Блокировка периода (постановка) - История изменений

SYSDBA в 15:42, 17 октября 2017

2017-10-17T15:42:00Z

SYSDBA в 14:14, 17 октября 2017

2017-10-17T14:14:21Z

SYSDBA в 14:10, 17 октября 2017

2017-10-17T14:10:14Z

SYSDBA в 11:25, 3 апреля 2017

2017-04-03T11:25:51Z

SYSDBA в 17:59, 2 апреля 2017

2017-04-02T17:59:34Z

SYSDBA в 11:54, 28 февраля 2017

2017-02-28T11:54:00Z

SYSDBA в 07:09, 11 февраля 2017

2017-02-11T07:09:06Z

SYSDBA в 09:41, 9 февраля 2017

2017-02-09T09:41:44Z

SYSDBA в 11:29, 7 февраля 2017

2017-02-07T11:29:23Z

SYSDBA в 09:52, 7 февраля 2017

2017-02-07T09:52:22Z

@@ Строка 1: / Строка 1: @@
 Кто-то, что-то, где-то может изменить и это большая проблема для базы данных. Хорошо, если расхождение обнаружено по горячим следам, а если прошло несколько месяцев? Если неверные данные привели к неверным расчетам по налогам?
-Изначально в Гедымине мы предусмотрели простой механизм блокировки на триггерах:
+Изначально, в Гедымине мы предусмотрели простой механизм блокировки на триггерах:
 * Защищались только четыре основных таблицы: документы, проводки и складское движение.
 * Защита управлялась единственным параметром: датой, до которой блокировались все изменения.
-Позже, добавили возможность указать группы пользователей, на которых распространяется блокировка и список типов документов.
+Позже, мы добавили возможность указать группы пользователей, на которых распространяется блокировка, и список типов документов.
 Такие возможности не удовлетворяют текущим потребностям наших клиентов. Необходим следующий функционал:
 * Управление доступом не только к документам/проводкам, но и к любым данным (таблицам). Например, запретить пользователю менять справочник клиентов или товаров.
-* Условное разграничение доступа к записям таблицы на основе данных. Например, запретить пользователю менять клиентов только из Брестской области, или запретить создавать складские документы с товаром из группы Спецтовары, или запретить менять документы, которые приводят к созданию/изменению проводок по 20-му счету.
+* Условное разграничение доступа к записям таблицы на основе данных. Например, запретить пользователю менять клиентов только из Брестской области, или запретить создавать складские документы с товаром из группы Спецтовары, или запретить менять документы, которые приводят к созданию/изменению проводок по 20-му счету. При этом, при вычислении правила можно обращаться к:
-* При вычислении правила можно обращаться к:
 ** Полям таблицы
 ** Полям связанных таблиц
 ** Встроенным функциям (например CURRENT_DATE)
 ** Глобальным переменным
-* Разграничение доступа для всех, групп пользователей, списка учетных записей.
+** На поля типа дата (частный случай -- дата документа или дата проводки) могут накладываться условия: за n дней (например, запретить редактирование документов старше 30 дней), до 1 числа текущего месяца, до 1 числа предыдущего месяца, до 1 числа квартала, года и т.п.
-* На поля типа дата (частный случай -- дата документа или дата проводки) могут накладываться условия: за n дней (например, запретить редактирование документов старше 30 дней), до 1 числа текущего месяца, до 1 числа предыдущего месяца, до 1 числа квартала, года и т.п.
+* Разграничение доступа для всех, групп пользователей, списка учетных записей, единственной учетной записи.
 * Разграничение доступа по времени суток. Например, запретить создание накладных вне рабочего дня с 8:00 до 17:00.
-* Разграничение доступа по компьютеру (ip адресу).
+* Разграничение доступа по компьютеру (ip адресу). Например, создание платежных документов только с рабочего место ответственного бухгалтера.
 * Разграничение доступа к отдельным полям.
 * Правила доступа должны быть бизнес-объектами и переноситься с базы на базу посредством ПИ.
+* Блокировка должна быть реализована на уровне БД посредством триггеров.
 Приведем несколько наиболее востребованных типовых сценариев ограничения доступа к данным:
@@ Строка 33: / Строка 32: @@
 * и т.п.
