6126 deactivated leases

[alishaevn]

Fixes

• cannot remove lease from work #6126

Summary

fix deactivating leases in koppie

Guidance for testing, such as acceptance criteria or new user interface behaviors:

• create a work, or update a work, to have a lease in the future
• go to the "/leases" endpoint
• click the name of the work
• select "deactivate"
• be taken back to the work show page and notice the lease is removed

Detailed Description

while working on #6098, braydon and I began updating some of the lease code to follow the pattern of the embargo code we were implementing. however, actually fixing the ability to deactivate leases was out of scope for #5844, so I created a ticket and the work was moved here.

some other things to note:

• the lease is no longer saved on the work. it us referenced using a lease_id attrubute
• adding a file to a work with a lease, adds a lease to the file
• removing the lease from the work does not remove the lease from the file set even if you tell it to. this is the same functionality with dassie on main though, so I did not fix it
  • on main however, we're able to go to "/leases" and see the file set. then click on it and deactivate it
  • in valkyrie "/leases" shows that there's a fileset with a lease on it...but the fileset doesn't have "title" metadata so we can't click into it to deactivate it. fixing fileset metadata felt out of scope so I didn't address it. (you could manually get there by going to "/leases/<fileset_id>/edit" though)

@samvera/hyrax-code-reviewers

[jeremyf]

Hmm…thinking about this parameter name valid? It is a bit confusing.

Does it mean "Treat this record as valid?" Or does it mean "validate this record". Looking at how it is later used, it looks like it could be perform_af_validation: false

[jeremyf]

The spec says "will not call the workflow_importer" but that part was removed. I think we need to restore the expect(workflow_importer).not_to have_received(:call) as that's the purpose of the spec. Namely to ensure that we're not having side effects when an error is raised.

[alishaevn]

I removed it because at the time I was testing it...it was no longer valid. related to the note below.

if I recall correctly...since we weren't validating in Hyrax::Persister#save, any longer, we did not get the runtime error anymore from Hyrax::AdminSetCreateService#create!. therefore the workflow importer was called. later down the stacktrace in Sipity::Workflow#activate!, Sipity::Workflow.find_by! failed because we didn't have a workflow_id. that caused the ActiveRecord::RecordNotFound we're now checking for.

when I spoke to Rob about it, the different error and change in the save method, he said to change the error we were now expecting. I did not however explain the full background of the spec with him.

now that I'm passing a perform_af_validation param to save though...I can pass perform_af_validation: true inside Hyrax::AdminSetCreateService#create!.
hopefully that doesn't break another spec. 😩 🤞🏾

note

Tuesday, August 1, 2023
while pairing last week, rob suggested this change. I noticed last night that committing that change made the 7 failing works_controller_behavior_spec’s, pass.
a little bit ago however, I noticed that the change caused spec/services/hyrax/admin_set_create_service_spec.rb:294 to fail.
I’m now unsure whether I should or should not use validate: false in Wings::Valkyrie::Persister#save. or the best practice way forward on making sure that the specs in both files pass…and that we’re doing the right thing.

[alishaevn]

my proposed change broke several things because Hyrax.persister.save that gets called inside of Hyrax::AdminSetCreateService#create! is not the same as Wings::Persister#save. it instead comes from "/usr/local/bundle/gems/valkyrie-3.0.3/lib/valkyrie/persistence/postgres/persister.rb", 20.

I've reverted my change and updated the assertion.
ref: f992e10

[jeremyf]

I'm surprised that we're changing the data type. A Date object only includes Month Day Year, and maps to the concept of lease_expiration_date. Whereas a DateTime includes hour, minute, second.

This seems like a subtle shift but I'd like to know how this came about.

[alishaevn]

I changed it because on main, when you add a lease to a work, it's saved as a DateTime. so I made koppie do the same. idk how the tests weren't failing before. 🤷🏾‍♀️

[1] pry(main)> ActiveFedora::Base.find('dr26xx36k').lease
=> #<Hydra::AccessControls::Lease id: "0db70bc6-1bd0-4b95-a991-9b4e275b6f33", visibility_during_lease: "open", visibility_after_lease: "restricted", lease_expiration_date: "2023-08-31 00:00:00", lease_history: []>

[2] pry(main)> ActiveFedora::Base.find('dr26xx36k').lease.lease_expiration_date.class
=> DateTime

[jeremyf]

Reading this comment, and the following spec, seems like we're not actually testing the assertion of the comment.

Does the converter.convert have a lease_id key? Is the corresponding value different from work.lease_id? That would be helpful to align the spec with your comment.

[alishaevn]

I went back to test this and was able to revert the test to what it already was. 🤷🏾‍♀️

ref: 580d817

[alishaevn]

a new file set gets added to the work in this #call method, which happens after "steps/save.rb". doing this call here correctly puts the lease on new files and existing ones.

[alishaevn]

putting this method in the LeaseManger feels like a better place for it to be than in "transactions/save.rb". it also makes it easier to use when #6131 gets worked on.

I think this is addressed and I want to get it merged before anything else breaks it =-) if its not, we can alway open up a new ticket for this one small thing