In versions prior to MT4, users were approved for certain operations according to whether or not they had specific permissions. This was written in syntax for each operation like this:
$app->permissions->can_manage_pages(); or $app->permissions->has('manage_pages');
The problem with this way of writing is that the relationship between the action and the permission names is only defined in the source code, and is dispersed in source code.
In order to find out if specific permissions (manage_pages) permitted an operation (such as deleting all trackbacks on a given webpage), you had to refer directly to the source code. As a result, when you introduced new permissions, it was very difficult to confirm whether or not they were consistent with other permissions.
In order to solve this problem in Movable Type 5, we’ve separated permission names and actions, and they are now managed together in the Registry.
Write a code to confirm the permitted actions.
$app->can_do('remove_all_trackbacks_on_webpages') or return $app->errtrans('Permission Denied');
Specify the action that correspond to the permission.
manage_pages: permitted_actions: remove_all_trackbacks_on_webpages: 1
By doing this, as long as you create a clear action name, you need not return to code you’ve already written. If there is an inconsistency between the behavior of individual permissions, you can edit the Registry definition (MT::Core, config.yaml, etc) to identify whether or not there is an inconsistency with permissions.
All the relationships between permissions and actions are defined in the registry except one - super_user. Super_user is a specific property of users, and permits users to conduct any and all operations on the MT system.
Previous permission systems did not support inheritance in the code. With Movable Type 5 permission management, you can define inheritance in the registry.
Registry inheritance relationships are implemented by expanding each entry that was found below ‘permissions’ in the MT4 registory. The two entries below define support for each permission’s action. For specific definition examples, please see lib/MT/Core.pm.
Hash to define a list of actions permitted for the user who have this permission.
A list of inheritance origins for this permission. Defined by references to the list.
The MT::Permission class can_do method determines whether users strung to this permission can run “$action.” If they can, 1 is returned, if not 0, and if it’s unclear, “undef” is returned.
$perms->can_do('login_to_cms') or return $app->errtrans('Access Denied');
$author->can_do($action, at_least_one => 1) or return $app->errtrans('Access Denied');
The MT::Author class can_do method determines whether “$author” is allowed to run “$action.” If allowed, it returns 1, if not, it returns 0, and if it’s unclear, it retunrs “undef.” By default, it determines run permissions on the system level (blog_id==0).
When the option “at_least_one” is true, it returns the result when at least one blog allows operations (including system level permissions).
The MT::App class can_do method determines whether currently logged in users can run “$action.” If yes, 1, if no, 0, and if unclear, “undef” is returned.
MT::App::can_do makes its determination according to currently logged in users and the current context’s blog_id. It also considers system level permissions (blog_id=0 permissions).
$app->can_do('login_to_cms') or return $app->errtrans('Access Denied');
This example registers a new permission from a plugin. The registered permissions will be displayed on “Edit Role” screen.
permissions: blog.your_permission: group: blog_admin label: Your New Permission order: 350 permitted_action: your_action: 1 your_other_action: 1
Specify the role group.
- sys_admin (only system level)
The display name of the permission.
Ordering the permission in its role group.
This example restricts access to “my_menu” by the specified permission.
applications: cms: menus: tools:my_menu: label: Your Menu Label mode: your_mode order: 150 view: blog permit_action: your_permissions