+Ниже представлены эскизы и предварительные наброски по системе блокировки и разграничения:
-== Новый механизм блокировки ==
-−
-Предлагается модифицировать механизм блокировки периода следующим образом:
 === Интерфейс пользователя ===
-Изменение параметров блокировки осуществляется в диалоговом окне [[Опции системы]] на вкладке Блокировка. Изменение возможно только под учетной записью [[Administrator]] (данное требование проистекает из необходимости формирования хранимой процедуры). Если зашли под другой учетной записью, то на вкладке скрываем все визуальные контролы и пишем пояснительное сообщение.
+Ниже приведен вариант организации пользовательского интерфейса:
-Вверху вкладки предусмотрим чек-бокс "Блокировка включена". Если он выключен, то больше в разделе ничего не показывается. Если включен, то появляется таблица с тремя колонками. Высота строк таблицы не фиксирована и зависит от содержимого.
+http://gsbelarus.com/gs/images/gs/2007/block.png
-−
-==== Колонки таблицы ====
 * '''Типы документов'''. Вверху клетки находится группа радиокнопок: Все, Указанные, Кроме указанных. Под ними отображается список наименований типов документов через запятую. В правой части ячейки находится кнопка "..." для выбора типов документов (изменения списка).
@@ Строка 53: / Строка 47: @@
 Возможно, для отображения таблицы стоит использовать компонент [[TScrollBox]], на котором в зависимости от выбора пользователя динамически располагать компоненты.
 === Хранение информации о блокировке ===

@@ Строка 12: / Строка 12: @@
 * Управление доступом не только к документам/проводкам, но и к любым данным (таблицам). Например, запретить пользователю менять справочник клиентов или товаров.
 * Условное разграничение доступа к записям таблицы на основе данных. Например, запретить пользователю менять клиентов только из Брестской области, или запретить создавать складские документы с товаром из группы Спецтовары, или запретить менять документы, которые приводят к созданию/изменению проводок по 20-му счету.
 * Разграничение доступа для всех, групп пользователей, списка учетных записей.
 * На поля типа дата (частный случай -- дата документа или дата проводки) могут накладываться условия: за 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-го числа следующего месяца. После этой даты документы должны быть заблокированы на изменение.
@@ Строка 43: / Строка 33: @@
 * и т.п.
 == Новый механизм блокировки ==

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

@@ Строка 3: / Строка 3: @@
 ===Аутентификация пользователя===
-Список пользователей хранится в таблице [[GD_USER]]. Каждый пользователь Гедымина сопоставлен своей учетной записи на сервере Firebird. Поскольку в Firebird до версии 3.0 список учетных записей хранился отдельно, то при переносе БД на другой сервер следовало пересоздать учетные записи с помощью соответствующей команды в окне списка пользователей. Пользователю '''Administrator''' Гедымина сопоставлена учетная запись '''SYSDBA''' сервера Firebird с максимальными правами. При создании нового пользователя в Гедымине автоматически создается учетная запись сервера Firebird. Этой учетной записи
+Список пользователей хранится в таблице [[GD_USER]]. Каждый пользователь Гедымина сопоставлен своей учетной записи на сервере Firebird. Поскольку в Firebird до версии 3.0 список учетных записей хранится отдельно, то при переносе БД на другой сервер следует '''пересоздать''' учетные записи с помощью соответствующей команды в окне списка пользователей. Пользователю '''Administrator''' Гедымина (является частью эталонной базы данных) сопоставлена учетная запись '''SYSDBA''' сервера Firebird с максимальными правами. При создании нового пользователя в Гедымине автоматически создается учетная запись сервера Firebird, которой даются права на использование роли Administrator (является частью эталонной базы данных. Не путать с пользователем Administrator!). Доступ к объектам базы данных предоставлен вышеуказанной роли.
 * Разграничение доступа к бизнес-классам

← Предыдущая		Версия 17:59, 2 апреля 2017
Строка 1:		Строка 1:
	Для разграничения прав доступа и защиты данных в Гедымине используются следующие механизмы:		Для разграничения прав доступа и защиты данных в Гедымине используются следующие механизмы:

