Project

General

Profile

Actions

Feature #19269

open

"All users" group membership should be RW, not RO

Added by Tom Clegg about 1 month ago. Updated about 16 hours ago.

Status:
In Progress
Priority:
Normal
Assigned To:
Category:
-
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
(Total: 0.00 h)
Story points:
-

Description

This will make it easy to make a project or collection world-writable. (Currently, one would need to create a role group and add everyone to it, including all future new users.)

IIRC (TC) the reason why the user→"all users" group link is read-only (can_read) is to prevent users from modifying/renaming the role group record itself. If that's the only reason, it seems like we could prevent that with a special case in the update permission check: non-admin user cannot update the well-known "all users" group.


Subtasks 1 (1 open0 closed)

Task #19288: ReviewNewLucas Di Pentima

Actions
Actions #1

Updated by Tom Clegg 28 days ago

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

Actions #2

Updated by Peter Amstutz 28 days ago

  • Target version set to 2022-08-03 Sprint
Actions #3

Updated by Tom Clegg 28 days ago

  • Assigned To set to Tom Clegg
Actions #4

Updated by Tom Clegg 22 days ago

  • Status changed from New to In Progress
Actions #5

Updated by Tom Clegg 17 days ago

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.

Actions #6

Updated by Tom Clegg 16 days ago

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

Actions #7

Updated by Peter Amstutz 15 days ago

  • Target version changed from 2022-08-03 Sprint to 2022-08-17 sprint
Actions #8

Updated by Peter Amstutz 14 days ago

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

Actions #9

Updated by Tom Clegg 14 days ago

specifically (1b)

Actions #10

Updated by Peter Amstutz about 16 hours ago

  • Target version changed from 2022-08-17 sprint to 2022-08-31 sprint
Actions

Also available in: Atom PDF