Content
Updated by Oliver Günther 1 day ago
**As a** system manager at Helmholtz-Zentrum Berlin using OpenProject
**I want** my project admins to only see the names of the users that are in the same group _**or project**_.
**So that** I fully implement the GDPR when using OpenProject.
The goal is to further reduce the visibility of all OpenProject users in the systems, so that varying user groups can access the system and invite each other without finding out about the entire scope of the instances.
**Acceptance criteria**
* The visibility of users permissions is separated
* UNCHANGED existing global permission "Edit users" - User can see all users in the instance
* Edit users has a dependency on View users
* Migration added to grant View users to everyone with Edit users
* NEW global permission `view_all_principals` (View "View all users and groups) users" - User can see all users in the instance
* Provide system to assign default global role, similar to builtin nonmember roles
* Migration to add `view_all_principals` (View "View all users and groups) users" as a default role to those that currently have "Manage members" (backwards compatibility)
* NEW permission "Invite members by email"
* This removes the current admin-only permission to invite users
* CHANGED existing project permission "Manage members" - No longer connected to user visibility, visibility is controlled through other permissions
* User can invite new users, and autocomplete those that they can see
* They will see users of projects they share a membership in (any permission in that project)
* They will see users in the same groups as they are (new default behavior without permission)
* Unless they have "View all users", They do not see other users, but can autocomplete them via email, same as invitation flow
* CHANGED visibility of /users/:id profile endpoint
* Only users that are visible according to the above rules
* CHANGED visibility of user popup according to the above rules
* UNCHANGED visibility of user activities within a project (e.g., being assigned, comments, previous activity)
<br>
<br>
* When adding a new member to a project there are three cases:
* Case 1: The user is already in the same group or project scope with the invited user, or the user has View all Users permission. So the inviting user can see the user's name.
* Case 2: The invited user is not in OpenProject yet.
* When you have permission to invite: The user will be created as an invited user.
* You see a label in the autocompleter "Invite <email>" that you can select and confirm
* OpenProject will send an email to that user to invite them to log in to the system
* Case 3: The user is in the system not in the same group with the invited user:
* The user has _Invite members by email_ permission
* The inviting user has the permission to invite users
* There is no autocompletion when starting typing.
* The flow appears as if Case 2
* Upon successful "invitation", the user is made a member of the project
* Case 4: The user is in the system not in the same group with the invited user:
* The user **does not have** _Invite members by email_ permission
* The system does not offer inviting for existing or new users
* \-> User can only add those that he sees (Case 1)
* Sharing work packages
* The same cases apply as above for invitation
* Global or inline (e.g.., assignee autocompleter) user invitation flow
* It uses a different endpoints (principal vs member autocompleter)
* The same cases apply as above
<br>
* This new permission introduces additional complexity in the permission system
* A dependency has been introduced to make this clear. e.g., when trying to assign `manage_user` , `view_all_principals` We will also have ask for support by the UI/UX team to be selected
* A release notes entry will be made documenting this change help clean up the new permissions into a format that is easier understandable
<br>
**Rough estimation**
* Default global role + migration for "View all users" (10 -15 PD)
* Reducing of current "Manage members" permissions (5 PD)
* Invitation-like flow for invisible users on members page (10 - 15 PD)
* New permission "Invite users by email" (5 PD)
* Adapt sharing and global invitation flows to new permissions (3 - 8PD)
<figure class="image op-uc-figure"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/104757/content"></div></figure>
**Current solution concept used for Nextcloud**
* Nextcloud admin has the option to configure user search auto completion in [share settings](https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/file_sharing_configuration.html) "Privacy settings for sharing"
* Parent setting: "Allow username autocompletion in share dialog and allow access to the system address book"
* \-> Allows any autocompletion in the share dialog. If not set, there are no suggestions displayed in share dialog when typing.
* Child setting: "Allow username autocompletion to users within the same groups and limit system address books to users in the same groups"
* \-> Only allows autocompletion when users are in the same group as the user who is typing in the share dialog.
* Setting: "Allow autocompletion when entering the full name or email address (ignoring the missing phonebook match and being in the same group)
* \-> Allows for autocompletion when the typing user enters the full name or email address of another user in the share dialog. (e.g. enter "john.smith@mydomain.tld" -> autocompletion will find user "John Smith")
**I want** my project admins to only see the names of the users that are in the same group _**or project**_.
**So that** I fully implement the GDPR when using OpenProject.
The goal is to further reduce the visibility of all OpenProject users in the systems, so that varying user groups can access the system and invite each other without finding out about the entire scope of the instances.
**Acceptance criteria**
* The visibility of users permissions is separated
* UNCHANGED existing global permission "Edit users" - User can see all users in the instance
* Edit users has a dependency on View users
* Migration added to grant View users to everyone with Edit users
* NEW global permission `view_all_principals` (View
* Provide system to assign default global role, similar to builtin nonmember roles
* Migration to add `view_all_principals` (View
* NEW permission "Invite members by email"
* This removes the current admin-only permission to invite users
* CHANGED existing project permission "Manage members" - No longer connected to user visibility, visibility is controlled through other permissions
* User can invite new users, and autocomplete those that they can see
* They will see users of projects they share a membership in (any permission in that project)
* They will see users in the same groups as they are (new default behavior without permission)
* Unless they have "View all users", They do not see other users, but can autocomplete them via email, same as invitation flow
* CHANGED visibility of /users/:id profile endpoint
* Only users that are visible according to the above rules
* CHANGED visibility of user popup according to the above rules
* UNCHANGED visibility of user activities within a project (e.g., being assigned, comments, previous activity)
<br>
<br>
* When adding a new member to a project there are three cases:
* Case 1: The user is already in the same group or project scope with the invited user, or the user has View all Users permission. So the inviting user can see the user's name.
* Case 2: The invited user is not in OpenProject yet.
* When you have permission to invite: The user will be created as an invited user.
* You see a label in the autocompleter "Invite <email>" that you can select and confirm
* OpenProject will send an email to that user to invite them to log in to the system
* Case 3: The user is in the system not in the same group with the invited user:
* The user has _Invite members by email_ permission
* The inviting user has the permission to invite users
* There is no autocompletion when starting typing.
* The flow appears as if Case 2
* Upon successful "invitation", the user is made a member of the project
* Case 4: The user is in the system not in the same group with the invited user:
* The user **does not have** _Invite members by email_ permission
* The system does not offer inviting for existing or new users
* \-> User can only add those that he sees (Case 1)
* Sharing work packages
* The same cases apply as above for invitation
* Global or inline (e.g.., assignee autocompleter) user invitation flow
* It uses a different endpoints (principal vs member autocompleter)
* The same cases apply as above
<br>
* This new permission introduces additional complexity in the permission system
* A dependency has been introduced to make this clear. e.g., when trying to assign `manage_user` , `view_all_principals`
* A release notes entry will be made documenting this change
<br>
**Rough estimation**
* Default global role + migration for "View all users" (10 -15 PD)
* Reducing of current "Manage members" permissions (5 PD)
* Invitation-like flow for invisible users on members page (10 - 15 PD)
* New permission "Invite users by email" (5 PD)
* Adapt sharing and global invitation flows to new permissions (3 - 8PD)
<figure class="image op-uc-figure"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/104757/content"></div></figure>
**Current solution concept used for Nextcloud**
* Nextcloud admin has the option to configure user search auto completion in [share settings](https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/file_sharing_configuration.html) "Privacy settings for sharing"
* Parent setting: "Allow username autocompletion in share dialog and allow access to the system address book"
* \-> Allows any autocompletion in the share dialog. If not set, there are no suggestions displayed in share dialog when typing.
* Child setting: "Allow username autocompletion to users within the same groups and limit system address books to users in the same groups"
* \-> Only allows autocompletion when users are in the same group as the user who is typing in the share dialog.
* Setting: "Allow autocompletion when entering the full name or email address (ignoring the missing phonebook match and being in the same group)
* \-> Allows for autocompletion when the typing user enters the full name or email address of another user in the share dialog. (e.g. enter "john.smith@mydomain.tld" -> autocompletion will find user "John Smith")