Decouple rights / access : specification

[arwenhutt]

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

• spec drafted (DOMM)
• spec reviewed (ITD)
• changes made and spec finalized (DOMM & ITD)

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

[arwenhutt]

1. Draft specification for decoupling rights metadata from access controls
2. Draft specification for dams:accessControl Controlled Values specification

[arwenhutt]

@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]

@arwenhutt You got it!

[gamontoya]

@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]

@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]

@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]

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

[gamontoya]

@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?