Replacement for Scholar Embargo (time-based)

[mjordan]

We need a replacement for functionality provided by Scholar Embargo - time durated access control policies with auto-expiry.

[mjordan]

Could this be a Context? If embargo date has past, release access control?

[dannylamb]

Pretty much. If time has lapsed, delete the tag with a Cron job. That's how I'd attempt it.

…

On Wed, Jun 19, 2019, 03:51 Mark Jordan ***@***.***> wrote: Could this be a Context? If embargo date has past, release access control? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1161>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE6PSH3SOHQ2WO4AZSCJIHDP3HJN7ANCNFSM4HXIVJLA> .

[bryjbrown]

Can someone post a quick summary of the work thats been done so far via access control? I have some ideas for how this could be accomplished, but I don't want to suggest X when Y is already the standard way of doing things.

[mjordan]

@bryjbrown there has been little done on access control, but one method discussed a bit so far, in #823, #826, #1134, and elsewhere, is using taxonomies.

Islandora does nothing special, you should use the most applicable Drupal node, field, and media access control modules/strategies. Perhaps this is an areas that could be documented in several recipes in the cookbook @manez is planning.

[mjordan]

@bryjbrown this blog post from today might be of interest as well: https://wishdesk.com/blog/drupal8-user-access-modules.

[mjordan]

https://www.drupal.org/project/moderation_scheduler might be able to provide embargos similar to those provided by Scholar.

[dannylamb]

Of course somebody's already done it...

[bryjbrown]

@mjordan This could work for some folks, but the most common types of required embargoes for IR users has to do with blocking access to folks outside of a specified IP range, or providing access to a node but blocking download of the node's attached file. https://www.drupal.org/project/moderation_scheduler allows you to schedule a date for publishing a node, but since that leaves the node unpublished until then its not suitable for most IR users (personally I don't think a node should be public until its fully accessible, but apparently this is the most common practice in the IR world).

My guess is there will likely be lots of modules that are already written that do ALMOST what we want, but I don't expect to find one that will do everything, and certainly not from a single, unified interface (which was a major flaw for embargo management in 7.x since IP Embargoes and Scholar Embargoes had different methods of access restriction and different admin menus, and as a result different learning curves that require separate training).

My idea for 8.x currently is to create a module that provides a pre-defined Paragraph field group that will be used to store all the embargo data one might want to express (IP restricted or global? Node visible or hidden? Permanent embargo, or schedule a lift date? etc) making it a one-stop embargo control panel for the individual object, as well as an admin menu that lets you view ALL the objects that are currently using this paragraph and what their state is (there's a paragraph-view integration module that should make this doable). Finally, to actually implement the access restriction you should be able to build a context that fires on page load for any node that has this paragraph attached, and then behave accordingly. This sounds like of course more work than just using a module that already exists, but I think building something that fits precisely into IR managers' brains and fitting the way they see embargoes as opposed to making them think in Drupalisms will be a key win for usability and worth the effort.

[manez]

I'm normally a big fan of just doing the Drupal thing, but @bryjbrown that was pretty convincing.

[bryjbrown]

Cross-referencing #1160 and https://github.com/mjordan/ip_range_access here since they are very relevant.

[mjordan]

@bryjbrown thanks for the comment. I was going to point out IP Range Access (posted on Github just a couple of hours ago) since it is relevant to what you're saying.

[dannylamb]

In the end, it's not really that much coursework @bryjbrown. Still sounds pretty drupal-y to me and in line with how we're doing everything else. Just put it into plugins and use context 👍

[elizoller]

Do the embargo policy apply at the media level or the node level?
Our use case at ASU is that our embargo limits download/access to the media files but that the node's metadata is still accessible. @wgilling and I are conceptualizing adding a field for embargo date on the media object(s) and then filtering the media object(s) views (EVAs) by that date. We tested this config out locally and it seemed to work.
When you all mention using context - I would think that would be more of node level config where you would no longer be able to access the entire node. Am I understanding that correctly?