Per discussion within the parent task, please move the existing acl*security_volunteer policy outside of its current acl*security parent policy. Please also ensure that members of acl*security_volunteer can view any security-protected task to which the policy is applied. Please also add the following, existing members of acl*security_volunteer to acl*security_developer instead, for the time being:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Restricted Task | |||||
| In Progress | None | T305890 Move the #acl_security_volunteer policy outside of #acl_security |
To prevent confusion it may be better to archive the current project and then create a new ACL project.
AFAIK we cannot convert subprojects into projects (and the other way round is also very bumpy), so this would be setting up a new parent project via this form, then adding members. (And it's not clear to me yet who/when to apply that new ACL policy on tasks afterwards in some batch-editing way; might be manual or need API.)
Thanks @Aklapper !
I found the same thing after some digging.
Migrating projects is done via a script called move_beneath.php that was hacked together from upstream. The same task also offers the important caveat to making a project into a subproject, "this script mutates data immediately, without prompting, and can not be undone." Creating a new project seems to be the only way to achieve this.
Can you say more about the difficulties you foresee here? I'm imagining someone builds a maniphest search, bulk edits, silences, and clicks go—are there special considerations in this case (other than figuring out exactly what tasks need the new acl*project tag)?
Could we do something like:
The intention here is to create a new policy for volunteers who would like security access but may struggle to be granted full access due to various rules and regulations. The new tag would be applied to various tasks by the Security-Team during our weekly clinic (where we triage all new security tasks) and to existing security-protected tasks when we do our monthly Phabricator clean-up sessions. But it would allow access to a much smaller set of curated, security-protected tasks than the entirety of what exists within Phabricator.
Ensure that it grants access to security-protected tasks within Phabricator, whenever it is applied to a task.
This fights the model of phabricator a bit. Quoting the phab docs:
An important rule to understand about projects is that adding or removing projects to an object never affects who can see the object.
...
Note that you can write policy rules which restrict capabilities to members of a specific project or set of projects, but you do this by editing an object's policies and adding rules based on project membership, not by tagging or untagging the object with projects.
Phabricator's philosophy here is that it's hard to understand the intent of adding a tag.
I can sympathize with that, sure. But this is a use-case that upstream folks likely didn't envision (I find it bizarre myself) but due to certain legal constraints and risk acceptance by various leadership levels at the WMF, is really the only path forward that the Security-Team has found to provide more volunteer and community contributors access to a set of security-protected tasks in relation to the all-or-nothing status quo. This approach was outlined a bit in T305731 and discussed more thoroughly within T302686 and T298997. I'm also happy to have a more in-depth chat with anybody to further discuss or work through solutions for this issue.
What about using a herald rule with a custom action:
This would not fight phab as much, since the actual presence of the tag doesn't affect the visibility, its just the herald rule
Or, without needing a custom action, just add the members of the acl as subscribers
I think this would mostly work, if it's a much easier solution to implement. The only issue I see is that if someone mistakenly or maliciously removes the acl (or users subbed to the task via the herald rule) then it would likely be difficult to notice that and they would just remain unaware of the protected task. That's not that terrible of an issue though, IMO.
When adding #acl_security_volunteers changes the view policy so that members of that project can view the task, shouldn't it then be possible that removing the project itself has no effect, but the view policy has to be changed manually if the members of acl_security_volunteers should not be able to see the task anymore?
Given that T298784 has been reopened, I'm going to backlog this task for now, as we're currently revisiting our volunteer security access policies. If not much comes of that discussion, we can move this back to in progress.