Блокировка периода (постановка)

Кто-то, что-то, где-то может изменить и это большая проблема для базы данных. Хорошо, если расхождение обнаружено по горячим следам, а если прошло несколько месяцев? Если неверные данные привели к неверным расчетам по налогам?

Изначально, в Гедымине мы предусмотрели простой механизм блокировки на триггерах:

• Защищались только четыре основных таблицы: документы, проводки и складское движение.
• Защита управлялась единственным параметром: датой, до которой блокировались все изменения.

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

Такие возможности не удовлетворяют текущим потребностям наших клиентов. Необходим следующий функционал:

• Управление доступом не только к документам/проводкам, но и к любым данным (таблицам). Например, запретить пользователю менять справочник клиентов или товаров.
• Условное разграничение доступа к записям таблицы на основе данных. Например, запретить пользователю менять клиентов только из Брестской области, или запретить создавать складские документы с товаром из группы Спецтовары, или запретить менять документы, которые приводят к созданию/изменению проводок по 20-му счету. При этом, при вычислении правила можно обращаться к:
  • Полям таблицы
  • Полям связанных таблиц
  • Встроенным функциям (например CURRENT_DATE)
  • Глобальным переменным
  • На поля типа дата (частный случай -- дата документа или дата проводки) могут накладываться условия: за n дней (например, запретить редактирование документов старше 30 дней), до 1 числа текущего месяца, до 1 числа предыдущего месяца, до 1 числа квартала, года и т.п.
• Разграничение доступа для всех, групп пользователей, списка учетных записей, единственной учетной записи.
• Разграничение доступа по времени суток. Например, запретить создание накладных вне рабочего дня с 8:00 до 17:00.
• Разграничение доступа по компьютеру (ip адресу). Например, создание платежных документов только с рабочего место ответственного бухгалтера.
• Разграничение доступа к отдельным полям.
• Правила доступа должны быть бизнес-объектами и переноситься с базы на базу посредством ПИ.
• Блокировка должна быть реализована на уровне БД посредством триггеров.

Приведем несколько наиболее востребованных типовых сценариев ограничения доступа к данным:

• Бухгалтерия закрывает месяц и считает налоги до 20-го числа следующего месяца. После этой даты документы должны быть заблокированы на изменение.
• Зарплата начисляется до 10-го числа последующего месяца. После этой даты изменение в документах прошлого периода должно быть запрещено.
• Оператор, принимающий заявки на отгрузку готовой продукции, должен иметь возможность редактировать заявки только в течение одной своей рабочей смены.
• Сотрудник сырьевого отдела может изменять данные в справочнике клиентов только для записей, входящих в папку Поставщики.
• и т.п.

Ниже представлены эскизы и предварительные наброски по системе блокировки и разграничения:

Интерфейс пользователя

Ниже приведен вариант организации пользовательского интерфейса:

• Типы документов. Вверху клетки находится группа радиокнопок: Все, Указанные, Кроме указанных. Под ними отображается список наименований типов документов через запятую. В правой части ячейки находится кнопка "..." для выбора типов документов (изменения списка).

• Дата блокировки. Дата, до которой будут заблокированы документы указанных типов. При сравнении дат действует операция строгого неравенства меньше, т.е. сам указанный день блокировки не включается в период блокировки. Можно вводить как фиксированную дату, так и относительную.

• Блокировка распространяется на группы пользователей. Вверху клетки находится группа радиокнопок: Все, Указанные, Кроме указанных. Под ними выводится строкой, через запятую список групп пользователей. Справа выводится кнопка "...", которая позволяет открыть окно для изменения списка.

Возможно, для отображения таблицы стоит использовать компонент TScrollBox, на котором в зависимости от выбора пользователя динамически располагать компоненты.

Хранение информации о блокировке

Информацию о параметрах блокировки планируется хранить в таблице GD_BLOCK_RULE.

Метаданные

 CREATE PROCEDURE gd_p_block (DocDate DATE, DocType INTEGER)
 AS
   DECLARE VARIABLE IG INTEGER;
 BEGIN

   ...
   
   // такой блок кода повторяется для каждой группы типов документов
   IF (DocType IN (12345, 67890, ...)) THEN
   BEGIN
     // если блокировка распространяется на все группы
     // пользователей без исключений, то проверим дату
     // и, при нарушении, вызовем исключение
     IF (DocDate < date `01.01.2001`) THEN
       EXCEPTION gd_e_block;

     // если указаны группы, на которые не распространяется блокировка, 
     // сначала проверяем дату, а затем не попадает ли пользователь
     // в список исключенных групп
     IF (DocDate < date `01.01.2001`) THEN
     BEGIN
       SELECT ingroup FROM gd_user WHERE ibname = CURRENT_USER
         INTO :IG;
       IF (BIN_AND(12345, :IG) = 0) THEN
         EXCEPTION gd_e_block;
     END

     // для ФБ 2.0 можно попробовать избежать лишних чтений из таблицы
     // и кэшировать значение битовой маски в контекстной переменной
     IF (DocDate < date `01.01.2001`) THEN
     BEGIN
       IF (RDB$GET_CONTEXT(`USER_SESSION`, `INGROUP`) = ``) THEN
       BEGIN
         SELECT ingroup FROM gd_user WHERE ibname = CURRENT_USER
           INTO :IG;
         RDB$SET_CONTEXT(`USER_SESSION`, `INGROUP`, :IG);
       END ELSE        
         IG = RDB$GET_CONTEXT(`USER_SESSION`, `INGROUP`);

       IF (BIN_AND(12345, :IG) = 0) THEN
         EXCEPTION gd_e_block;
     END

     // если при задании условия блокировки использовались метапеременные
     // то вычисляем соответствующую им дату. Например, задана переменная
     // ПредМесяц
     M = EXTRACT(MONTH FROM CURRENT_DATE) - 1;
     IF (M = 0) THEN M = 12;
     IF (DocDate < CAST('01.' || M || '.' || EXTRACT(YEAR FROM CURRENT_DATE) AS DATE)) THEN
       EXCEPTION gd_e_block;

   END

   ...
 END