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

If you select "Custom Policy" from the dropdown, the dialog will show the rules in the policy.

(This can/should be made easier to use.)

If I get the original poster correctly:

(The current workaround, in detail.)

I think we can clarify it in both places.

In T6802#88402, @chad wrote:

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

Looks like you have to login to see it. :(

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

And the ability to actually see custom policy details such as the one for our "Can Edit Task Projects" Maniphest application policy please.

The visibility of a Space in our Phab instance is using a Custom Policy. When I click the red "Custom Policy" box, I am presented with this text, which does not help me at all:

Users with the "Can View" capability for this object:

    This object has a custom policy controlling who can take this action.

This object has a more restrictive policy ("Custom Policy") than the default policy for similar objects (which is "All Users").

When I search in this Space's history for changed the visibility of this Space from "… (Project)" to "Custom Policy" and click "Custom Policy" there, I am presented with a message box telling me:

Custom Policy

These rules are processed in order:
    Allow members of projects …, …

If no rules match, deny all other users.

The latter is way more useful than the former. Thus I propose to make all instances of "Custom Policy" (at the top of the page, in "Editable by" and everywhere else it appears) a button which links to the latter message box.

this may be covered by the spaces system?

per task policies are hard to manage,
you cannot mass-edit them at all,
so using "spaces" as policy containers looks much more convenient to me.

And having a "space name" is a very clear global definition then. =)
Allowing "subscribers" and something like "members of associated projects" in spaces level could replace the need for custom policies at all.
(Its getting a headache to manage and check all the "custom policy" that may have been made by accident and sort of lock-out the real task relevant teams... like had a user creating a task with "visible" and "editable by" author, was a bit surprised when that guy poked me, "Why does my issue get ignored? seen a few others that reported later, but already got processed" ^^°)

This way "subscriber" + "associated project member" could allow private issues, if you make herald allow issues to be "without a project".

this may be covered by the spaces system?

No.

so using "spaces" as policy containers looks much more convenient to me.

And significantly less flexible/useful

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

that's cool