Restrict Items to Particular Sites


#1

Hi, I have a question about the way multiple sites work in regards to items. I’ve figured out how to make only certain items appear on certain sites but not others, but I’m wondering if it’s possible to restrict items to users in particular sites.

I work at a university that has used Omeka classic for a number of years, and we have various faculty working on different digital archive projects. It would be nice if they could use the various new features of Omeka S on the same site, but we are concerned about item sharing. Our faculty are usually not comfortable sharing their research with others until they are ready to publish, and this includes sharing between projects.

Obviously this is possible with different Omeka classic sites or with multiple installations of Omeka S, but we’re hoping to use the multisite options, as that would make using it and giving out instances much easier.

So is it possible to make items that are part of a particular site not appear to users not assigned to that site? If it isn’t, we are hoping this can be a feature in a future version.


#2

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.


#3

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


#4

Probably in January or Februrary.


#5

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


#6

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.


#7

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


#8

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


#9

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.


#10

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.


#11

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


#12

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…


#13

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?


#14

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…


#15

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?


#16

Thank you Daniel for your module.

I don’t know if there are any updates about this module, but, as Ferran wrote before, I would like to “Restrict Items to Particular Sites” too.

Even if Omeka S has a lot of other qualities, it would be very important for my installation to manage privileges on the sites and the item sets. I used the “itempool” to associate an itemset to a site but it is not enought because of the possibility to view all the resources of the installation.

Do you have any suggestions? Other solutions?


#17

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


#18

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.


#19

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.