Authorizations

This is a brief review of what is written in functional overview and business logic layer.

• If not explicitely stated the policy is DENY
• ADD/REMOVE policies are defined on containers and influence the content. ITEM is a container for BUNDLES, thus adding ADD/REMOVE policy on ITEM means the GROUP can add/remove bundles. BUNDLE is container for BITSTREAMS.
• READ/WRITE policies influence the objects themselves. READ on ITEM means view item, WRITE on ITEM means modify the ITEM (if you want to REMOVE the ITEM or ADD a new ITEM you need ADD/REMOVE on COLLECTION (see the point above))
• Policies are not transitive
• Policies are inherited on create
• Policies updates do not propagate
• There are hacks outside of this policy framework to allow submitters edit the metadata

Scenarios

Adding files

1. Submission without files, allow the submitter to add files later:

• Empty submission doesn't contain bundles. You need to allow ADD on ITEM. This will be inherited by the bundle that was automatically created, the bitstream appears in this new bundle
• Step-by-step: authenticate to admin account, go to item view of the submission, click Edit this item, click Authorizations and Add a new Item policy

2. Submission with files, allow the submitter to add more:

   • There is bundle called ORIGINAL, you need to allow ADD on this bundle.

Removing files

1. Submission without files, allow the submitter to add + remove files later:

• as in adding files 1. you need to allow ADD/REMOVE on ITEM and this will be inherited

2. Submission with files:

• Again you need to allow REMOVE on ORIGINAL bundle. Adding REMOVE to ITEM at this point is not enough as the policy is not transitive and the update will not propagate.