The Proposal
Short-term plan for Sprint 3
Tasks Required to Implement the Plan
Use Cases
Problematic cases
Areas Requiring User Education and/or Notification

The Proposal

In order to offer the most opportunities for sharing, but still maintain our contract of privacy with the end users, we propose the following strategy:

1. Thumbnails are no longer public. They will be visible or not dependent on the users rights over that item. This is only relevant in albums and slideshows.
2. Users can create albums or slideshows of any content they have read access over without restriction.
3. When the user goes to share the album/ss, the IME sets access on items that user has admin rights on; IME reports on any it could not set access on - reports that user will not be able to see it, OR that user will be able to see it because already has access to that item. In second case, we should note that we cannot guarantee it will stay accessible.
4. IME will also create record in the item representing any item-level access right and the context in which it is relevant. It will use this record to manage these rights when adding/removing them. IME workflow:
   1.    For each item in the album/ss, check if admin over. If YES, set item-level right, and record album-right in item record.
   2.    If NO, query to see if the user being given privileges already has access to that item. Report on the failure, whether it will be visible or not.
5. Any items later added to the album should be also given all relevant item-level privileges where they can be, and the user should be notified if the item(s) cannot be shared.
6. Any items that are removed, item-level access record should be removed, and item-level access should be removed if it is not present in some other context.

Short-term plan for Sprint 3:

• Rollback the thumbnail changes so that they are public again. Put changes back in when we can do the whole plan.

Tasks Required to Implement the Plan:

• Updating data on production server:
  • Qing needs to write a script to make thumbnail have access rights on production server

• • To update production server data on albums and slideshows, we can manually go in as super admin, remove privileges, and add them back in, let the system do the updating.

• Qing must implement the contextual access rights tracking
• Front end must implement the messaging
• Need to implement ownable service, for system to be able to control full access rights.
• Areas to explore what needs to be done:
  • dragging items to albums/slideshows -- any messaging required? what needs to happen on the backend?

 
Use cases:

SAP & HST:

• Judy uploads files to a library. She creates an album, which she shares with Jamie, making Jamie an admin of the album. Jamie makes changes, and then is ready to let the publisher know that they are ready. Jamie then gives the publisher download rights to the album (which she can do because she is an admin over the album, and therefore all the items in it).
• OR, if Judy only gave Jamie WRITE access on the album, when Jamie goes to share it with the publisher, she will receive a message saying she cannot share the items in the album. Judy must give Jamie admin rights over the album (or over the content in her library) so Jamie can share it.
• This seems acceptable: everyone on the team needs to be an admin of the content. Once we have groups, this will be very easy to make work.  

Stellar:

• Professor A gathers content from Rotch, and from Vue, and creates a slideshow. She then shares it with her students. Students WILL be able to see all the content, because Rotch and Vue content is public, even though she does not have admin rights over that content. QUESTION: how should we handle the messaging? don't want to alarm people unnecessarily.
• Professor B has a library, and gives Professor A read access. Professor A takes some content from Prof B's library, and adds it to her slideshow. She is notified that this content will NOT be visible to her students, and she must ask Professor B to make the content public if it is to be shareable. Professor B can either make Professor A an admin of his library, which he probably will not want to do, OR he can create an album of the items that Professor A wants, and give Professor A admin rights over the album. In this way, albums can be used to manage access on subsets of items.
  

PSB:

• User called "PSB-Seller" (or something like that) is admin over all content. All content is readable by public.
• Public User creates an album, and drags images to it. They pay PSB and reference the album name (might need some kind of generic naming/number in albums). PSB should already be able to see all the albums. Maybe this means they go in as super-admin, maybe its some sort of PSB-specific customization. They then set 'download' on the album for that user, and the user can download the items. When PSB wants to restrict access, they remove download for that user. [Problem: if user created the album, download icon will be available. However, they wont actually get the items when the go to download them -- they'll get an error. This case works as it should, but might be a bit confusing.]

 Public Domain:

• There was a big party, and 7 people each upload pictures to their personal libraries. All of their libraries are private. One of them creates an album, and gives all 7 people admin rights on that album. Then everyone can drag images to the album, and choose to share all the pictures with others.
• Alternatively, the creator of the album could just give others WRITE on the album. When they drag their content there, they are giving the owner of the album admin rights over their items. Only the owner of the album can share it with others. The owner of the album can successfully share the album with anyone he wants to, even though he does not own the content. This is because he is the admin of all content in the album -- the others gave him admin rights by dragging  their items there.
  
  

Need to lock down suspected bad content:

• Need to implement ownable service in backend, so we can remove the owner's permissions over that content while its being researched.
• 2 cases: content is found out to be truly illegal, and there could be legal proceedings; OR content is found to be acceptable, all previous rights should be reinstated. 
  
  

Problematic cases:

These are cases that raise issues we need to address, either in our model, or in other ways to avoid certain problems.

• User A gives User B read on their library. User A drags items from his library to an album that User B is the admin of. When User B goes to User A's library, she can delete the items that User A put in the album, because she is an admin over those items.
  • I think this is a loophole we should close. Honestly, item-level access controls really should only apply to items in albums and slideshows, not in the library. I know this is not how alfresco works, though. To my mind, within libraries only the inherited rights should be relevant, not the item-level rights.
  • Same scenario is also relevant with regards to editing metadata on an item.

Areas Requiring User Education and/or Notification

• Users need to become aware that when they drag an item from their library to an album or slideshow, it *could* end up being shared by others, depending on who has admin rights on that album or slideshow. I do not see this as a problem, I see it as a feature. But it is something we need to be sure that the user understands.
  • Could be both annoying and overkill, but one possibility is to notify users whenever they drag anything to an item or slideshow -- or even just do it the first time they drag to a given item or slideshow, saying 'user a now has admin rights over your items; if this is not what you want, remove the items from the slideshow/library'