Idea #2044
Updated by Tom Clegg about 10 years ago
Acceptance criteria: * Share button opens a dialog box with a list of users and groups who can already read/write read this group. collection. * Visual indication of which users/groups *you* have given permission to read. * Click to un-share with a user/group. user whose permission was granted by you. This change does not get committed immediately. * Start typing name or email address to bring up an auto-complete list (e.g., "PGP" or "Tom"). _(This requires changes to @users.list@ api permissions.)_ * Choose a user or group from the list. * The chosen user is added to the list, but permission is not assigned yet. * Click "Save changes" "Done" to commit. * Click "Cancel" to abandon all modifications since opening dialog. * Click Share button again to refresh current permissions and adjust from there. * Screen captures for demonstration purposes. Not necessary [yet]: * Don't auto-refresh while the dialog is open, or worry about race conditions with other users/windows. Aside: This is a special case of a generic "Share" mechanism needed in Workbench. * Collections do not have "write" permission. * Collections are always owned by system_user. * When you create a collection, you get a free permission/can_read link which is owned by system_user. * Other than Collections, everything else should act pretty much the same as Groups. So -- hopefully sooner rather than later -- none of the Javascript or Workbench-server support will be specific to Groups. (But if it makes the difference between getting it done or not, "only groups are essential for this story" is the rule.) Other notes: * You can't necessarily tell whether another user can already read your collection (e.g., that user saved a copy independently). * You can't necessarily tell whether another user is a member of a group.