As I said in my other post I’m currently evaluation Omeka for a group trying to determine if it will meet all of their needs. One need they have is the ability to have multiple collections and then lock user roles down per collection.
So let’s say they have two collections A and B they want to:
Give user XX the right to view private items in collection A, as well as the ability to edit and update them.
Give user YY the right to view private items in collection B, as well as the ability to edit and update them.
Make it so that user XX cannot view or edit private items in collection B.
Make it so that user YY cannot view or edit private items in collection A.
What the group is looking for seems to be a combination of these two topics from the legacy forums:
Does anyone know if there have been any updates to Omeka that make something like this possible? Or any plugins that have been created to do so?
The suggestion that I read was to create a plugin based off of the Guest User plugin. Does anyone know how feasible that is? Would it make updating or upgrading in the future more difficult?
This is one of the kinds of specific workflow needs that Omeka itself doesn’t handle, but sounds possible via a bespoke plugin for the task. The ‘Omeka Levels of Access’ is pretty old, and I’m guessing refers to Omeka 1.x, so many changes have happened since then. The first link gives more up-to-date info.
I think that a plugin could do this by at least one of these
Using an AclAssertion class that adds more specific permissions-checking onto the existing roles. It would look at the user and item, do the additional checks about the item’s collection and privacy settings, and return permission from there. That’d be a new class, and something added to the plugin’s defineAcl hook, That might or might not call for a new role. The in-progress Editorial plugin has an example of using a new AclAssertion.
Using the plugin’s itemsBrowseSql hook to limit visibility. This would end up doing a similar permissions check as above to further limit the items that are visible.
The upshot is that being able to view, and being able to edit, can take two steps in the kinds of situations you describe. I’m pretty sure it is doable, but would call for some interesting and non-trivial development work to make it happen. That work would also make excellent example code for others with similar needs to work from!
Is anybody manage to implement user role per collection successfully? Do you mind to share your trick?
If I do something like:
$acl->isAllowed(‘some-role’, ‘Collection_Id’, ‘makePublic’)
Did anyone ever figure the proper implementation out? I am attempting to do something very similar at the item level with specific and fine tuned permissions.
Sorry to reopen but has anyone managed to create a plugin that allows this kind of behavior? I’m trying to do so, but i’m struggling with Zend’s Acl’s allow() function that doesn’t seem to be applicable to a specific user. Can anyone tell me if i missed something here?