Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide embargo management capabilities #273

Open
bryjbrown opened this issue May 29, 2016 · 5 comments
Open

Provide embargo management capabilities #273

bryjbrown opened this issue May 29, 2016 · 5 comments
Labels
Subject: Access Control related to managing roles and permissions/information security. Type: use case proposes a new feature or function for the software using user-first language.

Comments

@bryjbrown
Copy link
Member

Title Provide embargo management capabilities
Primary Actor repository manager, repository admin, developer
Scope access, interface, institutional repositories
Level Low
Story As a repository manager, I want to manage multiple types of embargoes on objects in the repository from an intuitive sortable interface.

Glossary Used

  • Embargo: a specific policy placed on an object that limits access to it in some way
  • Repository admin: a highly skilled Islandora user in charge of supervising repository managers. Examples include Scholarly Communications Librarians, Digital Archivists & Repository Developers.
  • Repository managers: less skilled users trained to do specialized tasks on behalf of repository admins. Examples of repository managers may include staff at external orgs (such as a graduate school), internal staff, graduate assistants & interns. A good embargo management UI should minimize the amount of frustration they feel and have a minimal learning curve.

Embargo Types

  • Complete vs Off-Campus:
    • Complete: embargo restricts access to all public users
    • Off-Campus: embargo restricts access to public users outside of a specified IP range
  • Object vs. File (PCDM)
    • Object: embargo suppresses display of all representations of the object to public users
    • File: object's representations display, but a specified attached file (think 1.x datastream such as PDF) is inaccessible/disabled
  • Temporary vs. Indefinite
    • Temporary: at a date specified by a repository manager or admin, embargo is automatically lifted
    • Indefinite: embargo has no specified end date, so it persists until manually removed

Examples:

  • As a repository manager, I want to set an Off-Campus File embargo on an ETD that expires on April 1, 2020.
  • As a repository manager, I want to get a 7 day warning for embargoes that are about to expire
  • As a repository manager, I want to get a notification when an embargo has expired
  • As a repository admin, I want to view all Complete Indefinite Object embargoes, sorted in alphabetical order.
  • As a repository admin, I want to view all Off-Campus Temporary File embargoes, sorted with the next embargo to expire first.
  • As a developer, I want an API for retrieving and managing embargoes programmatically

Remarks:

  • How does the Hydra community manage embargoes? Looks like through ACLs and Solr, which is smart but perhaps it should live in the metadata layer too? If so, then extending PCDM (perhaps the Rights Extension?) to include a matrix of embargo statuses that both communities agree to could be a good thing to discuss.
  • @DiegoPino recommended the SPAR Publishing Status Ontology (PSO) as a possible option as well.
  • I'm going to show this to the IR Interest Group and see if they have other ideas/use cases/suggestions to contribute.
@bradspry
Copy link

bradspry commented Jun 1, 2016

Yes, I like the metadata approach, which would put the metadata in authorative control. I assume it would take the form of a date-encoded field.

MODS date-encoded field -> pcdmrights:rightsOverrideExpiration?
MODS accessCondition field -> pcdmrights:rightsOverride?

I envision mapping the embargo date from for example, a Proquest ETD to MODS. The system would respect the metadata's specified embargo date.

@kstapelfeldt kstapelfeldt added Type: use case proposes a new feature or function for the software using user-first language. Subject: Access Control related to managing roles and permissions/information security. and removed use case labels Sep 25, 2021
@jordandukart
Copy link
Member

jordandukart commented Oct 14, 2021

From the Oct 14th user call of use cases:

So this bumping a super old issue but @bryjbrown did indeed make an embargoes module that lives at https://www.drupal.org/project/embargoes and was also captured within #1161?

We (dgi) have a fork of this as well that we've been adding features to and maintaining: https://github.com/discoverygarden/embargoes.

@seth-shaw-unlv
Copy link
Contributor

@jordandukart, it was my understanding from Bryan that the module needs refactoring to use content entities instead of config entities. There was also an issue where embargoed items could be leaked through views. Has dgi been able to address either of those?

@jordandukart
Copy link
Member

Can't speak to the content entity refactoring. However, that issue does indeed need to get addressed 💣 .

@amyrb
Copy link
Contributor

amyrb commented Oct 29, 2021

Another aspect to embargo notification to consider: notification to content owner/depositor in addition to notification to repository administrator when an embargo is set, changed, or lifted -- preferably with an option to send a warning that embargo will be lifted ahead of that date. (From Islandora 8 IR Delta doc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Subject: Access Control related to managing roles and permissions/information security. Type: use case proposes a new feature or function for the software using user-first language.
Projects
Development

No branches or pull requests

7 participants