Editing records: Difference between revisions
(Original page content from 23-Oct-2006) |
m (Hide section edit links) |
||
Line 18: | Line 18: | ||
[[Category:Usage]] | [[Category:Usage]] | ||
__NOEDITSECTION__ |
Revision as of 16:37, 20 November 2023
General notes about editing
We strongly believe in the wiki approach of collaboration where every (logged-in) user is allowed to edit every database record. Normally, this tremendeously helps to improve the quality of your records since everybody can easily make corrections and/or additions. Actually, we have never heard of any serious misuse of this feature.
Of course, there may be some valid concerns among your users about data persistence. When discussing this issue with your users, it's worth pointing out these things:
- While the basic bibliographic data of a record are shared among users (and can be edited by every user), every user has in fact private, i.e., user-specific fields that nobody else can view. These are the "yellow" fields at the bottom of each entry when viewed in details view. People can put their private keys and notes there without having to fear that somebody else will read them.
- refbase allows users to setup (and subscribe to) custom RSS feeds that track any changes made to records that belong to their own library.
- It should be relatively easy to setup a cron job on your server that backups the refbase database at regular intervals, say, every night. An example for a backup script is given here.
- This ensures that you can retrieve a previous version of a particular record in case some malicious user did something bad. And with a rigorous backup strategy on the server, this setup may already be much safer than most people's own literature database on their local machine.
- It's also worth pointing out that every user can install refbase locally – provided the user has a webserver installed. But with projects such as XAMPP, this has become very easy.
- The backup dump file that you get from the mysqldump utility can be used as base data file when installing refbase. This means, that users could grab a recent backup copy of your refbase database from your server (if you allow them to do so) and install it locally on their machine for convenient offline access. The same method can be used to update a local copy of a refbase database with updated data from the server's master database.