Распределение прав доступа и протоколирование изменений

Работа с данными через классы доступа к данным даёт не только возможность писать универсальный, не зависящий от используемой СУБД код, но также и решить задачу централизованного распределения прав доступа к данным таблиц и протоколирования изменений.

Вызов ряда методов требует наличия соответствующих прав у пользователя на таблицы, прописанных в системных таблицах celesta.userroles и celesta.permissions, в противном случае возникает исключение PermissionDeniedException с сообщением вида "There is no …​ permission for user …​ on object …​".

Если протоколирование изменения таблицы настроено в таблице celesta.logsetup, то вызов некоторых методов будет приводить к созданиям записей в таблице celesta.log.

Метод Требуемые права Протоколирование изменений

[try]first(), [try]get(), next().

на чтение (r)

не протоколируются

[try]insert()

на вставку (i)

протоколируется, если включён флаг i.

  • oldvalues — пустое значение.

  • newvalues — вставляемая запись.

[try]update()

на модификацию (m)

протоколируется, если включён флаг m.

  • oldvalues — состояние записи до модификации.

  • newvalues — состояние записи после модификации.

delete[All]()

на удаление (d)

delete() протоколируется, если включён флаг d.

  • oldvalues — состояние записи до удаление.

  • newvalues — пустое значение.
deleteAll() не протоколируется и триггеры не выполняются.

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

Механизмом распределения прав и протоколирования можно как пользоваться, так и не пользоваться. При этом, если ими не пользоваться, их потенциальное наличие создаёт минимальный overhead по производительности.