Forums » User access in plugins

RSS feed for this topic

Info

  1. Hi,

    I have little problems with the users’ access to some plugins. I noticed that there was a lot of discussion about users’ access, but I didn’t find any answers to my questions.

    First, if contributors have only access to the private items that they created themselves, why can they have access to the CSV import plugin? Is there a way to give them this access? I suppose that it is because a contributor doesn’t normally have access to the server, but if I upload the csv file, I want them to use the plugin to create their own item’s description. Or, do it myself, but give them the paternity of the items created so they can see it, even if it is private. It’s the same thing with the dropbox plugin.

    On the other hand, why do the contributors have access to the simple vocab plugin? I don’t want them to modify it, just to use it. Again, is there a way to change that? And it’s the same thing with the item relation plugin. I want them to see de definitions, but not to edit the custom vocabulary.

    Thank you so much for taking time to respond,

  2. I'll have to do some checking into things to see what the default permissions are for these things.

    Each plugin sets its permissions individually, but the general idea that they should be following is that contributors can see the admin panels for those plugins because they should be able to add new things (items, pages, exhibits), and edit their own.

    The setup is usually such that, while contributors can create new things, they can't make them public, so they can't affect the site as "real" users see it unless an administrator explicitly makes their creations public.

  3. Yes, it is what I understood about the logic under Omeka's permissions.

    But I don't think that the plugins mentionned respect this way of thinking.

    If each plugin sets its permissions individually, can I change de code to allow my contributors to access the plugin? I know where, but whithout a good knowledge in php, I don't know how to write it...

  4. Just so I understand, can you say on a plugin-by-plugin basis, exactly what the plugin allows or doesn't allow that's counter to what you're expecting?

    In general terms, the plugins will set up their permissions by using the define_acl hook. Each plugin will have a function defined for doing this, which will usually end in define_acl.

    Adding or removing permissions in a plugin would be simple, just adding a new $acl->allow or $acl->deny call, but we'd like to know specifically what you think is wrong so that we can potentially include those changes in future updates to the plugins.

  5. Ok. This is a long post, but I took the time to explain what I was thinking about.

    First, I don’t have enough knowledge in php to figure out how to modify the acl calls in the csv import plugin. There is something I don’t understand in the section with commentary “Add the admin navigation for the plugin”

    Anyway, this idea wasn’t the best because it wasn’t exactly what I need. I was searching for a solution. I found out a solution by asking directly in sql to change the “paternity” of the item with:

    UPDATE omeka_entities_relations
    SET entity_id=[id of the contributor who should have access to the items]
    WHERE relation_id between [lower item id upload] and [higher item id upload]

    This way, contributors can make some modifications or add files to the items’ description (or even prepare an exhibit) before an administrator makes it public.

    The reason why I want that is simple. Imagine we are in an archive center and I am the principal archivist. I load in batch the archives I want my volunteers to describe. I don’t want them to have access to the admin interface, so, I need them to be contributors. If I load in batch, and don’t make the items public, they cannot have access to describe it. But I want the items to stay private because they are not described and I want to make a verification before making them public (me or my colleagues with admin status). This is the main reason why we should have a better control, as admin, to give access to private items to contributors, however the way the item was added, manually or with a plugin (csv import or dropbox).

    Other thing I was noticing in my first post:

    Simple vocab: Contributors can edit vocabularies and I think they shouldn’t. There is too much risk of too many modifications of the vocabularies. A limited number of persons (admin and super) should have the right to edit the vocabularies. Contributors should use it when they describe items, but not change the vocabulary whenever they want. Otherwise, it is not controlled vocabulary!

    Item relations: Same thing than simple vocab. The contributors can edit the custom vocabulary and I don’t think he should for the same reason than the one explained for the simple vocab plugin.

    I hope that my explanations will help. Ask if anything is not clear enough.

  6. Thanks for the clarification.

    A plugin or some other way to modify the "owner" of an Item without having to go into SQL might be a good idea.

    As for the permissions issues with the other plugins, I think most people would agree with you. This may simply be an oversight in the defined permissions for those plugins.

  7. Thanks! Hope it can helps!

Reply

You must log in to post.