Allow applications to define new policy capabilities
Summary:
Ref T603. I want to let applications define new capabilities (like "can manage global rules" in Herald) and get full support for them, including reasonable error strings in the UI.
Currently, this is difficult for a couple of reasons. Partly this is just a code organization issue, which is easy to fix. The bigger thing is that we have a bunch of strings which depend on both the policy and capability, like: "You must be an administrator to view this object." "Administrator" is the policy, and "view" is the capability.
That means every new capability has to add a string for each policy, and every new policy (should we introduce any) needs to add a string for each capability. And we can't do any piecemeal "You must be a {$role} to {$action} this object" becuase it's impossible to translate.
Instead, make all the strings depend on //only// the policy, //only// the capability, or //only// the object type. This makes the dialogs read a little more strangely, but I think it's still pretty easy to understand, and it makes adding new stuff way way easier.
Also provide more context, and more useful exception messages.
Test Plan:
- See screenshots.
- Also triggered a policy exception and verified it was dramatically more useful than it used to be.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: chad, aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D7260
2013-10-07 22:28:58 +02:00
|
|
|
<?php
|
|
|
|
|
|
|
|
abstract class PhabricatorPolicyCapability extends Phobject {
|
|
|
|
|
|
|
|
const CAN_VIEW = 'view';
|
|
|
|
const CAN_EDIT = 'edit';
|
|
|
|
const CAN_JOIN = 'join';
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the unique key identifying this capability. This key must be globally
|
|
|
|
* unique. Application capabilities should be namespaced. For example:
|
|
|
|
*
|
|
|
|
* application.create
|
|
|
|
*
|
|
|
|
* @return string Globally unique capability key.
|
|
|
|
*/
|
2014-07-25 00:25:42 +02:00
|
|
|
final public function getCapabilityKey() {
|
2015-10-02 01:56:21 +02:00
|
|
|
return $this->getPhobjectClassConstant('CAPABILITY');
|
2014-07-25 00:25:42 +02:00
|
|
|
}
|
Allow applications to define new policy capabilities
Summary:
Ref T603. I want to let applications define new capabilities (like "can manage global rules" in Herald) and get full support for them, including reasonable error strings in the UI.
Currently, this is difficult for a couple of reasons. Partly this is just a code organization issue, which is easy to fix. The bigger thing is that we have a bunch of strings which depend on both the policy and capability, like: "You must be an administrator to view this object." "Administrator" is the policy, and "view" is the capability.
That means every new capability has to add a string for each policy, and every new policy (should we introduce any) needs to add a string for each capability. And we can't do any piecemeal "You must be a {$role} to {$action} this object" becuase it's impossible to translate.
Instead, make all the strings depend on //only// the policy, //only// the capability, or //only// the object type. This makes the dialogs read a little more strangely, but I think it's still pretty easy to understand, and it makes adding new stuff way way easier.
Also provide more context, and more useful exception messages.
Test Plan:
- See screenshots.
- Also triggered a policy exception and verified it was dramatically more useful than it used to be.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: chad, aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D7260
2013-10-07 22:28:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Return a human-readable descriptive name for this capability, like
|
|
|
|
* "Can View".
|
|
|
|
*
|
|
|
|
* @return string Human-readable name describing the capability.
|
|
|
|
*/
|
|
|
|
abstract public function getCapabilityName();
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Return a human-readable string describing what not having this capability
|
|
|
|
* prevents the user from doing. For example:
|
|
|
|
*
|
|
|
|
* - You do not have permission to edit this object.
|
|
|
|
* - You do not have permission to create new tasks.
|
|
|
|
*
|
|
|
|
* @return string Human-readable name describing what failing a check for this
|
|
|
|
* capability prevents the user from doing.
|
|
|
|
*/
|
2013-10-09 22:53:17 +02:00
|
|
|
public function describeCapabilityRejection() {
|
|
|
|
return null;
|
|
|
|
}
|
Allow applications to define new policy capabilities
Summary:
Ref T603. I want to let applications define new capabilities (like "can manage global rules" in Herald) and get full support for them, including reasonable error strings in the UI.
Currently, this is difficult for a couple of reasons. Partly this is just a code organization issue, which is easy to fix. The bigger thing is that we have a bunch of strings which depend on both the policy and capability, like: "You must be an administrator to view this object." "Administrator" is the policy, and "view" is the capability.
That means every new capability has to add a string for each policy, and every new policy (should we introduce any) needs to add a string for each capability. And we can't do any piecemeal "You must be a {$role} to {$action} this object" becuase it's impossible to translate.
Instead, make all the strings depend on //only// the policy, //only// the capability, or //only// the object type. This makes the dialogs read a little more strangely, but I think it's still pretty easy to understand, and it makes adding new stuff way way easier.
Also provide more context, and more useful exception messages.
Test Plan:
- See screenshots.
- Also triggered a policy exception and verified it was dramatically more useful than it used to be.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: chad, aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D7260
2013-10-07 22:28:58 +02:00
|
|
|
|
2013-10-10 00:06:18 +02:00
|
|
|
/**
|
|
|
|
* Can this capability be set to "public"? Broadly, this is only appropriate
|
|
|
|
* for view and view-related policies.
|
|
|
|
*
|
|
|
|
* @return bool True to allow the "public" policy. Returns false by default.
|
|
|
|
*/
|
|
|
|
public function shouldAllowPublicPolicySetting() {
|
|
|
|
return false;
|
|
|
|
}
|
Allow applications to define new policy capabilities
Summary:
Ref T603. I want to let applications define new capabilities (like "can manage global rules" in Herald) and get full support for them, including reasonable error strings in the UI.
Currently, this is difficult for a couple of reasons. Partly this is just a code organization issue, which is easy to fix. The bigger thing is that we have a bunch of strings which depend on both the policy and capability, like: "You must be an administrator to view this object." "Administrator" is the policy, and "view" is the capability.
That means every new capability has to add a string for each policy, and every new policy (should we introduce any) needs to add a string for each capability. And we can't do any piecemeal "You must be a {$role} to {$action} this object" becuase it's impossible to translate.
Instead, make all the strings depend on //only// the policy, //only// the capability, or //only// the object type. This makes the dialogs read a little more strangely, but I think it's still pretty easy to understand, and it makes adding new stuff way way easier.
Also provide more context, and more useful exception messages.
Test Plan:
- See screenshots.
- Also triggered a policy exception and verified it was dramatically more useful than it used to be.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: chad, aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D7260
2013-10-07 22:28:58 +02:00
|
|
|
|
|
|
|
final public static function getCapabilityByKey($key) {
|
|
|
|
return idx(self::getCapabilityMap(), $key);
|
|
|
|
}
|
|
|
|
|
|
|
|
final public static function getCapabilityMap() {
|
2015-07-07 14:34:30 +02:00
|
|
|
return id(new PhutilClassMapQuery())
|
|
|
|
->setAncestorClass(__CLASS__)
|
|
|
|
->setUniqueMethod('getCapabilityKey')
|
|
|
|
->execute();
|
Allow applications to define new policy capabilities
Summary:
Ref T603. I want to let applications define new capabilities (like "can manage global rules" in Herald) and get full support for them, including reasonable error strings in the UI.
Currently, this is difficult for a couple of reasons. Partly this is just a code organization issue, which is easy to fix. The bigger thing is that we have a bunch of strings which depend on both the policy and capability, like: "You must be an administrator to view this object." "Administrator" is the policy, and "view" is the capability.
That means every new capability has to add a string for each policy, and every new policy (should we introduce any) needs to add a string for each capability. And we can't do any piecemeal "You must be a {$role} to {$action} this object" becuase it's impossible to translate.
Instead, make all the strings depend on //only// the policy, //only// the capability, or //only// the object type. This makes the dialogs read a little more strangely, but I think it's still pretty easy to understand, and it makes adding new stuff way way easier.
Also provide more context, and more useful exception messages.
Test Plan:
- See screenshots.
- Also triggered a policy exception and verified it was dramatically more useful than it used to be.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: chad, aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D7260
2013-10-07 22:28:58 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|