Yeah, I know, that this exists. The current problem is, that this option changes restricts the abilty to change the policys and the abilty to change a space. (User which can't edit task policys can only change spaces via batch edit). So I think it would be better, to make different fields for it.

Can you describe the core problem you are having with Phabricator? What workflows are people getting hung up on and how often is it happening?

Ok, but the problem is, that you can't allow users to only change the space, there all always able to change visibilty and edit policys too (except they use batch edits to change the space, but I think this is not confortable). So I think it would be better to let administrators set different rules for editing spaces and task policys.

For example you have user, they should not change space/visibilty/edit policys

Please follow our feature request guide when asking for new features. https://secure.phabricator.com/book/phabcontrib/article/feature_requests/

This is definitely confusing and something we should fix. (We may get it from T9132 cheaply.)

On the other hand, there were observable effects in the similar case of T7284

AFAICS this is not Spaces specific but also applies to e.g. setting an initial custom task policy when creating a task: Foobar changed the visibility from "Public (No Login Required)" to "Custom Policy".
So far I'm aware of two WM Phab users who contacted me, concerned that the tasks they created were public for a short moment and might have created public notifications.

I include the fix for this in D14128

Related D14128

I'm not quite sure if I should expect a response (here or on IRC) before submitting some code. Or if the maniphest task is sufficient.

My goal is to edit [[https://secure.phabricator.com/diffusion/P/browse/master/src/view/form/control/AphrontFormPolicyControl.php;23b2653f52cd16bc9cedfdf7328d401171e668ca$328-358 | AphrontFormPolicyControl::buildSpacesControl ]] to return null also when only default Space is remaining active.

May I try to submit a fix ?

Oh ! Then let me correct the question.

Spaces is the application name. Space is the object.

@chad was more "desactivate space as an application". I can already "desactivate a special space" by archiving it.

I surely misunderstood the goal of this field/
For me it was more saying the details in detail and giving a summary in summary.

Did you intend to add an Answer Summary as the same question? I'd love to improve the clarity of the form if it's unclear, we're not asking you to ask your questions three times.

One issue might be projects and their member list. Users from other spaces should probably be replaced with a "question mark" placeholder, so that others don't know who it is, but see that the project has some members. That way generic cross-space groups don't become a privacy/security issue.

In T9165#131879, @epriestley wrote:

There is only one flavor of "Visible To", which is the second, more general one:

Who can see this object and sub-objects / contents?

"Visible To" always means this. If you can point out cases where it doesn't, we'll fix them.

In T9165#131879, @epriestley wrote:

It sounds like the root issue here is really confusion around projects, and an expectation that associating a project with an object puts the object "in" the project. It doesn't, and, by design, project associations never affect visibility.

We could also split projects into two completely separate but essentially identical applications, "Groups" and "Tags". In the simplest form, both applications would run exactly the same code, except one would say "Groups" everywhere and one would say "Tags" everywhere, and each object would have an internal type flag specifying whether it is a "Group" or a "Tag".

There is only one flavor of "Visible To", which is the second, more general one:

The different behaviours of Visible-To for different types of objects are currently quite confusing to our users.

@swisspol nails it.

General feedback from @swisspol:

1. Spaces in themselves are not complicated to understand (just needs a bit of UI polish for integration in apps).
2. Visible To / Editable By are not complicated to understand either, I completely agree.
3. The *combination* of the 2 is complex: case in point the amount of explanation needed in "Space Policies” in https://secure.phabricator.com/book/phabricator/article/spaces/.

I would argue this is very powerful but needlessly complex for the average user: even tech people *cannot* know out of the box how these things interact together unless you read the docs. I’ll bet you lunch that showing this to the majority of tech people (phab users or not) results in them not being able to understand at a glance how this works - it truly is confusing:

Then you say spaces make it more reliable to enforce policies across the board and less error-prone, but not really: because visible to / editable by are still here, you can still get it wrong: e.g. someone sets them to something else than “all users” in a restricted space, then other people need access, that author changes the space: it still doesn’t work.

I would point out that the model of visible / editable by is simple and elegant. Same for a pure space model (i.e. no visible / editable by) which happens to be ideal for organizations that want easy/can’t-shoot-yourself-in-the-foot access control. The current space model is probably for orgs that have quite more complex access control requirements. I’m not suggesting to this take this off, just add a middle ground which I’m betting plenty of users would be happy with :)

I love Phab because it’s elegant, professional, reliable *and* doesn’t make it easy for average users to shoot themselves in the foot. IMO Spaces are not there yet.

Updated to fix a bug where the default $space_phid (and $current_value) would be 'all' instead of $actor->getDefaultSpacePHID().

I updated the patch yet again. In this iteration, anyone can add users to projects, if these users are not in any space at all.

Thanks, that feedback is helpful.

I want to resolve this via T9132, by providing prefilling of all fields in all forms.

I'm pushing T8442 out since we don't really have enough understanding of use cases yet, and would like to give installs time to adopt and use Spaces before we move forward with it, since there are a number of different possible approaches with different tradeoffs.

Status here:

I think we've pretty much tied up all the loose ends for v1 here.

We have pretty good saturation now and I don't think there are any real-world use cases driving other applications at the moment. A few more applications will probably get support eventually.

I added following patch to allow admins to add users into spaces, if currently that user is in no space at all:

I am now using following patch locally:

This isn't a priority, which means I don't want to spend time planning, reviewing, merging, or supporting it right now, not just developing it.

Would abovementioned approach be viable? I.e. filtering the list of users in /people/, and those which typeahead and similar functions provide? Would you accept a patch that implements it that way? Do you have any other suggestions on how to implement this efficiently?

It's vaguely possible we may implement this eventually, but it's not going to happen any time soon and almost certainly not this year.

From my experience playing with this and some user feedback:

• Spaces would greatly benefit from having colours and icons. Then not only could the selector show different (and hopefully more obvious) icons, but the header (or site background) colour could also be changed to the colour of the space. A less intrusive coloured line below the header, possibly combined with coloured text in the spaces selector, would also be fine.
• The benefit that this small patch alone does to UX feels immense. Instead of having to adjust spaces for each and every object I create (which actually reduces usability instead of increasing it), I can switch "modes" or "projects" globally, which means a lot if your instance contains objects from very different projects which are being worked on by distinct groups of people.
• User feedback suggests that the position (central header) and combination with a text (space name) improves usability of spaces a lot and makes it very obvious which space one is currently working in.
• Filtering the page contents to show only objects in the currently selected space might help users switching over from Redmine (which is the majority in our case) to understand the concept.

The patch could still need a bit of polishing, but should I already submit a review request anyway, so it becomes easier to discuss necessary changes?

I updated P1834 to fix the mentioned issues:

I've got a patch ready, which basically copies the search scope selector implementation, and is still rather crude and unpolished: P1834

webroot/rsrc/js/core/behavior-spaces-switcher.js:

/**
 * @provides javelin-behavior-phabricator-spaces-switcher
 * @requires javelin-behavior
 *           javelin-typeahead-ondemand-source
 *           javelin-typeahead
 *           javelin-dom
 *           javelin-uri
 *           javelin-util
 *           javelin-stratcom
 *           phabricator-prefab
 */