Restrict Items to Particular Sites

In fact, I have the same problem and I created a module “Group”, so the author and the reviewer only see items when the are in the one of the groups of the items or collection. The module is not yet published.

2 Likes

This sounds great - We’ve got the same problems with different User groups. Please let us know when your module is published.

1 Like

Probably in January or Februrary.

2 Likes

Hi
From your description, I assume your module will work on the admin dashboard?

Yes, this is for the admin board. For the public board, only public resources are available for anonymous visitors. But the authenticated or the guest user see the group resources too on the public board. I 'll publish soon.

1 Like

I published it in Daniel-KM/Omeka-S-module-Group.

Many thanks, Daniel. Do you want to add it to the registry so it’ll be available on omeka.org for download there, too?

Yes, it can be published on omeka.org.

Off topic, I don’t understand the meaning of the new registry on omeka.org. If we put all modules on it, we won’t see the difference with my own automatic lists (with a little manual work) (https://daniel-km.github.io/UpgradeToOmekaS). And I don’t know why you need to send my personal data to google and why google needs them. Anyway, all my modules and tools are open source, so anybody can register them and any other module.

Thanks.

Regarding your questions about the new registry, here’s some quick responses that I should probably expand into a blog post soon.

Part of it is needing to integrate the lists of addons into our site. We needed something we had a little more control over for our workflows and publishing, especially for consistent packaging.

We ask for your email so that we can contact you if there is any problem with the packaging of the module for distribution.

We’ve also found that sometimes developers want more control over how and when their work appears on our site. That’s especially true of people in some academic positions. They might want to cite the official omeka.org info for their CVs or tenure/promotion files, but only when they are ready. So, I think we’ll shy away from making those choices for others.

How to set private working groups in Omeka-S?

We are testing Omeka-S 1.0.1 and we’d like to configure it for this scenario:

  1. There will be several (maybe a dozen) researcher groups; some of this sites will have thousands of items.
  2. Each person belongs to a single site.
  3. For each person, after logging in, they should see only their resource templates, items, and their item groups.
  4. Each time a person creates a new item, this item should automatically belong to their item set and so, to their group.
  5. This visibility must not be affected with the status of public or private for each item.

We tried to configure Omeka-S before and after installing Daniel-KM Group module (https://github.com/Daniel-KM/Omeka-S-module-Group), but after many tests, we haven’t been able to create the permissions we need.

There are several entries in this forum with related questions, like:

However, it seems that this scenario is not obvious. How should we do it?

Thanks

Yes, the module group is not enough in that case: it doesn’t do 3, 4 and 5 ( and for the 2, for the project i made this module, a user can belong multiple sites). So the module work as I want in my case, but it should be improved to manage your case…

Or a new module can be created to change directly the core visibility rules, in particular to make the site permissions more useful, so only the people that are listed in the site part can see the items of the site.The difficulty is that in many cases, items can belong to multiple sites in order to create exhibits, or to facilitate the exchanges, the mix, the research…

Thanks Daniel for your reply.

Do we understand it well that, for our scenario, a single Omeka-S is not the software we need, at least for the medium term (say, this 2018)?

Should we better look for other solutions?

The user rights are probably not the only points you have to check to choose an app. If this is the only one issue you have, it’s probably simpler to improve the module, because Omeka S has many other qualities.

I may improve the module to comply with 3, 4 and 5, but it requires two days of development (except for the groups for resource templates, something that is totally not implemented for now and I don’t know if it is easy to do it).

Or perhaps the full management of the visibility via site permissions will be included in the next version of Omeka, if the core team wants it…

Certainly Omeka S has many other qualities. A couple of months ago, we were about to decide to install several Omeka Classic (at least half a dozen in the next few months) when we discovered Omeka S. The way we understood it (a single installation for institutions with several collections to manage, each with its own skin, language and data schema) was that each working group was isolated from the other ones, like the scenario I wrote above, but with the administrative advantage of a single installation. For them, seeing items of other groups will be at least disturbing and confusing.

Maybe we didn’t understand it well, or maybe the description is a little bit confusing. But we need to decide something, as they are waiting for our evaluation. Perhaps https://www.accesstomemory.org/ could serve us better?

The module Group is maintained, but I didn’t add new features for now.

Sorry for bothering you, but would you take a look at a question I posted earlier this week? How does visibility of Items work?. I’m basically trying to figure out how should I handle selective publication of Items on an Omeka S site. Thanks.

Omeka S is based on a central unique repository for all items, but on multiple sites. Furthermore, any resource can be public or private. If a resource is private, it will be always hidden to visitors. If it is public, it will be visible only on the site where they are in the item pool or in the item set list. So to make an item visible only on a specific site, check all other item pools of other sites.

Hi there. I have installed the groups module and I am trying to figure out exactly how to achieve what it claims it can do; “In the admin, this module decreases the access of the identified users to the resources”.

I have created a second user login for myself to see how this would work. My goal is to limit the view of item sets and items that I see ( only the ones that I am assigned to in a certain group) when I login. The module can do this, correct? In the admin, I have set myself to an author. I can still see every single item set and item in the system. I know that if the item sets are set to private that I won’t see them, but then so will no one else on the live site and that’s not what we want.

I am not sure what I am doing wrong, or maybe I am misunderstanding what this module really does?

The module allows to limit access to a group of resources. For example, if a user is in the group A and in the group B, he can access to the items that are in the group A or B, but not to the items that are in the group C. Of course, if his role is admin, he has access to everything. And if the item is public, he can see it, whatever the group he is.
So you have to use the same groups for the items and for the users.