I would like to use a private project for tracking administrative tasks for the CTO Team (Victoria, Joel, Kevin, and eng-admin). Some fraction of our tasks are sensitive and inappropriate to share publically.
Will do. Trying to understand and clarify the instruction:
Private: If you want a project with restricted access (ACL project/Space) whose tasks should not be public and only be accessible by a defined static group of people, create a task with Name, Project description, and Project type.
It seems like this should say something like, "create a task with Name, Project description, Project type, and also do the four bullet points under "Requesting a Space". Should I just move those steps up to the top? Would you ever request a Space other than in the context of Creating new projects/Project Type above?
I'm not quite following the differences between "Private project", "ACL project", and "Space". It seems like "Space" is a different kind of object, tasks can belong to both a space and other projects, and spaces have view policies that override other security. The docs then say that access to the space is defined via an ACL project, which I guess is a separate project that exists only to anchor a user list for the Space; why is that needed if Spaces already provide access lists? Lastly, is "Private Project" a different kind of project, or is that another way of referring to a Space with an associated ACL project?
Explain why there are repeatedly tasks in your project which should only be accessible by a defined group of people
CTO-Team regularly creates tasks with sensitive administrative or personnel issues that should not be visible outside of the team itself.
Please indicate the name that should be used for the space
Please identify the group lead (responsible for adding and removing people with access)
Please also describe which specific Phabricator usernames should be able to access objects in that space.
Would you ever request a Space other than in the context of Creating new projects/Project Type above?
Yes. A task can be both in a public project && in a Space and hence only visible to people who can access that Space (as Space policies are stronger than anything else). For example, Community-Liaisons have most of their tasks public and some private tasks in a Space. All these tasks are associated to the Community-Relations-Support project.
I'm not quite following the differences between "Private project", "ACL project", and "Space".
"Private projects" do not exist. I do not know where that term comes from. The rest of your comment is correct. :)
why is that needed if Spaces already provide access lists?
Changes to Spaces themselves require Phab admin rights. Hence we usually designate one or two people who decide on the membership of the ACL group/project and delegate control to them so that Phabricator admins don't have to intervene every time there is a change to the list of people who can access the Space.
Andre, I tried to clarify the instructions. The biggest issue was that there were two different sets of instructions for how to create a "private project", so I merged them. The second issue, for me, was the term "Private Project", which implies a Phabricator project with a special setting. I replaced that with "Project with limited access", which I think is more accurate for describing the three-entity convention we are using to effect "private projects".
Thanks. The problem is that Spaces are not projects with limited access. Spaces are completely independent from projects.
Edit: Ah sorry, I had missed parts of that wiki page edit. You make that clear enough, thanks!
Yes. I've called this WMF-CTO-Team because in theory there might be other CTOs out there in our movement. :)
- Regarding the project and its workboard:
- Public project WMF-CTO-Team-Backlog created.
- Regarding the Space (a Space is not a project and hence there is no workboard):
- For access control, created #acl*WMF-CTO-Team_policy_admins. This defines access to tasks in the Space.
- Created the private Space S14 ("WMF-CTO-Team"). Its View and Edit policy is intentionally set to #acl*WMF-CTO-Team_policy_admins and should not be changed.
- @JAufrecht can add/remove users (who can create and access tasks in S14) via editing the members of #acl*WMF-CTO-Team_policy_admins. Note that Phabricator admins could also add themselves (this is a fallback for when a team lead has left; we had that situation); if you watch the #acl*WMF-CTO-Team_policy_admins project you'd get a notification about such an action.
- Please do see Displaying and using a Space for more information. To create private tasks, use this task creation form: You must set Visible To: Space S14: WMF-CTO-Team to create private tasks only accessible to members of S14 and nobody else.
- For convenience, created Herald Rule H255: If Space is set to S14, add project: WMF-CTO-Team-Backlog. So tasks should end up on the workboard even if you forgot to add the project and only set the Space.
- Documented the creation of S14 on https://www.mediawiki.org/wiki/Phabricator/Spaces
- Please ask if things are unclear. Happy to help!
(just a reminder for Kevin/Joel/etc: any tasks in that space can not be seen by the rest of tech-mgt, so if there is a task you want us to view you'll have to add us to the space as well)