This call is a Community Forum call: Sharing best practices and challenges in the use of existing DSpace features
We will use the international conference call dial-in. Please follow directions below.
Community Forum Call: DSpace authentication and authorization demystified
Sharing best practices, challenges, and questions. The call will be dedicated to answering participants questions and discussing.
Following topics are considered in-scope of the conversation:
Information about authentication and authorization, groups and policies, is currently scattered over different pages in the DSpace documentation and is quite limited. As an outcome of the call, participants can indicate which pieces of information from the call are candidates to be added to the general DSpace documentation.
If anyone wants to volunteer to extend the documentation for authentication and authorization, by al means feel welcome.
Related open tickets in JIRA:
Bring your questions/comments you would like to discuss to the call, or add them to the comments of this meeting page.
If you can join the call, or are willing to comment on the topics submitted via the meeting page, please add your name, institution, and repository URL to the Call Attendees section below.
With the DSpace community calls the DCAT group wants to open up the DCAT calls and get groups of DSpace administrators together. The main topics of DSpace community calls are current DSpace features and how administrators are (or are not) using them. The goal is not only to discover flaws or opportunities for improvement of these features. We also want to share our best practices and ideas to learn from each other.
Authentication is a rather technical aspect, and thus more interesting for DSpace developers than DSpace administrators. For this reason it was more interesting to focus on the authorization aspect.
When it comes to DSpace authorization one thing is very clear. It needs to be better documented. Up to now the rights of some authorization roles are not sufficiently elaborated upon in the DSpace documentation.
During this meeting's discussion one attendee mentioned using only the administrator role, as they were told the other roles did not function well. One issue with only using this administrator role is that it is extremely powerful. E-persons with that role are even capable of changing things like the metadata profile.
A participant mentioned often receiving the request from submitters to edit their own submissions' metadata. To avoid the main DSpace administrator has to edit all of those submission there currently is no other option than giving submitters the collection administrator role. This however, implies that those submitters are also able delete bitstreams, which the participant wants to avoid.
One way of dealing with this is granting collection administrators granular access by altering the DSpace config file. In this config file it is possible to disable the collection administrator's permission to delete bitstreams.
Although the authorization described above does grant submitters access to the metadata records of their own submission so they are able to modify them, it does have a disadvantage. By applying this method, all submitters are able to alter all items of the entire collection, not only their own.
At this moment there is no out of the box way to grant submitter just enough access to alter their own metadata records after submission, without providing them edit rights to other items.
One participant wanted to make certain items invisible to the end user. The participant first tried to give these items the 'private item' status. Although this did make those items invisible to the end user, those item were still harvested through OAI-PMH. This forced the participant to make those items into withdrawn items.
It is possible the issue with harvesting private items was caused do to a bug in earlier DSpace versions. Using the latest DSpace version may already fix the issue.
On a side note, the private item status is one of the things currently inadequately documented. It was mainly created to avoid a certain item from being indexed by search, and thus make it not retrievable through the search function. At the same time, users with the item's url would still be able to view the item.
One participant mentioned using the withdrawn status as an embargoing tool. They did not want to limit the embargo to the bitstream, but instead embargo the entire item. As DSpace does not support this out of the box, they give the item the withdrawn status until the embargo period is over. One downside is that those items are difficult to retrieve, as they already were private items before they were withdrawn, and thus they can not be searched for.
Multiple participants mentioned DSpace is currently not providing information regarding affected items when altering authorizations. It would be useful to have both a report before and after authorization changes. The report prior to the change could indicate how many items will be affected. The report after the execution could summarize what exactly has changed.
A participant mentioned internal staff at one institution was extremely enthusiastic about the request a copy feature for metadata only items. The reason for this is that it are the authors themselves who receive the request a copy emails, and so the authors could see who was interested in their work. These requests for copies are often used by them to examine possible research collaborations, and function as a conversation starter.
The DSpace 7 outreach group is still looking for a chairman. The required commitment for the outreach group is likely to be able to attend one meeting every two weeks. Participating in this group has the benefit of being able to closely interact with developers and stakeholders, and have influence in the DSpace 7 project.
Up to now there is no formal topic list for 2017's DCAT meetings. The DCAT chairs will send out an email with suggestions on subjects, which is open for other proposals.