search

ucsdlib / damsmanager

DAMS Manager
Other
3 stars 1 forks source link

Decouple rights / access : specification #312

Open arwenhutt opened 5 years ago

arwenhutt commented 5 years ago

Descriptive summary

Specification for decoupling rights from access functionality in DAMS 4.

A note that, since the primary goal of this ticket/epic is to decouple rights & access, this specification work is limited to usage scenarios already supported in DAMS 4. With the expectation that, once this has been achieved and tested, additional access scenarios can be proposed, specified, and added.

Acceptance criteria

Part of Decouple rights metadata from access controls (epic) #311

arwenhutt commented 5 years ago
  1. Draft specification for decoupling rights metadata from access controls
  2. Draft specification for dams:accessControl Controlled Values specification
arwenhutt commented 5 years ago

@gamontoya we have a fairly well vetted (by DOMM) and robust spec for the rights / access decoupling!

Can we add this ticket to the prioritization discussion at DAMS-WG Tuesday? I'd love it if we could get this ticket (for the spec review and revisions) done before the end of June, so that @GregReser can be part of those discussions.

Also any feedback you have regarding the spec would be much appreciated!

gamontoya commented 5 years ago

@arwenhutt You got it!

gamontoya commented 5 years ago

@arwenhutt The specs look great. I'm just wondering how long Deliverable 2 will take and if we will need to do major testing scenarios again in a QA environment since a lot of object records will be touched?

arwenhutt commented 5 years ago

@gamontoya I don't really know - it'll depend on how long the batch updates take, how many records are left after the batch update, how diverse they are, and whether the batch overlay tool is available at that point for DOMM to do some of the updating (which reminds me, we'll probably also need a ticket to update the batch export and overlay tools with the new properties added in deliverable 1!).

A few things that may shorten the time frame: I was thinking that we could add the data (step 1 & 2) in production (since it won't change any current functionality just add new metadata fields), once that's done sync to QA and then do the dev and testing (deliverables 3 & 4) in QA. That would save making the record updates in QA and Production. The idea should be reviewed by ITD to verify that it wouldn't cause problems with the current site/system though.

Also, I think that to some degree deliverables 2 and 3/4 can be worked on in parallel - so DOMM could be working on 2.c. while ITD is working on 3 and/or 4.

lsitu commented 5 years ago

@gamontoya / @arwenhutt I am working on the tickets for batch update now. I think the following four tickets related to batch update (overlay) could be done in two weeks: Batch metadata overlay: deliverable 1 Batch metadata overlay: deliverable 2 Batch metadata overlay: deliverable 3 Batch metadata overlay: deliverable 4

lsitu commented 5 years ago

@gamontoya / @arwenhutt While waiting for reviewing, do you have any tickets created for this spec that I can work on now? Thanks.

gamontoya commented 5 years ago

@lsitu I don't think so, but I'm pinging @arwenhutt in case I'm missing something.

@lsitu Who in ITD is reviewing the spec?

lsitu commented 5 years ago

@gamontoya I've reviewed it and I think it looks good. But I would like @jessicahilt and @mcritchlow to keep an eye on it and give it a pass. Thank you.

mcritchlow commented 5 years ago

I agree w/ @lsitu that overall this looks good and will greatly simplify things once we're done.

I do have one question from the spec re: Deliverable 4 (damspas code updates):

Limit the CLR visibility functionality to the temporary curator only status used during ingest review. Other than this situation, access for objects will be determined by the value of dams:accessControl at object level

Ideally the front-end (damspas) code shouldn't have to make this distinction, it would only key on the value in dams:accessControl and set/limit access to objects and files accordingly. I'm curious if we can make that happen while still preserving the underlying goal of having a temporary status during ingest review. Though maybe this is something that the dams manager tooling can handle, which I think is the case now? @lsitu curious what you think on that.

lsitu commented 5 years ago

@mcritchlow Yes, that makes senses. I think we just need to do the same way as what we are doing now to update the access control value on damsrepo while damsolrizer index the objects. But the result only can be reviewed in damspas. Maybe that why @arwenhutt put it on damspas.

arwenhutt commented 5 years ago

@mcritchlow & @lsitu about this:

Limit the CLR visibility functionality to the temporary curator only status used during ingest review. Other than this situation, access for objects will be determined by the value of dams:accessControl at object level

The reason we included it was that we do still need to have a temporary status during ingest review, BUT we are totally flexible on how this is done if either of you have an idea for a better way to do it.

arwenhutt commented 5 years ago

@mcritchlow & @lsitu What are your thoughts on this item in the spec:

1.b. dams:restrictionMessage Text field used to append (or override?) default “restricted content” message displayed to user. It can be used for cultural sensitivity notes, embargo description, customizable contact info (for specific collections, etc.)

@gamontoya can you review the list of access scenarios to see if there are any that we currently support that are missing? This draws on Greg's pretty extensive survey of current ones in D4, but I think it'd be great if you could give it one last review! https://docs.google.com/spreadsheets/d/1qe0ruWJRhMX_jxPKCNZBqqS9ghhGWLb7Qb7zS8gCUDo/edit#gid=0

gamontoya commented 5 years ago

@arwenhutt Will do!

lsitu commented 4 years ago

@arwenhutt I am fine with adding the new field dams:restrictionMessage to append (or override?) default “restricted content”. But we we may need some efforts on damsrepo, damsmanger and damspas to support it. Also, what kind of data cleanups that we need for this change?

arwenhutt commented 4 years ago

@lsitu I believe the clean up is largely outlined in the spec linked above https://github.com/ucsdlib/damsmanager/issues/312#issuecomment-497508259

I think we will want to review this again in light of work done and bugs discovered in the last six months. We'll do that before the DAMS wg meeting on Tuesday