It is currently unclear to us how we should best set-up access control, also taking ease-of-use into account. Thus I am going to describe our use cases, so you can decide whether and how Phabricator can make our setup simple to manage.

On the words I use below:

• When I refer to "objects", I mean tasks, repositories, wiki pages, etc.
• I am trying to describe the problem in general terms, without jumping directly to Phabricator semantics.
  • Thus "project" does not refer to Phabricator Projects, but to some joined effort.
• Starting from Current "solution" I describe what we setup in Phabricator and how Phabricator might behave in the future to accomodate us, all using Phabricator semantics.
  • I try to differentiate the different meanings of "project" by capitalising when I refer to the Phabricator meaning.

Goal

In general we would like to have maximum possible visibility for everyone in the organisation, to make people actually work together. In some situations, though, we need to apply more care.

Preconditions

We have a main group #org that is fed by LDAP and a supplementary group #org-interns that cannot be found in LDAP. Then we have individual project specific groups #theproject which may also contain external users.

Use cases

We have four cases of projects we run / four types of object-sets:

1. Internal projects
   • Everyone in #org and #org-interns shall know about its existence and have access to its objects.
   • External users shall not have access to these objects.
2. Open projects
   • Everyone in #org and #org-interns shall know about its existence and have access to its objects.
   • Members of #theproject shall also have full access to these objects.
   • External users may be part of #theproject.
3. Closed projects
   • Everyone in #org and #org-interns shall know about its existence.
   • Only members of #theproject shall have access to its objects.
   • External users may be part of #theproject.
4. Secret projects
   • Only members of #theproject shall know about its existence and have access to its objects.
   • External users may be part of #theproject.

Where necessary selected objects may have more restrictive access policies. Employees involved in the projects shall manage the access policies themselves.

Question

What is the easiest way to map this to Phabricator semantics? What are easy default policies for every user?

Current "solution"

We created Projects #org (managed by LDAP), #org-interns (managed manually), and one Project #theproject for each use case (managed manually) and then went with the following:

1. Internal projects
   • Project:
     • Visible-To: CustomPolicy(#org + #org-interns)
   • Space:
     • Visible-To: same
   • Default policy for all applications and object types:
     • Visible-To: CustomPolicy(#org + #org-interns)
     • Helps to push people to use it.
2. Open projects
   • Project:
     • Visible-To: CustomPolicy(#org + #org-interns + #theproject)
   • Space:
     • Visible-To: same
3. Closed projects
   • Project:
     • Visible-To: CustomPolicy(#org + #org-interns + #theproject)
   • Space:
     • Visible-To: #theproject
4. Secret projects
   • Project:
     • Visible-To: #theproject
   • Space:
     • Visible-To: same

Setting a Custom Policy is rather bothersome and not as obvious as setting a Project-style visibility. So what happens here is that people just lock down the Project entirely, as if it was a case 3 secret project, because that appears to be the most simple to deal with. Actually we would like to encourage more openness, i.e. the opposite.

Ideas how to solve this

1. Simplify the Policy control UI (e.g. Visible-To fields) to make combining multiple projects easier. Basically making Custom Policies more accessible.
2. Allow to define Policy templates (e.g. "open", "closed", "secret" as explained above). If a user selects this from the Policy control (e.g. Visible-To field), he just has to fill in the name of one Project in addition to #organisation.

Related

Q76#A96, T3980, T9165, T9164, T3670, T9152, T4136#105802, T6802, T9021

This is a split-off from T9152#131767.