NOTE: This page is obsolete, see current Access ControlProposal

Libraries and Items
In addition to access controls on libraries, albums and slideshows, we will add access control on individual items.

The permissions options for items are the same as they are for libraries, with one addition. Items will have a flag to inherit parent library rights or not. If the user turns off inheritance from the library, then only the item's rights are used, and the parent library's permissions are ignored.

If we move or copy an item from library A to library B, the item will copy the inheritance flag and all the item specific permissions.

In addition to the current share button at the library level, we will add a share button in the main image window. The user can use this button to edit permission on one or more item(s) inside the library. If they select multiple items, the button will only be enabled if they have admin rights over ALL the selected items.
Issue: to do this in the UI, we'll need to query access rights on EACH item, so the UI knows what to do. This may be too much of a performance hit. Instead we may need to let them try, and have the backend tell them that they were allowed to do it on some, but not others.

Albums
Permissions on items within albums are distinct from the permissions on the album itself. There is not necessarily any relationship between them, except that read on an album gives the user a way to see the THUMBNAILS of given items, even if they do not have access over the actual item.

The fact that the album permission is not consistent with the item permission is likely to be a place where users get confused, but if we provide enough UI messaging and documentation, they will eventually get it.

On an album, we will have three permission levels "Read Album, Modify Album, Share Album". Download Album has no real meaning, because if you can read the album, then you should be able to see the contact sheet (there is no additional information in the contact sheet).
NOTE: Need to make it clear to users that giving anyone read access over an item means that the THUMBNAIL of that item could end up being widely distributed.

We will keep the current share button at the album level. The screen that comes up should have 2 parts, one to manage the album permissions, and one to do a bulk operation on all items in that album. This is to help the user understand that these are not the same things, and also to give them an easy way to change rights on all items.   

We will also add a share button at the main window. The user can use this button to edit permission on one or more items inside the album, if they have admin rights over that item or its parent library. It will look and act the same as it does if you click "share" on an item in a library.

We will add a download button at the main image window level in album view which functions the same as the one in library view, i.e. it will download the actual item. If multiple items are selected, the user will get a zip file of the source images.
NOTES: Also include metadata as tab delimited txt OR xml; Contact sheet would need to be gotten separately

We have download buttons at album level also. The user will have the option of downloading a contact sheets or downloading all images in a zip. There is no restriction on downloading the contact sheet. If you can view the album, you can download it as a contact sheet. The zip will contain only those images over which the user has download rights. All other images will be skipped. There should be some sort of summary notification like "Due to access restrictions, you only downloaded five out of ten images".

Ideally, we'd have a column in the list view that shows the user's access over any given item (just showing the most permissive right).  However, to do this, we would need to check the rights on each item individually, which would create a huge performance problem.

Slideshows
Download should only apply to downloading the whole slideshow; there is no reason to download items, or set access on items from within a slideshow.

Because slideshows only use thumbnails, if the user has read access over the items, then sharing the slideshow should not be an issue, because the thumbnails are public.

Conclusion
Other than moving the access control down to the item level, we are basically keeping our current access control model (ie, access control is determined by library+item, not by album). It is not possible to have items inherit access rights from both libraries and albums so our current access control model makes a lot of sense. As a result, we don't have to migrate access rights in our production environment.

USE-CASES
To review our proposed model and changes, let's map out behavior of the following screens/actions for each of the user stories listed below:
•    album-share
•    album-download

•    album-item-share
•    album-item-download

Possible scenarios within each use case:
•    Album where user has admin on all items (simplest case)
•    Album where user has admin on some but not all items

User Stories:
•    PSB

• Public user creates an album, and collects in it images they want to buy
• By some action specific to PSB, share on album is given to PSB-Staff, and an email is sent to the staff
• PSB-Staff wants to set download access on all items in that album for the given user

•    SAP & HST

• Department-Staff all have write and/or admin over album, not sure about all items in the album (should have, but might not by default; if not this is a workflow issue they need to address)
• Department-Staff share the album with an outside user, and give that outside user download on all items

•    Public Domain

• User creates an album of their stuff; they share it with a friend
• User does a search, and creates an album of search results; they have admin over some but not all items
• What is user's expectation in each case? What do they see in the album share window, and the item share windows?

•    Professor for classroom use

• Professor gathers images for many sources, some of which she has admin rights over, and some of which she doesn't
• Wants the class to be able to read all images for homework review (easy)
• Wants the class to choose 3 images to download, and do a project about. Tries to give download over all images to the whole class. What is her user experience, messaging about items that she cannot do this one, etc.
• Wants the class to be able to comment on all items (I know this is for later)

•    Mmedia

• "Resource" = our Library, and "Collection" = our Album
• They use our older model - have the item's parent resource set the access rights.
• They do not have "download" separate from "read", which simplifies the issue, and potential user confusion, greatly

•    Blocking bad content

• Content really was bad, needs to remain blocked, and need some kind of audit trail
• Was an error, need to be able to unblock and restore to how it was