Ability to invite users to a confidential issue
Confidential issues can be viewed by the author (if they can view the project), project members with at least the "Reporter" role (which excludes users with the "Guest" role), and assignees.
It would be useful to be able to give someone access to a specific confidential issue, even if they aren't any of those three things (author, project reporter or assignee). Since an issue can have multiple assignees, it sounds natural to add a random user to a confidential issue by assigning the issue to them, but as described by @smcgivern in https://gitlab.com/gitlab-org/gitlab-ce/issues/40545, this does not actually work:
Combined with multiple assignees, this makes adding people to a confidential issue by assigning them quite natural.
However, it doesn't work:
You can't assign a non-project-member, non-participant using the dropdown in the sidebar. You can type their username in, but then nothing.
Even if you could do that (or used quick actions), we don't allow someone to be assigned to an issue they can't see. But they won't be able to see it until they're assigned, so it's a chicken-and-egg problem.
Because we do not want to change the rules around assignment, we need to introduce a new concept: the confidential issue invitee. The idea is that any user who can view the project's issue tracker, but who cannot currently view a confidential issue, can be added as an invitee, which will allow them to read the issue, comment on the issue, and receive notifications of activity on the issue.
Just like adding and removing assignees, it would ideally be possible to invite and uninvite users using the issue sidebar, the issue API, and /invite @user
and /uninvite @user
quick actions. For the sake of simplicity, we can start out with only quick actions, and leave the sidebar and API for future iterations. Inviting or uninviting someone should also result in a "system note" (event) being added to the issue's discussion stream. Until we have a proper "Invitees" section in the sidebar, we could include invitees under "participants", so that it's clear to everyone who's reading along.
To summarize, the first iteration of the feature should have (in order of priority, as time allows):
- The concept of confidential issue invitees, with access to the confidential issue
-
/invite
and/uninvite
quick actions - A system note "event" when a user is (un)invited
- Invitees included in "participants"
This feature will add some complexity to the query that determines whether a user can view a confidential issue, so to simplify it and reduce performance impact, it may be desirable to automatically add all issue assignees to the hypothetical new confidential_issue_invitees
table and only use that table in the query (see https://gitlab.com/gitlab-org/gitlab-ce/issues/41973#note_54945290 and further), but this can wait until a future iteration of the implementation. If we go this route, it should not be possible to uninvite a confidential issue invitee who is also an assignee, and unassigning someone should not automatically uninvite them.
Original issue description
Like with Google docs where you can share single document with specific users without exposing the rest of the docs.
Use case: We have confidential information that needs to be discussed with people outside of the company. Those users have GitLab account but adding them to the project will expose all other confidential issues to them.