See T13602 for modern followup, recent changes, and plans.

See also PHI1987 for another case of this.

Spaces have been working great for my install. The only real place where they're lacking I think arises from their coarseness/mutual-exclusivity.

D19549 added Spaces support to projects.

In Barcelona we're looking at the same problem: how to deactive Spaces? After archiving all spaces, the UI still keeps on showing the Space dropdown with default Space. We would be glad to simplify life of our users, and haven't seen the added value of Spaces as such. If anyone could give us a hint that would be greatly appreciated. Thanks in advance!

I don't think this or T12421 are valid use cases, for reasons described in T12421, and don't plan to support them.

I'm going to wontfix this. Functionally, everything is incorrect on the batch editor on a new install, if you have no users, no projects, no spaces. These don't seem to be too confusing to understand.

T4411 discusses some similar issues, although it predates Spaces and focuses on subscribers rather than assignees.

I had indeed implemented precisely that herald rule once I realized that these diffs were being created without repository info attached. I also added repository.callsign to /etc/arcconfig to eliminate the problem going forward.

We've seen a couple of flavors of this from @swisspol, too. Although the symptom there is a little different (not a policy issue, exactly), the root cause is mostly similar. In particular, we saw:

I'm going to merge this into T11580 because I think that describes what remains here.

@PicoCreator:

1. Paste the patch into a $FILE
2. cd $PHABRICATOR_SRC
3. patch -p1 < $FILE

@devurandom - I am facing a similar problem in my installation regarding "corporate secrets". How to I get this and perhaps other similar patches up and running?

@avivey (this is me testing it again) : Or perhaps the search is just taking .... forever .... XD

I do notice that this is actually in place on this site

what? I'm pretty sure that there's no way to do it at all...

@revi This third party tool no longer exists, the two links are broken and the latest commit at https://github.com/haskell-infra/libphutil-haskell removed the changes:

Just to add: in a big organizations Spaces can be used to divide different legal entities in a group (or big departments).
With this use most probably the majority of the users will belong just to one space, and they will just see the (default) "public" space and their own one. That means that in this case the majority of the users will not even need the switch, but just the possibility to configure the default space for new objects to their own one (not the default "public" space).
The user configurable parameter for the default space for the new objects creation can be anyway a first step in implementing then the full functionality of Space switching.

@chad : Thank you for your answer, that is very helpful. I will wait for custom forms on workboards.

I would recommend creating a custom Maniphest form and requiring people who need to create tasks in those spaces, use those forms from the Quick Create menu. Custom forms are not currently available on Workboards, they will be at some point.

Maybe I have not understand this and I could also not found any documentation for this topic.

Got you. Hope to perhaps see this feature implemented at some point in the future then, as it would be a big help to us on our client projects.

"project" there just the noun, not "Project-object", but we could probably pick a different word to avoid ambiguity.

Ah I see, apologies. As the Spaces user guide lists one of the possible use cases for Spaces as:

At the moment this is not implemented yet, so this is a feature request, not a bug report.

There is not, and never will be. Associated projects never affect policies, so there is no possibility to make them start affecting policies. I'm not sure what's unclear about this.

Yes, I understood the general behavior. I also read this documentation. What I could not find, however, was if there is any possibility to set tasks visibility by standard based on their associated project.

By design, changing projects never affects policies. See the documentation here:

I am also unsure about how to use spaces if they cannot be applied projects.

You can now customize "Create" forms and prefill (and, optionally, lock) their policies. See:

Yeah, use phid.lookup.

You can look up the PHID with phid.lookup.

T5046 has a specific case of this causing particularly questionable behavior when doing HTTP clones -- since the object is totally hidden, you don't get prompted for credentials.

after two users abused this to hide important tasks from developers

The worst case scenario was not real, but some time ago I was admin at a instance with public registration. We disabled the possibilty to let users adjust the task policys, after two users abused this to hide important tasks from developers. Sure, we restored this tasks by bin/policy, but we had first to find out, which numbers the tasks had, so we had to insert time in a problem, that can be easily fixed. After this, we disabled the ability to change tasks poliycs for unstrusted users. The problem now, is, that if new users have tasks with confidential informations, they need to contact us at another way, which means more work too, but makes existing tasks more secure. My proposal above has the advantage, that they can report confidetal data, if they change the space, but they had no change to hide data from us, and mass abuse can reverted by a bulk edit.

Is this an actual problem you've experienced, or purely hypothetical?

Has that actually happened? Our expectation is non experienced users who don't need certain fields should just use a custom form.

I think the problem "People can hide tasks from admins and staffs, and you need to investigate much work to find this tasks, and at a worst case scenario people can do illegal thinks at that task, which is not visible for you" is a root problem, because you can't control all tasks at a public instance without forbid the people to mark tasks as not public visible. So you can't give people a chance to report security issues, or issues/requests with private data. This is an existing problem. For example Wikimedia wrote a 3rd party extension for this problem, which lets herald change the policys, without let people adjust the policys at their own (they can choose at a dropdown). So the problem exists, and it can easily solved, by the proposed solution.

This feature request doesn't describe a problem, see Describing Root Problems. Specifically, "feature doesn't exist or might cause an issue" doesn't give us any indication how people are having issues using Phabricator.

Some feedback from our Phabricator instance. At the moment, the way we have been testing usage of Spaces is:

• S 1: Public (Default). Our open-source projects go there.
• S 2: Internal. Visible only to employees. For this, we would really, really like some way to batch assign/add users to a Policy/Space, as discussed in T9780 and T4103#145539. Handling this manually quickly becomes impractical with large numbers of employees.
• S 3+: Long-running special interest projects. They do exist, and they tend to value their privacy.

We apply a Space constraint when executing this query and the object never makes it as far as the application. This is broadly by design, as it hugely improves the scalability of Spaces.

Understood !

I fully understand if you have no time to look at it.

@chad i'm not asking for a full review nor for merging it soon (TM) !
I was just wondering what revision I had open and thus I was asking if it could be an working way to fix T9425 and T9436.
I fully understand if you have no time to look at it.

@tycho.tatitscheff See Planning

@epriestley, what do you think conceptually of this ?? If you have time giving me some thought ?

iirc, it's 3rd party tool (and it's herald) (SetTaskEditPolicyHeraldCustomAction and SetTaskViewPolicyHeraldCustomAction of libphutil-haskell @ Community Resources) that actually handles permission from wikimedia extension.

Hm, Wikimedia has custom code to change the policys. You got a custom field at each maniphest task there, and you can choose 4 options, the first is visible to all, the second is for software security bugs, herald changes the policys to the "security" project, suscribers and the author. The third is for confidential issues, (same policys, just visible for another project instead of security), and the fourth option creates a not visible blocking task for ops.

I want a policy that initially put tasks in a specific "safe" space, but allow overrides later.

Please read our feature request documentation if you have something you'd like to see in Phabricator. https://secure.phabricator.com/book/phabcontrib/article/feature_requests/

Would the above be considered a reasonable, and concrete enough, feature request?

In T9645#142391, @chad wrote:

Closing this out as Invalid. We have no means of taking hypothetical feature requests, please see our documentation for a better explanation:

(also see T4675 which is a similarly related task)

Closing this out as Invalid. We have no means of taking hypothetical feature requests, please see our documentation for a better explanation:

We don't build features for hypothetical scenarios. Do you have a real workflow problem you are running into now or are these requests just anticipatory?