...
- Item-specific permissions can be set from within a library or an album or search result (but not within a slideshow)
- Items always still inherit permissions from the library they live in; you can use item-specific permissions to add privileges, but not to take away privileges.
- Album and Slideshow permissions will have NO impact on, or relationship to item-specific permissions. So, if you change privileges on an alb/ss, it has no impact on the items it contains.
- Users must explicitly set permissions on items. They do this by selecting one or more items in the thumbnail window (in either a library or album), and clicking the 'share' icon that we will add to the bottom of the screen, with the other item-level icons.
- In albums, slideshows, and search results, there will be the option of applying "batch permissions" on all items.
Wiki Markup \[contradiction with first item? ok to batch set permissions within slideshow, but not set individual permissions within slideshow?\]
- the domain admin can take ownership of a library or an item. If domain admin wants to take ownership of an item, he/she has the option of remove the library inheritance. This is used to limit access to questionable contents. For example, if user A has some images in his personal library that violates our term of usage, a domain admin can take ownership of those images and also remove the library inheritance, so even user A will not have access to those images.
...
- In order to be able to take away privileges once they have been given, we will have to make thumbnails protected in albums and slideshows. In libraries and search results, thumbnails will be public. There will be 2 different URLs for thumbnails: one is the publicly accessible url, over http, that goes directly to alfresco. The other URL will go to the IME, and will be over https. For example:
- Public URL: http://isda-thalia6.mit.edu:8080/alfresco/guestDownload/direct/workspace/TEST/ac05bad4-7cba-11dc-a3e8-abc6d12769f5/thumbnail (or /medium or /large)
- Protected URL: https://hst.thalia.mit.edu/item/ac05bad4-7cba-11dc-a3e8-abc6d12769f5/map/b1de2507-7cba-11dc-a3e8-abc6d12769f5/thumbnail; (or /medium or /large) The URL contains both item id and the album/ss id. We will use the album/ss id to find the album/ss owner. It guarantees that the user has at lease "viewer" permission on the album/ss. If the owner is different from the user, We also double check that the owner still has full admin rights over the item and then we use the owner's credential to retrieve the item thumbnail/medium/large. If the owner is the same as the user, we still use the user's credential to retrieve the item thumbnail/medium/large.
- If READ privileges on items have been revoked for the album/ss owner, then everyone (including the owner) will see the 'not authorized' icon instead of the image. If ADMIN or WRITE privileges have been revoked, but READ remains, the items will still be visible to the owner only.
- If Admin privileges on the items have been revoked for the album/ss owner, then only the owner can see the items in the slideshow. All other users will get "not authorized". In a way, the shared album becomes a personal album. Also the owner will not be able to further share the album/ss.
I think it is still possible, see the text under protected url]Wiki Markup \[assuming that we are authenticating items as the album owner, this is not possible to implement, even though its the ideal behavior\.
- In albums and slideshows, we will not put the URL to the items in the xml. Instead, we will construct the URL from the item id and album/ss id. The images will be served over https, which will have performance implications. But it allows us to enforce the access restrictions in the case where someone grants share rights to a user, that user shares the image with others, it gets into various albums and slideshows, and then the owner of the content revokes the share privileges. In this case, once a privilege is revoked, the item will show the 'not authorized' icon.
...