−	* Аутентификация пользователя	+	===Аутентификация пользователя===
		+
		+	Список пользователей хранится в таблице [[GD_USER]]. Каждый пользователь Гедымина сопоставлен своей учетной записи на сервере Firebird. Поскольку в Firebird до версии 3.0 список учетных записей хранился отдельно, то при переносе БД на другой сервер следовало пересоздать учетные записи с помощью соответствующей команды в окне списка пользователей. Пользователю '''Administrator''' Гедымина сопоставлена учетная запись '''SYSDBA''' сервера Firebird с максимальными правами. При создании нового пользователя в Гедымине автоматически создается учетная запись сервера Firebird. Этой учетной записи
		+
		+	* Разграничение доступа к бизнес-классам

← Предыдущая		Версия 11:54, 28 февраля 2017
Строка 1:		Строка 1:
		+	Для разграничения прав доступа и защиты данных в Гедымине используются следующие механизмы:
		+
		+	* Аутентификация пользователя
		+
		+
	Первоначальная реализация блокировки была чрезвычайно проста: 4 триггера на таблицах документов, проводок и складского движения, которые сравнивали дату из соответствующего поля со значением в генераторе (дата, как число хранится в генераторе, чтобы не заводить отдельной таблицы). При срабатывании условия -- выбрасывалось исключение. Позже механизм усложнили, позволив исключать некоторые типы документов и некоторые группы пользователей (см. например, [[GD_BI_ENTRY_BLOCK]]).		Первоначальная реализация блокировки была чрезвычайно проста: 4 триггера на таблицах документов, проводок и складского движения, которые сравнивали дату из соответствующего поля со значением в генераторе (дата, как число хранится в генераторе, чтобы не заводить отдельной таблицы). При срабатывании условия -- выбрасывалось исключение. Позже механизм усложнили, позволив исключать некоторые типы документов и некоторые группы пользователей (см. например, [[GD_BI_ENTRY_BLOCK]]).

@@ Строка 1: / Строка 1: @@
-Изначальная реализация блокировки была чрезвычайно проста: 4 триггера на таблицах документов, проводок и складского движения, которые сравнивали дату из соответствующего поля со значением в генераторе (дата, как число хранится в генераторе, чтобы не заводить отдельной таблицы). При срабатывании условия -- генерировалось исключение.
+Первоначальная реализация блокировки была чрезвычайно проста: 4 триггера на таблицах документов, проводок и складского движения, которые сравнивали дату из соответствующего поля со значением в генераторе (дата, как число хранится в генераторе, чтобы не заводить отдельной таблицы). При срабатывании условия -- выбрасывалось исключение. Позже механизм усложнили, позволив исключать некоторые типы документов и некоторые группы пользователей (см. например, [[GD_BI_ENTRY_BLOCK]]).
-−
 Позже механизм усложнили, позволив исключать некоторые типы документов и некоторые группы пользователей.
-−
-В таком виде блокировка периода не позволяет удовлетворить все запросы наших клиентов. Приведем несколько типовых сценариев ограничения доступа к данным:
-−
-−
-−
 Предполагается переработать механизм, реализовав следующую функциональность:

← Предыдущая		Версия 11:29, 7 февраля 2017
Строка 1:		Строка 1:
−	~~Требования к системе~~ блокировки ~~изменения данных~~:	+	Изначальная реализация блокировки была чрезвычайно проста: 4 триггера на таблицах документов, проводок и складского движения, которые сравнивали дату из соответствующего поля со значением в генераторе (дата, как число хранилась в генераторе, чтобы не заводить отдельной таблицы). При срабатывании условия -- генерировалось исключение.
		+
		+	Позже механизм усложнили, позволив исключать некоторые типы документов и некоторые группы пользователей.
		+
		+	В таком виде блокировка периода не позволяет удовлетворить все запросы наших клиентов и специалистов по внедрению/сопровождению ПО. Предполагается переработать механизм, реализовав следующую функциональность:

	* Правила блокировки должны являться бизнес-объектами и храниться в самой базе данных		* Правила блокировки должны являться бизнес-объектами и храниться в самой базе данных

← Предыдущая		Версия 09:52, 7 февраля 2017
Строка 111:		Строка 111:

	[[Category:Постановка]]		[[Category:Постановка]]
		+
		+	__NOTOC__