First, on the Import menu:
I haven't tested this, but I think this is something you could change by adding additional groups to the following file:
As you can see, currently both the import functionality, and the import menu in the AtoM header, are restricted to the administrator group. Here is an example of a file (for the Accessions module) that shows you what this should look like when multiple user groups are added:
So, for example, if you wanted Administrators and Editors to be able to perform imports, try changing the file above to look like this:
credentials: [[ editor, administrator ]]
credentials: [[ editor, administrator ]]
I strongly recommend that you test this on a development instance before trying it on your public-facing production site!
You'll also want to restart PHP-FPM and clear the application cache after making changes. See:
Remember as well that your web browser has its own cache - so if you are not seeing changes, try clearing that and/or test in an incognito browser window.
Your second question is more difficult to answer:
As you may know, AtoM's permissions module is one of the oldest modules in AtoM, first introduced in either ICA-AtoM 1.1 or 1.2. There has not been major development of this module since this time - depsite the fact that AtoM has grown significantly, and people are using it for increasingly complex use cases with an increasing amount of records! Part of the challenge here is Artefactual's business model and the way we maintain AtoM - we rely on community support for major development, but while institutions are willing to pay for new features, it's very difficult for us to find sponsorship for refactoring existing modules, even when they need it. You can learn more about how we maintain and develop AtoM here:
At this point, there are a number of known issues and bugs with the Permissions module that make fixing individual problems very difficult - we need to do a complete overhaul of the permissions to make them more performant and scalable, as well as clearer to end users. Artefactual does not have the resources to take on this scale of work without development sponsorship, but so far we have not found institutions interested in helping to fund this work.
I have previously written about some of the known challenges with the Permissions module in the user forum, here:
Some of the known bugs that I suspect you may be encountering include:
In the long-term, Artefactual is currently investigating third-party open source libraries that deal with identity and access management (such as Gluu
, the Open Identity Platform
, etc). User management and granular permissions is a common problem that most enterprise-level software needs to address, and there is no reason for Artefactual or AtoM to build everything from scratch and reinvent the wheel if we can implement an open source library that is specifically focused on this area.
Incorporating a new library for identity and access management (IAM) will likely be our strategy for any next-generation version of AtoM (aka AtoM3). However, it's also possible we could build a new component around one of these tools and integrate it with AtoM2 now, rather than trying to rebuild a new permissions module from scratch in AtoM2. Since we are committed to supporting AtoM, Artefactual will eventually find a way to get this work done - but with community sponsorship, this is something we could prioritize for an upcoming release, rather than target as a long-term goal.
In the meantime, your best strategy is one of testing and compromise. In some cases, trusting your users to be respectful with each others' records and keeping the permissions minimal will be more successful than trying to implement complex and granular permissions in AtoM. One case we know can cause issues is trying to restrict View Draft permissions on a per-repository basis - this can cause timeouts for logged in users even when looking at other record types, such as authority records! See my second user forum post linked above for more on this specific topic.
I know this is not ideal, but I hope that the information will help you find a compromise or workaround in your AtoM installation that will work for your needs.