|Resolved||epriestley||T13411 Improve "Custom Policy" behavior in policy dialogs|
|Resolved||epriestley||T6802 "Custom policy" for editing/viewing does not link to details|
- Mentioned In
- T13411: Improve "Custom Policy" behavior in policy dialogs
T9949: Custom policy error is unhelpful
T9164: Simplification of policy controls for different types of projects in an organisation with external collaborators (policy templates?)
T6807: Edit Project page shows to logged in users but not logged out users despite public visibility
- Mentioned Here
- D20804: Give policy name rendering explicit "text name", "capability link", and "transaction link" pathways
D20805: Inline custom policy rules inside policy capability explanation dialogs
T13186: Upgrading: Legacy "Can Edit <Field>" policies in Maniphest; requireCapabilities() in TransactionEditor
T13411: Improve "Custom Policy" behavior in policy dialogs
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".
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
Here's the fate of the various issues discussed here:
"Editable By" on Projects not linked/useful.
This particular element was removed by some earlier change. Other variations of it are now handled better, see below.
Also if you press 'Custom Policy' for visibility below the title of things like Pastes, it doesn't provide a very useful message.
When I click the red "Custom Policy" box, I am presented with this text, which does not help me at all:
This dialog now inlines the custom policy rules after D20805, provided you can see the object:
And the ability to actually see custom policy details such as the one for our "Can Edit Task Projects" Maniphest application policy please.
See T13411 for more context / related changes / followup.