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

Материал из GedeminWiki
(Различия между версиями)
Перейти к: навигация, поиск
Строка 12: Строка 12:
 
* Управление доступом не только к документам/проводкам, но и к любым данным (таблицам). Например, запретить пользователю менять справочник клиентов или товаров.
 
* Управление доступом не только к документам/проводкам, но и к любым данным (таблицам). Например, запретить пользователю менять справочник клиентов или товаров.
 
* Условное разграничение доступа к записям таблицы на основе данных. Например, запретить пользователю менять клиентов только из Брестской области, или запретить создавать складские документы с товаром из группы Спецтовары, или запретить менять документы, которые приводят к созданию/изменению проводок по 20-му счету.
 
* Условное разграничение доступа к записям таблицы на основе данных. Например, запретить пользователю менять клиентов только из Брестской области, или запретить создавать складские документы с товаром из группы Спецтовары, или запретить менять документы, которые приводят к созданию/изменению проводок по 20-му счету.
 +
* При вычислении правила можно обращаться к:
 +
** Полям таблицы
 +
** Полям связанных таблиц
 +
** Встроенным функциям (например CURRENT_DATE)
 +
** Глобальным переменным
 
* Разграничение доступа для всех, групп пользователей, списка учетных записей.
 
* Разграничение доступа для всех, групп пользователей, списка учетных записей.
 
* На поля типа дата (частный случай -- дата документа или дата проводки) могут накладываться условия: за n дней (например, запретить редактирование документов старше 30 дней), до 1 числа текущего месяца, до 1 числа предыдущего месяца, до 1 числа квартала, года и т.п.
 
* На поля типа дата (частный случай -- дата документа или дата проводки) могут накладываться условия: за n дней (например, запретить редактирование документов старше 30 дней), до 1 числа текущего месяца, до 1 числа предыдущего месяца, до 1 числа квартала, года и т.п.
Строка 20: Строка 25:
  
  
−
 
+
Приведем несколько наиболее востребованных типовых сценариев ограничения доступа к данным:
−
 
+
−
Для разграничения прав доступа и защиты данных в Гедымине используются следующие механизмы:
+
−
 
+
−
===Аутентификация пользователя===
+
−
 
+
−
Список пользователей хранится в таблице [[GD_USER]]. Каждый пользователь Гедымина сопоставлен своей учетной записи на сервере Firebird. Поскольку в Firebird до версии 3.0 список учетных записей хранится отдельно, то при переносе БД на другой сервер следует '''пересоздать''' учетные записи с помощью соответствующей команды в окне списка пользователей. Пользователю '''Administrator''' Гедымина (является частью эталонной базы данных) сопоставлена учетная запись '''SYSDBA''' сервера Firebird с максимальными правами. При создании нового пользователя в Гедымине автоматически создается учетная запись сервера Firebird, которой даются права на использование роли Administrator (является частью эталонной базы данных. Не путать с пользователем Administrator!). Доступ к объектам базы данных предоставлен вышеуказанной роли.
+
−
 
+
−
Существует специальная 
+
−
 
+
−
* Разграничение доступа к бизнес-классам
+
−
 
+
−
 
+
−
Первоначальная реализация блокировки была чрезвычайно проста: 4 триггера на таблицах документов, проводок и складского движения, которые сравнивали дату из соответствующего поля со значением в генераторе (дата, как число хранится в генераторе, чтобы не заводить отдельной таблицы). При срабатывании условия -- выбрасывалось исключение. Позже механизм усложнили, позволив исключать некоторые типы документов и некоторые группы пользователей (см. например, [[GD_BI_ENTRY_BLOCK]]).
+
−
 
+
−
В таком виде блокировка периода не позволяет удовлетворить все запросы наших клиентов. Приведем несколько наиболее востребованных типовых сценариев ограничения доступа к данным:
+
  
 
* Бухгалтерия закрывает месяц и считает налоги до 20-го числа следующего месяца. После этой даты документы должны быть заблокированы на изменение.
 
