Manager should be able to lift an embargo even if the embargo date is not passed

julesies commented 6 years ago

Descriptive summary

Right now if a work with an embargo and that date has not passed, a manager can lift the embargo, but the work does not automatically become unembargoed, since the original embargo date has not passed.

Rationale

This is unexpected behavior

Expected behavior

Lifting an embargo puts the work into the desired state regardless of date of embargo.

Steps to reproduce the behavior

create a work with an embargo that should change to public
As a manager/admin and before the embargo has passed, deactivate the embargo
work is not public

no-reply commented 6 years ago

This button calls down to https://github.com/samvera/hyrax/blob/1e504c200fd9c39120f514ac33cd42cd843de9fa/app/actors/hyrax/actors/embargo_actor.rb#L13-L18, which seems like it only changes work visibility under the condition that the embargo has lapsed.

no-reply commented 6 years ago

@samvera/hyrax-repo-managers It has been pointed out to me that "deactivate" is ambiguous, and that "remove embargo, but leave permissions as is" is one possible (if stretched) interpretation. Would we like to fix this and relabel "Lift Embargo" or similar?

Feedback is needed.

vantuyls commented 6 years ago

My interpretation of the desired state is this: 1) A work is under embargo 2) As a person with appropriate permissions, i can expire the embargo prematurely 3) Expiring the embargo will set the work's visibility to the visibility defined as part of the original embargo

Example 1: 1) i have a work that is embargoed. the embargoed visibility is set to Private, the embargo end date is set to 01/01/2020, and visibility after embargo is set to Institution 2) i am a repository administrator 3) when i prematurely lift the embargo (on 01/01/2019) the visibility is set to Institution

Example 2: 1) i have a work that is embargoed. the embargoed visibility is set to Private, the embargo end date is set to 01/01/2020, and visibility after embargo is set to Public 2) i am a repository administrator 3) when i prematurely lift the embargo (on 01/01/2019) the visibility is set to Public

julesies commented 6 years ago

agree with @vantuyls !

no-reply commented 6 years ago

:100:

Is a relabel from "Deactivate Embargo" to "Lift Embargo" (or something else?) desirable?

julesies commented 6 years ago

oh relabel in the interface? i was thinking you meant the words on this issue. FWIW every repo-manager that tested this assumed it would behave as steve described with the wording "deactivate". I assumed the work was to make it work like steve described. So you are proposing change the way it works AND rename UI active to "lift"? Lift does sound a bit better?

no-reply commented 6 years ago

Yeah, I'm supposing that "Lift" is more clear.

no-reply commented 6 years ago

I've done some preliminary work on this, in conjunction with a Hyrax 2.1 application. I think the status quo is confusing enough that the embargo management pages (and maybe the UI-facing embargo lifecycle) needs a significant design phase. This, and all below, applies to Lease as well.

The "Deactivate Embargo" button currently does the following:

Applies the current permissions specified by the embargo to the item;
- if the embargo is not expired, the item is updated to during-embargo permissions.
- if the embargo is expired, the item is updated to the post-embargo permissions.
Marks the embargo "deactivated".
Prompts the user for whether to apply the work permissions to the filesets/files;
- This happens whether the work permissions have changed or not (deactivating a non-expired embargo can cause previously public or institutional access files to go to private).

The thing is that "active/deactivated" is different from "not expired/expired". It's possible and common for an embargo to be active and expired, or deactivated but not expired. The "Deactivated Embargos" tab in the embargo index view reflects this, as does a link in the form suggesting that users should navigate to the embargo management page to deactivate (not lift/release) an embargo.

Lastly, the "Expired Active Embargos" tab in the embargo index view also uses "Deactivate Embargo" terminology. Though these buttons do the same thing as described above, they contribute to the confusion because the embargos on this page are all expired, meaning this is always a "Lift/Release", rather than an impotent "Deactivate" as is usually the case on the other page.

I'd like to see this go to design. The "active/deactivated" terminology seems like it causes a lot of confusion, without really being helpful to the user in any way. I wonder if we could keep the backend implementation/actions, while reconsidering what we show to users about embargo status.

In the meanwhile I'd like to clarify the scope of this ticket. I don't think we can rework the existing behavior reasonably without design, but we could implement a second "release/lift" button on the embargo edit page. It would be nice also to replace the "go over here to deactivate" text with an "Release Embargo" button on the edit form.

In our application, we have implemented stopgaps (see https://github.com/curationexperts/laevigata/pull/1125):

Removed the "Deactivate Embargo" button from the embargo edit view.
Removed the reference to that button from the work edit form.
Changed the text on the "Expired Active Embargo" tab of the embargo index view to "Release Embargo" (instead of "Deactivate")

julesies commented 6 years ago

@no-reply just adding a couple related UX tickets from testing that didn't make it into 2.1

https://github.com/curationexperts/nurax/issues/277

https://github.com/curationexperts/nurax/issues/257

njaffer commented 5 years ago

The topic of "Manage Embargoes" came up in repo managers IG meeting. We referred to this ticket as there is confusion around the design. It was suggested to add some help text with the buttons. The stopgaps referred above (https://github.com/curationexperts/laevigata/pull/1125) would be helpful to add to the core code.

rjkati commented 3 years ago

In Hyrax 3.0.2, lifting an embargo prematurely sets the work visibility to the pre-expired state. For example:

I deposit a work that is embargoed. the embargoed visibility is set to Private, the embargo end date is set to 05/21/2021, and visibility after embargo is set to Public.

When I lift the embargo on 05/20/2021, the visibility is set to Private.

samvera / hyrax