Change Details

It is currently unclear to us how we should best set-up #Projects and #Spaces with regards to ease-of-use. 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. We have three cases of projects: 1. Secret projects - No one but members (internal or external) shall know about their existence and content. - With Visible-To:`#this_project` on the Project and a Space with the same Policy, this is easy to manage. 2. Open projects (mostly used internally) - Everyone in the organisation shall know about their existence and content. - With Visible-To:`#organisation` on the Project and a //default// Space with the same Policy, this can be dealt with. - Setting a //default Policy// of Visible-To:`#organisation` for all applications and object types helps to push people to use it. 3. Closed projects (mostly used together with external collaborators) - Everyone in the organisation and people related to the project shall know about their existence. - Only members (internal and external) shall see their content. - This can be dealt with by setting the Project's Visible-To to `Custom Policy(#organisation + #this_project)` and the Space's Visible-To to `#this_project`. - These projects are usually managed by the employees related to the project. - 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 1 secret Project. Case 1 secret projects appear to be the most simple to deal with, while we would actually like to encourage more openness, i.e. the opposite. Two solutions appear to me: 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`. NOTE: I tried to distinguish "projects" as in "things we are working on / working groups" from Phabricator "Projects" by means of capitalisation. This is a split-off from T9152#131767.

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.

It is currently unclear to us how we should best set-up #Projects and #Spaces with regards to ease-of-use.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. We have three cases of projects:# 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. SecretInternal projects - No - Everyone but members (internal or exin `#org` and `#org-internal)s` shall know about theirits existence and contenthave access to its objects. - With Visible-To:`#this_project` on the Project and a Space with- External users shall not have access to the same Policy, this is easy to managese objects. 2. Open projects (mostly used internally) - Everyone in the organisation`#org` and `#org-interns` shall know about theirits existence and contenthave access to its objects. - With Visible-To:`#organisation` on the P- Members of `#theproject and a //default// Space with the same Policy, this can be dealt with` shall also have full access to these objects. - Setting a //default Policy// of Visible-To:`#organisation` for all applications and object types helps to push people to use it- External users may be part of `#theproject`. 3. Closed projects (mostly used together with external collaborators) - Everyone in the organisation`#org` and people related to the project`#org-interns` shall know about theirits existence. - Only members (internal and external) shall see their contentof `#theproject` shall have access to its objects. - This can be dealt with by setting the Project's Visible-To to `Custom Policy(#organisation + #this_project)` and the Space's Visible-To to `#this_project`.External users may be part of `#theproject`. 4. Secret projects - These projects are usually managed by the employees related- Only members of `#theproject` shall know about its existence and have access to the proits objects. - 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 1 secret ProjectExternal users may be part of `#theproject`. Case 1 secret projects appear to be the most simple to deal with, while we would actually like to encourage more openness, i.eWhere necessary selected objects may have more restrictive access policies. Employees involved in the oppositeprojects shall manage the access policies themselves. Two solutions appear to me:# 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`. NOTE: I tried to distinguish "projects" as in "things we are working on / working groups" from Phabricator "Projects" by means of capitalisation.# Related Q76#A96, T3980, T9165, T9164, T3670, T9152, T4136#105802, T6802, T9021 This is a split-off from T9152#131767.