Isn't this one resolved now, thanks to object policies?

Awesome, glad to hear it!

@epriestley: Sounds good to me. Agreed that object policies are working well, I've already replaced the hacked-up policy rule with your Subscribers rule and it's working as expected.

After thinking a litle more about T9183, the usability issue I'm seeing as our usage of Phabricator grows is *finding* the object / Project in the JS policy dropdown, to which I want to make the edited task visible. As the Projects list grows long, this action requires scrolling the entire page and results in a jerked jump back to top after selecting a Project. The natural sorting that I suggested there would only alleviate this slightly.

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:

I got somehow bit by this today... I have only handful "custom policies" and those are quite combination of uers/projects/legal documents etc. In current situation I fully agree with @devurandom: Dialog visible upon clicking "custom policy" should be as descriptive as the on in history - it would make it waay more readable and easy-to-use

this may be covered by the spaces system?

Thanks, that feedback is helpful.

I trying to implement this because we need this on our company installation.
Have almost working code now, but can't get thru one problem.

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.

Yes sorry it wasn't clear

1. Set Default View/Edit Policy to "Custom Policy"
2. Configure some custom policy and save
3. Refresh/edit page for Diffusion Policy settings
4. The value for Default View/Edit Policy is empty, and selecting "Custom Policy" starts a new blank policy instead of showing what was configured earlier.

Ah ok Custom Policy got it to trigger as blank on the edit screen for me.

What specifically are you setting these to (project, all users, custom?)

With 2 minutes of testing, I can't reproduce anything obvious (I'm also on master, but that not old enough to really matter).

Ach! I hadn't thought to look!

Anything in the error logs?

(oops, sorry I didn't see the other comment)

We want to get out of the hypothetical game with feature requests. If you have a real need, please describe the problem.

The default policy for x/y/ is inherited from x/. The expectation is that this is always the correct default. What's your use case where this isn't the correct default?

You have to be able to edit x/ to create x/y/. The UX is kind of junk, but I think this does technically work. Is that sufficient?

See some discussion in D13777.

Thank You, this was perfect reasoning. I'll then consider extension route for
"members of associated projects" and I hope I can get it done ;)

FWIW we are using projects this way i.e. setting Editable By to the project itself. The reason is two-fold:

• to prevent non-members to edit the project details
• to prevent random people from moving stuff in the workboards by mistake

It's not difficult to implement.

Ou... so "project members" would be rather straightforward, but I guess "members of associated projects" would be NP-hard?

Yes, but "Project Members" is not the same as "Members of associated projects", and I think we are unlikely to implement that in the upstream. You can implement it as an extension if you want that behavior.

@epriestley - can those be set as default policies for objects that can have dynamic policies? For now my default policy is "All Users" and I lock down almost everything to specific projects, but it would be better for me to have project members be deault policy for almost everything.

I will go find some now.

They're fairly recent (last couple of months).

haha, never noticed it!

@chad - that's some object-specific policy... like "subscribers of this project" [is this "watchers" ?]... which to me is weird because I still don't get the distinction between subscribers and members... I mean obviously members are member and subscribers subscribe to changes in project and are not members, but to me subscribers are useless for most projects but members are ;)

A similar policy elsewhere is the Conpherence "Room Participants" object policy:

The "Subscribers" object policy is PhabricatorSubscriptionsSubscribersPolicyRule, which adds this thing:

I don't follow what you're asking for here, what's a subscribers object policy?

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

Oh no that's not a "Phacility" quote. I'm just trying to say I really don't know what we'd end up building without a decent effort upfront.

So that makes it $3-6k (according to your Paid Prioritization scheme). Which means we'll have to go with a local patch, unless more funders weigh in.

I no idea what the end result will be, design wise. I would personally probably re-think the entire header. (20-40 design hours).

I gather that you still consider the menu-on-eye-icon the best way to present this UI? Would it help you, if I tried to come up with a patch that does exactly that?

@devurandom, see {I4} if you'd like a personalized status update on this task.

Has any progress been made in the last month? Any new decisions on how it should work?

Cool. Let us know if you're still having issues.

Thanks, I must have forgotten the 'r' prefix when I tried it.

You can use bin/policy unlock <object> to open up the policies on an object. For example, bin/policy unlock rXYZ.

Yeah, I'm mostly concerned about future changes (offhand: phone numbers, emails, messenger handles, oncall schedules, events/availability).

If there is a reasonable path forward that @epriestley will approve, I can do the grunt work and close this out.

Philosophically I'm fine making People "public". The main reason for me is that all the information on a Profile is already (in the most common cases) exposed in other "public" areas of the product (like hovercards). I do think though that when an install is public, we should have an additional reminder/note when someone goes to edit their profile as a reminder. With public profiles, I think we also need to be mindful of upcoming apps like oncall schedules, where some information might be actually private (and thus displayed in that individual app, like Calendar can) and not randomly exposed.