Блокировка периода (постановка)
SYSDBA (обсуждение | вклад) |
SYSDBA (обсуждение | вклад) |
||
| Строка 1: | Строка 1: | ||
| − | + | Первоначальная реализация блокировки была чрезвычайно проста: 4 триггера на таблицах документов, проводок и складского движения, которые сравнивали дату из соответствующего поля со значением в генераторе (дата, как число хранится в генераторе, чтобы не заводить отдельной таблицы). При срабатывании условия -- выбрасывалось исключение. Позже механизм усложнили, позволив исключать некоторые типы документов и некоторые группы пользователей (см. например, [[GD_BI_ENTRY_BLOCK]]). | |
| − | + | ||
| − | Позже механизм усложнили, позволив исключать некоторые типы документов и некоторые группы пользователей. | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | В таком виде блокировка периода не позволяет удовлетворить все запросы наших клиентов. Приведем несколько наиболее востребованных типовых сценариев ограничения доступа к данным: | ||
| + | * Бухгалтерия закрывает месяц и считает налоги до 20-го числа следующего месяца. После этой даты документы должны быть заблокированы на изменение. | ||
| + | * Зарплата начисляется до 10-го числа последующего месяца. После этой даты изменение в документах прошлого периода должно быть запрещено. | ||
| + | * Оператор, принимающий заявки на отгрузку готовой продукции, должен иметь возможность редактировать заявки только в течение одной своей рабочей смены. | ||
| + | * Сотрудник сырьевого отдела может изменять данные в справочнике клиентов только для записей, входящих в папку Поставщики. | ||
| + | * и т.п. | ||
Предполагается переработать механизм, реализовав следующую функциональность: | Предполагается переработать механизм, реализовав следующую функциональность: | ||
Версия 10:09, 11 февраля 2017
Первоначальная реализация блокировки была чрезвычайно проста: 4 триггера на таблицах документов, проводок и складского движения, которые сравнивали дату из соответствующего поля со значением в генераторе (дата, как число хранится в генераторе, чтобы не заводить отдельной таблицы). При срабатывании условия -- выбрасывалось исключение. Позже механизм усложнили, позволив исключать некоторые типы документов и некоторые группы пользователей (см. например, GD_BI_ENTRY_BLOCK).
В таком виде блокировка периода не позволяет удовлетворить все запросы наших клиентов. Приведем несколько наиболее востребованных типовых сценариев ограничения доступа к данным:
- Бухгалтерия закрывает месяц и считает налоги до 20-го числа следующего месяца. После этой даты документы должны быть заблокированы на изменение.
- Зарплата начисляется до 10-го числа последующего месяца. После этой даты изменение в документах прошлого периода должно быть запрещено.
- Оператор, принимающий заявки на отгрузку готовой продукции, должен иметь возможность редактировать заявки только в течение одной своей рабочей смены.
- Сотрудник сырьевого отдела может изменять данные в справочнике клиентов только для записей, входящих в папку Поставщики.
- и т.п.
Предполагается переработать механизм, реализовав следующую функциональность:
- Правила блокировки должны являться бизнес-объектами и храниться в самой базе данных
- Правила блокировки можно переносить между базами с помощью ПИ
- Правило можно устанавливать для любой таблицы
- При вычислении правила можно обращаться к:
- Полям таблицы
- Полям связанных таблиц
- Встроенным функциям (например CURRENT_DATE)
- Глобальным переменным
- Правила вычисляются на стороне сервера с помощью триггеров
- В процессе вычисления правил должны быть минимизированы обращения к базе данных
Краткое описание существующего механизма блокировки периода
Изначально, блокировка периода распространялась на все документы и всех пользователей системы. Позже, была добавлена возможность исключить некоторые группы пользователей из блокировки и, наконец, мы добавили возможность исключать некоторые типы документов. Но, период, а точнее дата, до которой запрещается изменять записи в БД, остается фиксированной константой.
За определение: подпадает конкретный тип документа под блокировку или нет, отвечает процедура gd_p_exclude_block_dt, которая возвращает 1, если переданный идентификатор типа документа не блокируется и 0 в противном случае. Процедура формируется в окне Tgd_dlgOptions при выборе типов документов исключаемых из блокировки. Системными составляющими механизма блокировки периода являются генераторы gd_g_block и gd_g_block_group. Первый хранит дату, до которой документы считаются заблокированными, а второй -- битовую маску групп пользователей, на которых распространяется блокировка. Механизм реализуется с помощью 12-ти триггеров, по три на каждую из четырех таблиц: gd_document, ac_entry, ac_record и inv_movement. Существующий триггер блокировки периода выглядит следующим образом. В случае нарушения условия блокировки вызывается исключение gd_e_block.
Данный механизм имеет следующие ограничения:
- Нельзя устанавливать разные периоды для разных типов документов;
- Нельзя устанавливать разные периоды для разных групп пользователей;
- Дата блокировки задается фиксированной константой.
Новый механизм блокировки
Предлагается модифицировать механизм блокировки периода следующим образом:
Интерфейс пользователя
Изменение параметров блокировки осуществляется в диалоговом окне Опции системы на вкладке Блокировка. Изменение возможно только под учетной записью Administrator (данное требование проистекает из необходимости формирования хранимой процедуры). Если зашли под другой учетной записью, то на вкладке скрываем все визуальные контролы и пишем пояснительное сообщение.
Вверху вкладки предусмотрим чек-бокс "Блокировка включена". Если он выключен, то больше в разделе ничего не показывается. Если включен, то появляется таблица с тремя колонками. Высота строк таблицы не фиксирована и зависит от содержимого.
Колонки таблицы
- Типы документов. Вверху клетки находится группа радиокнопок: Все, Указанные, Кроме указанных. Под ними отображается список наименований типов документов через запятую. В правой части ячейки находится кнопка "..." для выбора типов документов (изменения списка).
- Дата блокировки. Дата, до которой будут заблокированы документы указанных типов. При сравнении дат действует операция строгого неравенства меньше, т.е. сам указанный день блокировки не включается в период блокировки. Можно вводить как фиксированную дату, так и относительную.
- Блокировка распространяется на группы пользователей. Вверху клетки находится группа радиокнопок: Все, Указанные, Кроме указанных. Под ними выводится строкой, через запятую список групп пользователей. Справа выводится кнопка "...", которая позволяет открыть окно для изменения списка.
Возможно, для отображения таблицы стоит использовать компонент 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