Как закблокировать форму редактирования ContactEdit

Здравствуйте!
Самым надежным(!) способом будет управление правами доступа. В "определенное значение поля ДБ" кто-то пишет, вот пусть когда это происходит снимается полный доступ пользователям, а остается только на чтение и на оборот. Карточка и гриды автоматически будут в режиме "только чтение".

Добрый день!
А пример кода как можно изменить программно эти самые права можете привести?

Два варианта:
1. Скриптами в конфигурации.
2. Триггером на сервере.
Какой для Вас проще?

Меня больше интересует вариант 1(Скриптами в конфигурации).

1. У dataset, который используется в карточке, в событии OnAfterPost делаем обработчик.
2. Выбираем записи из таблицы доступа с фильтром по полю RecordID куда подставляете значение ID из dataset п.1
3. По выбранным записям выполняете update. Где для поля CanUpdate - ставите false, если выполняется условие "определенное значение поля ДБ", иначе ставите - true.
4. Можете еще подумать, что делать с полями CanDelete и CanChangeAccess - зависит от Ваших требований.

А какое название у таблицы доступа?

Название таблица прав состоит из имени таблицы для которой права + Right. Для Контактов соответственно tbl_ContactRight.

Добрый день!
Решил руками попробовать как работает этот механиз, в таблице tbl_ContactRight установил все поля таблицы СanRead, CanWrite, CanChangeAcess в 0, в результате все карточки как и раньше подлежит редактированию. Проясните пожалуйста ситуацию? Как с этим механизмом правильно работать?

P.S.
Мне бы подошел вариант заблокировать карточку с каким то RecordID для (Всех пользователей), то есть как я понимаю для этого необходимо установить все поля которые начинаются с Сan.. в 0 для AdminUnitID=6cd52759-5503-4130-8acc-4ad6b342c010(Все пользователи). Проблема тока в том, что у меня оно не блокируется почему то.

1. Вы работаете под пользователем с правами администратора. Защиты от него нет, что логично. Так как администратор может делать, что захочет, на то ему и дали "супер" права. Можно и для него заблокировать, но это будет "псевдо" защита...
2. Можно заблокировать. Но опять же это будет не защита... В скрипте scr_BaseDBEditUtils:

...
function InitializeDBEditDataset(Datalink, BaseDBEdit, Window) {
        ... // <--- Дописать в конец функции
	var Attributes = Window.Attributes;
	if (!IsEmptyValue(Attributes('IsReadOnly'))) {
		BaseDBEdit.IsReadOnly = Attributes('IsReadOnly');
	} else {
		BaseDBEdit.IsReadOnly = false;
	}
	if (!BaseDBEdit.IsReadOnly){
		return;
	}
	var Dataset = BaseDBEdit.Dataset;
	var DataFields = Dataset.DataFields;
	for(var i = 0, Count = DataFields.Count; i < Count; i++){
		DataFields.Items(i).IsReadOnly = true;
	}
}
...

Передайте в карточку редактирования атрибут IsReadOnly со значением true и все поля в карточке станут не редактируемыми.

Добрый день!
Вопрос по теме:
для каждого контакта в системе, являющегося сотрудником нашей компании, существует список лиц, который контролируют его работу (так сказать его руководители). Этот список лиц реализован в качестве детали в реестре Контакты. Необходимо, что бы любую карточку (Задача, Продажа и тд) мог редактировать не только ответственный, но и все лица, находящиеся у него в вышеописанной закладке.
В данной теме описывается способ закрытия доступа, а мне нужно наоборот открыть доступ на редактирование, обойдя основные настройки прав доступа.
Мне пока в голову пришел только один способ решения:
как описано в этой теме - редактировать таблицы с правами. Если я буду делать это редактирование перед открытием карточки (задачи. продажи), насколько это замедлит работу? Или есть более удобные способы?

Правильно настроенные "Права доступа по умолчанию" должны решить Вашу проблему.

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

Создавайте группы пользователей в соответствии с их ролями (должностями), даже если там всего один пользователь. Когда в компании появляется новый сотрудник, мы просто добавляем нового пользователя в соответствующие группы.

объясню поподробней:
есть Ответственный - он видит только свою задачу и может ее редактировать
у этого Ответственного есть несколько Начальников, которые следят за его работой, они так же должны редактировать только задачу их Ответственного, и никакие другие задачи не могут изменять.

Если сделать группами, тогда у меня должна быть группа Начальников, которым я дам права на все задачи. А мне не надо так.

Придумала такой вариант: при добавлении записи в таблицу с начальниками, сразу в таблицу с правами по-умолчанию добавлять нового начальника, а так его добавлять в другие записи, где Ответственным является подчиненный. Соответственно, удалять права,если начальника удалили из таблицы.
Какие могут возникнуть проблемы?

Может, есть возможность просто давать право на редактирование пользователю при открытии карточки задачи, если он начальник ответственного?

Такой вариант:
1. Заводим нового сотрудника [ФИО]. (создаем пользователя для исполнителя)
2. Создаем группу "Начальники [ФИО]". (Включаем соответствующих пользователей в эту группу).
3. Настраиваем права доступа по умолчанию.

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

"Kat" написал:Придумала такой вариант: при добавлении записи в таблицу с начальниками, сразу в таблицу с правами по-умолчанию добавлять нового начальника, а так его добавлять в другие записи, где Ответственным является подчиненный. Соответственно, удалять права,если начальника удалили из таблицы.
Какие могут возникнуть проблемы?

Kat, по моему мнению, лучше скомбинировать вариант Сергея с Вашим. А именно: хоть менеджеров и много, потратить один раз некоторое количество времени и создать для каждого из них группу начальников (можно даже сделать это скриптом SQL или написать действие в скриптах TS Administrator). После этого корректно настроить права по умолчанию (именно по созданным группам начальников, а не по конкретным пользователям). А далее можно реализовать функционал включения/исключения пользователя в/из группы при добавлении/удалении его на/из детали руководителей в разделе "Контакты". Конечно же, для уже существующих записей необходимо установить права вручную или SQL-скриптом.

Данный вариант будет работать гораздо быстрее, чем предложенный Вами (раздача прав на конкретных пользователей), так как для конкретных записей в разделах права изменяться вообще не будут (они уже установлены для этих групп). В Вашем же случае необходимо:
а) добавить пользователя из детали руководителей в таблицу прав по умолчанию для каждого раздела (а не в одну группу);
б) для всех записей в каждом разделе, по которым подчинённый является ответственным, добавить соответствующие записи в таблицу прав этого раздела для руководителя.

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

Олег, все поняла.
Да, так и сделаю. Огромное спасибо за совет.
Один момент не очень понятен:

"Лабьяк Олег Игоревич" написал:После этого корректно настроить права по умолчанию (именно по созданным группам начальников, а не по конкретным пользователям).

Я думала делать так: в права по-умолчанию для проекта каждому менеджеру назначить его группу руководителей.
А что вы имели ввиду?

Это я и имел в виду: выделяем пользователя (менеджера), нужный раздел и на детали "Права по умолчанию" добавляем группу его руководителей.