Arvados

Also: updating the name/description/etc of a role group should require can_manage (or admin), not just can_write.

Branch in progress: 19269-group-permissions @ 68a98cf559d6743bf4d0e829932951cf26c87fff -- developer-run-tests: #3251

• role groups can only be modified by admins, regardless of any permission links (note we were already ensuring role groups are owned by system user)
• users#setup uses can_manage for the user->all_users_group permission link
• migration upgrades existing user->all_users_group permission links from can_read to can_manage

This makes "share read/write with All Users" work as expected.

However, it does create a different oddity: a non-admin user can create a role (as before), but then cannot modify or delete it.

We could address this by preventing non-admin users from creating new role groups.

We should add a release note to alert admins that existing "shared at write/manage level with all users" permissions, which previously granted only read-only permission, will start grant write/manage permission after upgrading.

"updating the name/description/etc of a role group should require can_manage (or admin), not just can_write"

Assuming we don't make a bigger change to the permission system, like introducing a "can_access_via" permission type, I think we have these options:

1. updating role requires can_manage¶

(1a) "add user to group" uses a can_manage link (unchanged)

Members of a role can change the role's name/description

(1b) we change membership to use a can_write link

Members of a role cannot change the role's name/description -- but "share with role X at manage level" doesn't work any more (shares are automatically restricted to can_write level)

2. updating role requires admin¶

(2a) Non-admin users can create role groups (unchanged)

It's weird that a non-admin user can create a new role group, but can't modify or delete it.

(2b) Only admins can create role groups

It's inconvenient that everything to do with role groups (create/modify/delete) must be done by an admin user.

From discussion, we decided option (1) is least surprising.

specifically (1b)

updating role requires can_manage

...was done in #16007

19269-all-users-writable @ e4c83a3ebe3b16c16f604b3b0968ce5600b7ab64 -- developer-run-tests: #3272

Changes the automatic "all users" role permissions (existing ones and new ones added by "user setup") from can_read to can_write.

Code LGTM, thanks.

One thing that I was looking for is see if we need to update some documentation, I'm not sure if we explain the special case of role groups somewhere.

Indeed, I couldn't find any mention of that. Added in the "special cases" section of Architecture > Permission Model.