Change Details

See PHI1553. Currently, some applications colorize object policies in header UIs: {F7035143} The intent of this feature is that policies are colored red if they're more-restrictive than default and green if they're less-restrictive. They're also colored orange if they're different, but their relationship to the default policy can not be strictly determined (for example, if the default policy is "Members of Project X" and the object policy is "Members of Project Y", there's no reasonable way in the general case for Phabricator to determine that one policy is fundamentally more or less restrictive than the other). This feature seems reasonable on paper, but has some issues in practice: - This feature relies on the concept of a "Default Policy", which no longer exists in applications with Custom Forms (since the form determines the default policy, but forms aren't sticky to objects). Applications are generally moving toward Custom Forms. - This feature isn't terribly clear/obvious in the best case, and we can't do much about a wide range of policy comparisons. - In many applications (like Phriction), the policy behavior is complicated (depends on parent object policies) and the color may not convey much or may be misleading. - The feature is theoretically explained by clicking the tag, but at least in PHI1553 this wasn't sufficiently user-friendly to actually explain what's going on: the feature still caused an escalation to support. - The inconsistency between applications is confusing (some do this, some don't) is also confusing. Since things are increasingly on EditEngine/Custom Forms and generally headed in that direction, I'm going to resolve this confusion by simply removing the feature. It seems like more trouble than it's worth.

See PHI1553. Currently, some applications colorize object policies in header UIs: {F7035143} The intent of this feature is that policies are colored red if they're more-restrictive than default and green if they're less-restrictive. They're also colored orange if they're different, but their relationship to the default policy can not be strictly determined (for example, if the default policy is "Members of Project X" and the object policy is "Members of Project Y", there's no reasonable way in the general case for Phabricator to determine that one policy is fundamentally more or less restrictive than the other). This feature seems reasonable on paper, but has some issues in practice: - This feature relies on the concept of a "Default Policy", which no longer exists in applications with Custom Forms (since the form determines the default policy, but forms aren't sticky to objects). Applications are generally moving toward Custom Forms. - This feature isn't terribly clear/obvious in the best case, and we can't do much about a wide range of policy comparisons. - In many applications (like Phriction), the policy behavior is complicated (depends on parent object policies) and the color may not convey much or may be misleading. - The feature is theoretically explained by clicking the tag, but at least in PHI1553 this wasn't sufficiently user-friendly to actually explain what's going on: the feature still caused an escalation to support. - The inconsistency between applications (some do this, some don't) is also confusing. Since things are increasingly on EditEngine/Custom Forms and generally headed in that direction, I'm going to resolve this confusion by simply removing the feature. It seems like more trouble than it's worth.

See PHI1553. Currently, some applications colorize object policies in header UIs: {F7035143} The intent of this feature is that policies are colored red if they're more-restrictive than default and green if they're less-restrictive. They're also colored orange if they're different, but their relationship to the default policy can not be strictly determined (for example, if the default policy is "Members of Project X" and the object policy is "Members of Project Y", there's no reasonable way in the general case for Phabricator to determine that one policy is fundamentally more or less restrictive than the other). This feature seems reasonable on paper, but has some issues in practice: - This feature relies on the concept of a "Default Policy", which no longer exists in applications with Custom Forms (since the form determines the default policy, but forms aren't sticky to objects). Applications are generally moving toward Custom Forms. - This feature isn't terribly clear/obvious in the best case, and we can't do much about a wide range of policy comparisons. - In many applications (like Phriction), the policy behavior is complicated (depends on parent object policies) and the color may not convey much or may be misleading. - The feature is theoretically explained by clicking the tag, but at least in PHI1553 this wasn't sufficiently user-friendly to actually explain what's going on: the feature still caused an escalation to support. - The inconsistency between applications is confusing (some do this, some don't) is also confusing. Since things are increasingly on EditEngine/Custom Forms and generally headed in that direction, I'm going to resolve this confusion by simply removing the feature. It seems like more trouble than it's worth.