Is it possible to add a new role for group members (allocation of permissions)?

Right now we have group members who are "admins" and others who are "members", and so we can set different permissions.
We would like to give some "members" the permission to "view and edit" the group library (without turn them into admins) but other "members" should only be able to "view". Is it somehow possible to add an additional role, e.g. read-only members?
  • Zotero really only has two possible roles for users in groups, members and admins. With that said, there is a implied third role for public groups, viewers. If you make your library public anyone can then view the library items from the webpage, subscribe to feeds of library items, and add copies of group library items to their libraries through the item icons in their location bar.

    That said, adding more roles and role capabilities for roles is something worth considering. Are there any other people that want additional roles? What kinds of use cases would additional roles let you accomplish that current functionality does not accommodate?
  • edited August 27, 2010
    The permission infrastructure isn't flexible?
    Nevermind, sounds like it is, and you're just referring to the current UI.
  • One that people have requested before is the ability to add and edit your own items but not those of others.
  • As our group library is a company's citation library we don't like to make it public. But there are a few members that are not really familar with computers but also need information sometimes.... It would be very helpful for saving our library if such people would only have the permission to read and not to add/delete items.
  • Another user was asking nearly the same:

    Could you please give us a feedback?

    Thank you!
  • edited November 28, 2010
    Here is another use case. I think it would make sense to have a permissions system with at least the following roles:

    0. admin (all rights + group settings, members, etc.)
    1. view & edit items & attachments
    2. view items & attachments
    3. view items only

    The latter role is especially useful when (as in the use case linked above) you want to give someone access to your collaborative bibliography but not necessarily want to distribute all attachments to that person.

    I would love to see a simple roles/capabilities system along the lines of the WordPress system, with a limited number of default roles (covering everything most people need) and the possibility to edit capabilities at role level (covering the special uses). Perhaps in addition to the ones mentioned above, other capabilities like "adding/editing notes" and "tagging" would make sense, as per this thread.
  • This has been around for a while and I'd like to add my support and hopefully give it a 'bump'.

    I think Mark's schema above works reasonably well for my needs. I have a library that includes attachments that I own and one's that I don't. Many of the later are publicly available, and where possible my records include the URL where they can be found, but technically I shouldn't be hosting them. So, Mark's option 3 above would let me share the library, without copyright/permission violations (but still allow members that level of access).
  • Apologies, thought I'd expressed support for this before on a thread, but couldn't find it. The more current discussion is here:
  • More fine-grained permissions have long been on the agenda and I don't disagree, but note that a closed public library does what you want in most ways: you can keep your attachments, non-members can see the library online, but can't access the attachments. The only thing that's not possible is for them to _sync_ the library to their client -- and I'm actually kind of doubtful that that's something many people would want to do.
  • edited April 14, 2016
    Thanks adamsmith. I did have it in my mind that it behaved that way, but was having a play yesterday and it seemed to be allowing access. Went back today and it's not, so assume I was mistaken.

    However, I do see that Notes are accessible. Might be nice to be able to turn that off.

    Could also be nice to be able to turn off the display of the attachments. I'm of two minds on this one, but I think the biggest argument in favor of this would be user confusion -- the attachment looks like it should be an accessible link, but doesn't behave that way. Not showing it, or having a mouse-over message, could be a useful option.
  • Hello everyone. I hope to find you all well and safe.

    Is this threat still ongoing? Looking into this for quite sometime and working on a large Historical Sources database it would be helpful if the following user permissions are possible:

    Admin (add and edit all records)
    Member (Can read all records and view attachements)

    Contributor: Can Add and edit only its own records and can view attachments.
    Public: Can view all records but can't view/open attachment. From Zotero standalone.

    Thank you very much
    Take care
  • Nothing new here except that with the new web library, the public view on a closed public group is much more useful/powerful and does allow easy transfer of items (w/o attachments) from a public closed library you're not a member of to your personal library.

    I think generally improvements to permissions for groups are still planned, but no idea where they are on the list of priorities.
  • I'm glad this is still being considered for improvement. I have several groups, and my biggest fear is that someone who is new to a group, might go in and delete things without recognizing that they are doing this, or do other things that could delete the structure/organization of the groups.

    So it would be really useful to have a way that someone could add things to the archive, but not delete or move them. Or that there was some form of wiki method to revert changes (I recognize that this is not likely, because files are often involved)

    So in either case, please consider this a bump for having more granular permissions being added, hopefully both on the case of what a permission group can do, and also more granularity on permissions on specific collections/subcollections within a group.
  • I know how much effort it takes to develop new permissions like this but I will just add my bump to the previous bump. We have a large group library (800+ members) for a recurring university course and it seems some old member, or someone using the old member's creds, deleted the entire library. Which one of our group admins found in the trash and restored. So this "add only" permissions level would be a great development from our perspective.
  • Any news from zotero-admin side?
  • Good afternoon,

    I faced the exact same issue mikefortun reported about a year ago.

    Just a minor request, I have no idea how difficult this would be to implement.
  • The role jacob-walker was talking about would also very helpful for us as we have the same fear....:

    A role where "someone could add things to the archive, but not delete or move them".
Sign In or Register to comment.