Page MenuHomePhabricator

Still, restricting access to tasks based on project membership
Closed, DeclinedPublic


T50 provides the basic security features, perhaps at a level which is good enough for the RT and Bugzilla migration. Still, let's go back to the original requirement:

It should be possible to define the default access level of all tasks within a project, and user should not be able to override them.

For instance, given a "Security" project, all tasks assigned to that project would automatically be private. Nobody should be able to create a ticket for this project publicly visible. Nobody should be able to make an existing task public, not even by mistake.

Currently you can assign a task to the Security project and it will still be public until the "Security" field is set to something different than "none".

(We could discuss whether removing the Security project should make a task public as well, but in my opinion this is just a little convenience for the Security team members, a minor feature that we can live without for now.)

For what is wort, upstream is planning to work on a definitive implementation of "Spaces", although there are no dates confirmed, or even suggested.

Event Timeline

Qgil assigned this task to mmodell.
Qgil raised the priority of this task from to Medium.
Qgil updated the task description. (Show Details)
Qgil added projects: Phabricator, acl*security.
Qgil changed Security from none to None.
Qgil added subscribers: Qgil, mmodell.

qgil: we changed to using the security field because projects are less discoverable and possibly violate

Yes, I'm not against the Security field. I'm just proposing that Security field status and project membership must be always aligned:

  • if the Security field is "none", then the Project field cannot include any private project
  • if the Security field is not "none", then the Project field must include the corresponding private project(s)

This is how Bugzilla and RT operate today, right? This is also consistent and safer from a project point of view, i.e. all the tasks listed under Security will always be private.

mmodell raised the priority of this task from Medium to High.Oct 14 2014, 12:01 AM
Qgil lowered the priority of this task from High to Medium.Nov 1 2014, 3:56 PM

As discussed in IRC, we agreed that at least for now the security field controls access and the projects are to be seen as tags for organization purposes. If you add something to the security project it won't automatically add the policy. That's what the security dropdown field is for.

Mmmok, but I bet we will need to revisit this if we ever want to offer "private projects". In the meantime, T823: Implement Phabricator Spaces is now resolved as Stalled.

fyi, after further discussion I have completely abandoned the idea of this task. In the short term, must be defined by their Security setting (the dropdown). There is hope that in the mid term upstream will implement namespaces that will allow their own policies. Users with permissions to access those namespaces will not have to bother about the policies of tasks one by one, because the default policies will be defined at a namespace level.