* Бухгалтерия закрывает месяц и считает налоги до 20-го числа следующего месяца. После этой даты документы должны быть заблокированы на изменение.
Строка 43: Строка 33:
 
* и т.п.
 
* и т.п.
  
−
Предполагается переработать механизм, реализовав следующую функциональность:
 
−
 
−
* Правила блокировки должны являться бизнес-объектами и храниться в самой базе данных
 
−
* Правила блокировки можно переносить между базами с помощью ПИ
 
−
* Правило можно устанавливать для любой таблицы
 
−
* При вычислении правила можно обращаться к:
 
−
** Полям таблицы
 
−
** Полям связанных таблиц
 
−
** Встроенным функциям (например CURRENT_DATE)
 
−
** Глобальным переменным
 
−
* Правила вычисляются на стороне сервера с помощью триггеров
 
−
* В процессе вычисления правил должны быть минимизированы обращения к базе данных
 
−
 
−
===Краткое описание существующего механизма блокировки периода===
 
−
 
−
Изначально, блокировка периода распространялась на все документы и всех пользователей системы. Позже, была добавлена возможность исключить некоторые группы пользователей из блокировки и, наконец, мы добавили возможность исключать некоторые типы документов. Но, период, а точнее дата, до которой запрещается изменять записи в БД, остается фиксированной константой.
 
−
 
−
За определение: подпадает конкретный тип документа под блокировку или нет, отвечает процедура [[gd_p_exclude_block_dt]], которая возвращает 1, если переданный идентификатор типа документа не блокируется и 0 в противном случае. Процедура формируется в окне [[Tgd_dlgOptions]] при выборе типов документов исключаемых из блокировки. Системными составляющими механизма блокировки периода являются генераторы [[gd_g_block]] и [[gd_g_block_group]]. Первый хранит дату, до которой документы считаются заблокированными, а второй -- битовую маску групп пользователей, на которых распространяется блокировка. Механизм реализуется с помощью 12-ти триггеров, по три на каждую из четырех таблиц: [[gd_document]], [[AC_ENTRY|ac_entry]], [[AC_RECORD|ac_record]] и [[INV_MOVEMENT|inv_movement]]. Существующий триггер блокировки периода выглядит [[Триггер блокировки периода (старая версия)|следующим образом]]. В случае нарушения условия блокировки вызывается исключение [[gd_e_block]].
 
−
 
−
Данный механизм имеет следующие ограничения:
 
−
 
−
* Нельзя устанавливать разные периоды для разных типов документов;
 
−
* Нельзя устанавливать разные периоды для разных групп пользователей;
 
−
* Дата блокировки задается фиксированной константой.
 
  
 
== Новый механизм блокировки ==
 
== Новый механизм блокировки ==

Версия 17:14, 17 октября 2017

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

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

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

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

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

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


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

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


Новый механизм блокировки

Предлагается модифицировать механизм блокировки периода следующим образом:

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

Изменение параметров блокировки осуществляется в диалоговом окне Опции системы на вкладке Блокировка. Изменение возможно только под учетной записью Administrator (данное требование проистекает из необходимости формирования хранимой процедуры). Если зашли под другой учетной записью, то на вкладке скрываем все визуальные контролы и пишем пояснительное сообщение.

Вверху вкладки предусмотрим чек-бокс "Блокировка включена". Если он выключен, то больше в разделе ничего не показывается. Если включен, то появляется таблица с тремя колонками. Высота строк таблицы не фиксирована и зависит от содержимого.

Колонки таблицы

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

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

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

block.png

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

Информацию о параметрах блокировки планируется хранить в таблице 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
Источник — «https://gsbelarus.com:80/gs/wiki/index.php?title=%D0%91%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B0_%D0%BF%D0%B5%D1%80%D0%B8%D0%BE%D0%B4%D0%B0_(%D0%BF%D0%BE%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0)&oldid=7293»
Персональные инструменты
Пространства имён

Варианты
Действия
Навигация
Инструменты