Project watchers are affected in the same way; see T6183.

Thank you, that was fast. We'll see.

Very roughly I'd guess this is somewhere in the 80-120 hour range. D9204 is a very bare-bones technical implementation which attempts to show that the feature is possible, but this needs a great deal of product and integration work on top of that.

Would you be able to give a rough estimate for paid prioritization of this task?

One small addition: Having the ability to assign a meaningful name to custom policies would be beneficial even without the ability to re-use elsewhere. Right now when viewing policies of items, I have a lot of "Custom Policy" displayed in summaries, properties, etc.

Having an ability to name and save custom policies would be useful - in my organization we need to allow administrators access to some things in order to help with troubleshooting or general management. My current options are:

1. Re-create custom policy for items which allow Project + Admins
2. Create new Project that includes members of both Project + Admins

To your question @chad (although it seems like the clarity is not needed anymore), it just flags any newly created diff.

What would be the best way to handle archived projects in this control?

The expected behavior is for the dialog to use a workflow. In general, disabled actions should use a workflow so that dialogs show on the same page when the actions are clicked.

We don't plan to implement this in the foreseeable future. If you need extremely granular control over field permissions, we recommend considering other software which is better suited to heavier process-oriented workflows.

T3820 is the main task we feels solves this problem, and it has the added benefit it solves a problem a lot of installs would like to see. Not sure with T3820 if this is worth pursuing. Going to merge this in so at least it can be referenced (and we know to make it clear in Spaces who has access to what).

@ralph.van.etten: No we did not end up doing it, but if we do we will post here for sure.

We are considering giving clients access to our phabricator and I want to check if the permissions/policies are set up correctly. They do not need to see everything in our phabricator.
They way I am doing this now is to login as an user with similar permissions and then just click around and see what I can access. But even then I can't be 100% sure there isn't an object somewhere with the wrong permissions.

@dmorissette: I would be interested in the patch you describe. Is it available somewhere?

In T6860#91168, @nateguchi2 wrote:

In our installation, we have it so that if you make a task attached to a project, it sets the default visibility to that project.

#1: For drydock, I'd switch it to a Query with an omnipotent user -- we can only reasonably do the checks when users create the blueprints, since systems like Drydock, Almanac, Harbormaster and Instances don't act as a real user when running background tasks. Like with Harbormaster, we'll just prevent you from creating things that affect stuff you can't act on in the first place. Drydock will have high default barriers to creation, anyway.

Assuming my last revision makes it through, just four issues remain... @epriestley - I've provided some details... Can you let me know what you want me to do for these last four?

Thank you Chad, for taking this up. I am trying to understand the code, and attempting to implement this functionality.

It's our general recommendation to installs that have such specialized needs to use a software product better suited to the task.

Also if you press 'Custom Policy' for visibility below the title of things like Pastes, it doesn't provide a very useful message.

Thank you for clarifying and sorry for the erroneous report. It was not immediately apparent to me that the header had this additional policy information. The behavior now makes sense; I had just been confused when setting the mockup policy and seeing a different one on the actual file object.

If you click the policy for an object (in the header), it will explain any special policy rules that apply to the object. Here are the rules for files:

This is confusion over the policy.

Expectation is:

In our installation, we have it so that if you make a task attached to a project, it sets the default visibility to that project.

Haha cool, just tested this out on my dev install and it maxes out the CPU on my VM.

I wasn't able to find previous discussion of this immediately -- it was buried in T5135. I updated the description to provide some context.

Closed by commit rPb3e196b69400.

@joshuaspence, feel free to steal this -- I'll probably get to it today but am not actively working on it.

I'm going to diff out a forward-fix once I dig through everything else in my queue.

Did you want to keep this around or OK to close?

I've reverted rP8b756 in rP7c4de, so updating should fix this.

Nevermind, on trying to replicate this I think I mistyped the URL. Although I'm not sure that I agree with a 200.

We return HTTP 200 with an explicit message:

I assume this task just covers visibility policy?

Thank you! I'm wondering if it should be renamed for users who can't actually edit anything. Should I make a new task?

Closed by commit rPf35a38b086ab.