Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

Anchor
proposal
proposal
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.

Anchor
sprint3
sprint3
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.

Anchor
tasks
tasks
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

...

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

 

Anchor
cases
cases
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.  

...

  • 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. 

Anchor
problems
problems
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.

Anchor
usered
usered
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'