Документация по API UMI.CMS

Пользователь может входить в одну или более групп пользователей. Поэтому права пользователя это его права + права групп, в которые он входит. Наследование прав расширяющее (выбирается максимальный доступ). Это означает, что пользователь имеет все права групп, в которые он входит, и не может иметь прав меньше, чем есть у этих групп.

В UMI.CMS функциональной единицей является связка модуль/метод и функциональные права применяются именно к ней. Функциональные права выставляются в редактировании пользователя из административной части. На этой странице все права разбиты на модули и у каждого модуля есть набор прав, которые можно относительно него назначить пользователю. Это корневые права.

Корневые права доступа определяются в настройках модуля, в реестре. У каждого модуля module_name есть ключ в реестре вида "//modules/module_name/func_perms", где каждый ключ это корневое право на какое-либо действие. Например, для модуля "новости" это выглядит так: в реестре "//modules/news/func_perms" есть 2 ключа: view, lists и publish (это корневые права). В настройках пользователя это чекбоксы "Просмотр новостей", "Управление новостями" и "Возможность публикации". Если поставить пользователю галочку "view", то ему можно будет выполнять метод news::view(), если он существует.

Так как действие "Просмотр новостей" подразумевает, что при включенной галочке мы должны получить доступ не к одному методу, а к нескольким, введено такое понятие как подправа. Это права, которые логически объединяются в группу по корневому праву (например, по "view"). Каждый раз заносить подправа в реестр было бы утомительно, поэтому они обычно выносятся в файл "permissions.php", который размещается в папке модуля. Для модуля новостей это файл "~/classes/modules/news/permissions.php.

<?php
 $permissions = Array(
  'view' => Array('lastlist', 'listlents', 'rubric', 'related_links', 'rss', 'item', 'lastlents'), 
  'lists' => Array('add_item_do', 'del_item', 'edit_list', 'edit_list_do', 'del_list', 'subjects', 
    'subjects_do', 'add_item', 'add_list', 'add_list_do', 'edit_item', 'edit_item_do', 'last_lists', 'item.edit', 'rubric.edit', 'activity', 'add', 'edit', 'del')
 );
?>

Как видно, тут перечислены все подправа относительно корневых прав. В момент, когда система проверяет права, например на news::lastlist(), определяется корневое право в соответствии с permissions.php (в нашем случае это view) и проверяет права именно на корневой метод.

Права на методы необходимо выставить, в т.ч. для того, чтобы можно было отобразить страницу. Если мы пытаемся отобразить новость, то сначала проверяются права на базовый модуль/метод этой страницы (news::item()), а потом уже непосредственно доступ на чтение самой страницы.

Права доступа на страницы определяют возможность просмотра или редактирования этих страниц. Так есть 3 уровня доступа к страницам: 0, 1, 2 - "нет доступа", "только чтение", "чтение и запись". Наследование прав пользователя от его групп работает так же, как и для прав на функционал.

Права доступа на страницы назначаются, например при создании или редактировании этой страницы в административном интерфейсе. В данном случае это визуально отображено в интерфейсе. Некоторые особенности есть при выборе прав по умолчанию для страницы (дефолтное состояние галочек в форме создания страниц, права на страницы, созданные с сайта, права на топики, сообщения форума и т.д..)

В том случае, если права явно не задаются при создании страницы, они определяются следующим образом:

Непосредственно на объекты права не выставляются (т.е. 2 виртуальные копии одной страницы вполне могут иметь разные настройки прав, но ссылаться на один и тот же объект). Однако, существует механизм владения объекта.

Для объектов введен термин владелец объекта: владелец объекта — это пользователь, под которым был создан этот объект.

Данное свойство объекта в основном системное и используется для того, чтобы пользователи не могли редактировать чужие учетные записи и т.д.