Permission API

Permission Management on Movable Type 4

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.

Permission Management on Movable Type 5

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.

Source code

Write a code to confirm the permitted actions.

$app->can_do('remove_all_trackbacks_on_webpages')
     or return $app->errtrans('Permission Denied');

Registry

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.

Inheritance

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.

permitted_actions

Hash to define a list of actions permitted for the user who have this permission.

inherit_from

A list of inheritance origins for this permission. Defined by references to the list.

Methods

MT::Permission::can_do

$perms->can_do($action)

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');

MT::Author::can_do

$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).

MT::App::can_do

$perms->can_do($action)

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');

Register a new permission from a plugin

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

group

Specify the role group.

• blog_admin
• auth_pub
• blog_upload
• blog_comment
• blog_design
• sys_admin (only system level)

label

The display name of the permission.

order

Ordering the permission in its role group.

Binding a custom permission to a menu

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