In T6802#88402, @chad wrote:

We don't have access to said task, feel free to reproduce here (or use screenshots).

We don't have any plans for that in vanilla Phabricator. T4863 covers customizing workboards, T418 covers customizing everything else. In general though T3820 is how we think installs should deal with mixed levels of permissions in a single install.

also, could have similar differentiation in search results, workboards,
task lists on projects, feeds (i.e. side of front page), pages for
individual users with tasks changed by that user

Introducing pure red text in the header could be a useful first step, yes. We would need to think of a solution that doesn't conflict with other plans to put more emphasis in task resolutions i.e. T6500: Duplicated tasks should be marked more visibly as duplicates.

As a first pass, we could either go with something simple like text:

Thanks for getting this so fast, we'll be sure to pull this into our next deployment.

Closed by commit rP8ac73b2bf351.

I can only reproduce this by setting the Differential application to a restrictive policy such as administrators only. With default policy, uninstalling the Differential application does not reproduce this. Updated the task.

I peeped the IRC log so I'll take a stab at this now.

Some other general thoughts:

Ah, I missed that part. I do still think that "not default" is the right thing to cue -- for example, a more-open Almanac service in a field of admin-only-by-default services would be desirable to call out, rather than calling out the majority of services which have a tightly locked default.

In the description @qgil notes !public or !allusers, which is what I expect the default to be in most places. Though maybe "not default" is a more correct means of isolating changes.

Strictly as described, this would also leave 99% of tasks on 95% of installs red. I do think we could do a better job of surfacing cases where the policy deviates from the default policy, though, without being meaningless for the majority of users.

I think the core issue here is reasonable to solve, I'd probably want to resolve it consistently everywhere though (not just Maniphest). It also is likely important to solve at the comment box level as well, since people may not remember the object's policy before commenting.

Wiki pages had been broken for a while. So if you haven't updated in the past month or maybe two there might have been a old issue you were seeing.

Ah, I'll have to double check on Monday when I can look again. My understanding from what you guys have said is even though the file I dropped onto the task's comment box says it's only visible to me, other users with access to that task can see it regardless?

Thanks @chad! That's a sensible solution.

We'll allow namespace moves. The "global" namespace will just sort of be a default (and a namespace for existing objects to get put into when we build this), and not very special in other respects.

In T3820#50256, @epriestley wrote:

• A new namespace Interface defines object membership in a namespace. The policy filtering code acts on this immediately.

As usual, reasonable and clear. Thanks man.

@chasemp and I talked about this some more on IRC. We still don't have exactly the same viewpoint on where we should end up, but I think we can take an approach which everyone's onboard with for as long as possible and then possibly deviate a little at the end. Broadly, I want to implement the parts of this which would lock down or restrict capabilities first. Once we've implemented the heaviest set of restrictions, we can evaluate what holes we want to punch through them based on user feedback.

I think in the abstract locking down features because new users don't understand them sounds like the wrong solution to new users not understanding features. I also don't like to lock down features because of anticipated malicious use since the tools should be built first and foremost for good users, then bad users can be disabled and there is an audit trail for everything users do.

"Projects" as an app is likely one of our hardest to explain, and certainly onboarding would help. I'm just not sure there is any easy fix here. We've talked about renaming "Projects" as "Tags" which might help some with this specific issue.

In T6567#85161, @btrahan wrote:

the users should educate themselves pretty quickly

I appreciate the context, which I'll summarize as "other tools have 1:1 mappings of projects to objects where the project dictates privacy."

In T6567#84997, @btrahan wrote:

Do you know how come they have expectations that setting the policy on a project would later impact the policy of objects associated with the project?

A coarse solution is to create a project called "Users Who Can Prioritize Tasks", set that as the policy, and add anyone who should be able to edit priorities to that project.

Closed by commit rP32b1ffdf894c.

Do you know how come they have expectations that setting the policy on a project would later impact the policy of objects associated with the project?

What about a policy to define who can edit the policy of projects?

Check out D7269

I presume if I could figure one out, I could do others.

T6564 is similar too, and could be resolved by introducing a default "Can View" for Files and using it on both the manual upload form and the drag-and-drop-onto-the-homepage flow.

ManiphestTask::initializeNewTask is an example of a Policy object that initializes the default policy relative to application settings. That's the tip of the iceberg as you'll need to make a few other changes; I think the method is a reasonable start but definitely ask more questions...!

@epriestley, is there an example implementation somewhere?

Regarding UI: what about the possibility (not requirement) to assign a user a "default project" and a project a "default space" in order to have them "pre-compiled" when new entities are created by the user? (in big organizations often PM, users and developers belongs to one project only or work mainly for one at a time)

Closed by commit rP36c46d80f5a0.

Ah, that makes sense.

This repros at any new page, e.g. https://secure.phabricator.com/w/asdsadsadsadasd/

You may be able to implement this as an extension (subclass PhabricatorPolicyRule).

Closed by commit rP9252d2a579e3.

Closed by commit rP6f971a0fc4d8.

@epriestley, ok, that works too. You see, you wouldn't hire me as an engineer. :P

In T6502#83050, @chad wrote:

I feel like 'Can Edit Workboard' should grant 'Can Edit Task'.

In T6502#83049, @qgil wrote:

Is this summary correct, then?

When a user tries to move a card in a workboard...

I feel like 'Can Edit Workboard' should grant 'Can Edit Task'.

Is this summary correct, then?

Yep, exactly.

Oh Can Edit Workboard is a Project Policy, not a Maniphest Policy, correct?

(I think that would be a reasonable default, although the actual default-default would have to be "members of current project", which doesn't exist until T5681.)

Yeah, just set "Can Edit Workboard" to "Members of Project 'Security'".

Would there be any future path to ... say only Security can edit Security Workboard...

That said, I do think a separate permission is probably reasonable, but you'd need both ("Can Edit Workboard", "Can Edit Task") to drag.

Thinking on it a little more, I like it conceptually but think we can't get away with it:

Yeah, conceptually priority is also task management/planning like workboards and everything else is task definition.

Specifically, you'd lean toward requiring the separate policy only (you don't need to be able to edit the task, as long as you can edit the board)?

I'd lean towards separate policy. Editing a task is primarily changing the definition of a task, where Workboards are the planning/implementation of a Task.

It's supposed to be the "Can Edit" for the task, although that doesn't look like it's currently enforced (the UI sort of respects it, but not really).