Hello, we (www.lescomplexes.com), have to associate one RefBase account per book created.
We've one administrator account and, in this account have created as many users account as we do have books. We'd like each user not to be able to modify but access the other's entries. How shall we do?
I've associated one author group per user. But where are these author's groups options? If we disallow the "edit records" feature for one user he wont be able to edit his own!
Is there any other solution than creating as many administrator accounts as we do have books?
What are these author's group made for?
> Hello, we (www.lescomplexes.com), have to associate one RefBase
> account per book created.
I'm not sure I entirely understand what you're trying to do. Why do you need one user account per book? A further explanation of your workflow might help us to give better/other suggestions. Thanks!
> We've one administrator account and, in this account have created
> as many users account as we do have books. We'd like each user not
> to be able to modify but access the other's entries. How shall we
You want regular users to be able to view the user account details of other users? Or do you just want your users to see the literature entries of other users? The latter is how refbase functions anyhow, so maybe you want to achieve the first?
> I've associated one author group per user. But where are these
> author's groups options?
Currently, all permissions are handled on a per-user basis. I.e., ATM, there isn't a system that handles group permissions or options. User groups in the admin interface are just a means for the admin to group his users. Does this answer your question, or did you mean something else?
> If we disallow the "edit records" feature for one user he wont be
> able to edit his own!
Yes, this is exactly what the "edit records" permission is meant to do. It specifies whether a user is allowed to edit any records in the database. Note that one basic principle in refbase is that every user with edit permissions will be allowed to edit every record in the database. The reasoning behnind this is explained in more detail at:
Do I understand you correctly, that you'd like to allow users to edit their own records, but not the entries from other users? If so, this is currently not possible. We have a planned feature called "record-specific permissions" which will allow this. But it may still take some time until this gets implemented.
> Is there any other solution than creating as many administrator
> accounts as we do have books?
Again, I'm not sure I understand you correctly. Note that, currently, refbase does only allow for a single administrator account. What do you mean by "administrator account" -- being able to create & administer new users, or just to be able to add/edit new bibliographic entries?
Please tell us a bit more about your envisioned workflow so that we can make better suggestions.
Thank you for your answer.
La Poule ou l'Oeuf is a CMS made to produce books on line. Each book is associated to a User account in RefBase on our server in order to manage its bibliographic entries and cite it in the text.
The set up for the moment is:
La Poule ou l'Oeuf-Book1____________RefBase1-user1
La Poule ou l'Oeuf-Book2____________RefBase1-user2
We would like the book1 entries in RefBased to be separated from the book2 entries. At least we dont want user1 to be able to modify the user2 refbase entries, even if he can see it.
<quote>Do I understand you correctly, that you'd like to allow users to edit their own records, but not the entries from other users? If so, this is currently not possible. We have a planned feature called "record-specific permissions" which will allow this. But it may still take some time until this gets implemented.
Too bad, that's exactly what we need!!
In fact we need something like a RefBase's account collection, each account beeing separated from the others, and each of them beeing open to several users (as we can have several authors for each book).
It would be something like:
La Poule ou l'Oeuf-Book1____________Book1 RefBase account: user1, user2, user3 (all the users having the same permissions)
La Poule ou l'Oeuf-Book2____________Book2 RefBase account: user1, user2, user3 (all the users having the same permissions)
Do you have any solution for us?
Sorry for not beeing clear (you know, english teachers..., technical idiomatics...).
thanks for the clarification.
> <quote>Do I understand you correctly, that you'd like to allow
> users to edit their own records, but not the entries from other
> users? If so, this is currently not possible. We have a planned
> feature called "record-specific permissions" which will allow
> this. But it may still take some time until this gets implemented.
> http://wiki.refbase.net/index.php/Planned_feature_additions#Record-specific_permissions </quote>
> Too bad, that's exactly what we need!!
> Do you have any solution for us?
I fear there's not an easy solution. Implementing record-specific permissions would likely mean quite some changes to the refbase internals. Unfortunately, I don't have the time to do that now.
There might be a (clumsy?) workaround: for each book, bibliographic & user data could be loaded from different tables (with prefixes) or databases. I.e., for each book, the connection details in 'initialize/db.inc.php' would be different and would be loaded dynamically. Not sure if this is a viable workaround. We'd need to think about this more...
Sorry for being so vague, I wish I could serve you better here.
Maybe others in this forum have other/better ideas?
I agree with Matthias's assessment of current behavior and planned features. Trusting persons with the ability to edit other user's records has worked for many institutions that have at least dozens of users. The future enhancement would be finer-grained permissions.
This being said, it should not be difficult to check the location of a record & to not show the edit link or allow editing if the presently logged-in user is the creator of that record. This feels like something that should be an unsupported patch to me, but perhaps other users can comment on how valuable this would be.
I'm sorry if our demand feels like a "trusting problem". The authors we open a RefBase account to do not necessarily belong to an institution, do not write in the same books, nor on the same subjects and are human beings and, for that reason, could make a mistake! We do think too that they would perhaps prefer not to get the 243 other users references on "epistemology" when writing about sport and be sure they would not erase anything by error...
Anyway, we will find a solution and share it on this forum, in case it would interest someone.
Thank you very much for your help and your suggestions. And for RefBase, of course!
> it should not be difficult to check the location of a record & to
> not show the edit link or allow editing if the presently logged-in
> user is the creator of that record.
Rick's suggestion is a good one, and I agree that this wouldn't be too difficult to do. But this would only allow the creator of the record (and not any other users) to edit records. However, one could instead check for the value of the current user's "institutional abbreviation" (it's globally available in the 'abbrevInstitution' session variable, and it makes the first part of the user's ID string in the 'call_number' field).
You could then enter the same identifier string in the "institutional abbreviation" (i.e. the 'abbrev_institution') field for all users that belong to the same book project. I.e. each book project has its own (unique) identifier string in the 'abbrev_institution' field, and you'd use this string for all users that belong to this book project. Then this identifier string could be used to allow editing of bibliographic records that belong to this book project.
If some users should be allowed to edit entries from several books, composite strings (such as "book1-book2") could be used in the 'abbrev_institution' field.
And you could uncheck the "Modify options" permission (i.e. the 'allow_modify_options' field in table 'user_permissions') so that users would not be able to change the value of the 'abbrev_institution' field.
I think such a setup could work as a "poor-man's" group permission system.
I hope this was understandable, please let me know if not.
And if you run into problems during implementation, don't hesitate to ask, we'll be glad to help!
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.