The following use case is causing concern:
User has a library that is not shared. They create an album, copying items from their private library. They share the album. Expectation would be that the thumbnails as they shown in the album would be visible. In actuality, they would not be -- instead a "not authorized" icon would show up, now that the thumbnail is tied to access rights on the item.
One possible solution:
- When setting access on an album, user should have the option of also applying those same rights onto all items within the album that they are the owner of (ie, that they have admin access over).
- This implies that when they remove access to an album, they should also have the option of removing the item-level rights on all the items within the album.
This is potentially messy in a number of ways.
- The item access is (probably) still also tied to its container library. There could be a mismatch which causes user confusion.
- What happens to items that are added to the album later? Or if items are removed
An extreme option would be to totally redesign how albums work, and make them actually, on the backend, libraries with special properties -- users can only copy items to them, not upload directly, and not move things to them; and they would not be searchable. Then, the owner of the album really does have full rights over all items within it, which is the user's expectation. This is a huge change, and may not even be advisable.
What it comes down to is the user's expectation that giving others access to an album should apply to the items within that album -- this is not how our model works. While the thumbnails, etc were public, the problem with albums was not as visible. It is now exposed, and likely to cause significant user complaint.