Вопрос

Как снять у пользователей право на "изменение доступа" на собственные записи?

9 июня 2012 15:38

Добрый день.

При текущей настройке прав доступа, автор записи получает все права на эту запись (чтение, изменение, удаление, изменение доступа).
Допустим пользователи входят в две группы "Менеджеры" и "Руководство".

Мне необходимо было настроить права так, чтобы все созданные отдельным менеджером Контакты видел только менеджер создатель контакта и все члены группы "Руководство" (это я сделал). Однако у создателя есть право на изменение доступа. Как сделать так, чтоб по умолчанию на создание новой записи этого права у создателя не было (если он входит в группу "Менеджеры").

Сейчас у меня:
Запись Контакта (Доступ):
Гарри Потер (член группы менеджеров, автор записи): Чтение, Изменение, Удаление, Изменение Доступа
Руководство: Чтение, Изменение.

А хочется вот так:

Запись Контакта (Доступ):
Гарри Потер (член группы менеджеров, автор записи): Чтение, Изменение, Удаление
Руководство: Чтение, Изменение.

Нравится

2 комментария

Бакунович Павел Викторович

11 июня 2012 09:16

По умолчанию автор записи всегда имеет полный доступ к созданным записям. Нигде из клиента это не настроить. Если для конкретного раздела Вы хотите ограничить ему доступ, то это делается в триггере по раздаче прав доступа по умолчанию. Если идет речь о таблице контактов, то найдите триггер tr_tbl_Contact_I. Для всех таблиц, которые администрируются по записям есть такой триггер на вставку. Найдите в нем строчки

INSERT INTO [dbo].[tbl_AccountRight] (
    [ID]
    ,[RecordID]
    ,[AdminUnitID]
    ,[CanRead]
    ,[CanWrite]
    ,[CanDelete]
    ,[CanChangeAccess])
  SELECT
    newid()
    ,[ID]
    ,@AdminUnitID
    ,1
    ,1
    ,1
    ,1
  FROM INSERTED

и замените последнюю единичку на ноль. Но хочу заметить, что после пересохранения сервиса таблицы контактов(tbl_Contact) этот триггер перетерется на стандартный и Ваши изменения исчезнут(а сервис пересохраняется и в случае создания доп. полей). Так что нужно либо всегда помнить об этом и изменять триггер, если он изменится, либо поступить более радикально и изменить процедуру создания этих триггеров. Но в этом случае при пересохранении любого сервиса таблицы администруруемой по записям будет создаваться триггер, который раздает права с учетом Ваших пожеланий ограничения прав для автора записи. Хранимая процедура называется tsp_AdministratedByRecords. В ней очень похожий блок кода

	'  INSERT INTO ' + @RightTableName + ' (' + @NL +
	'    [ID]' + @NL +
	'    ,[RecordID]' + @NL +
	'    ,[AdminUnitID]' + @NL +
	'    ,[CanRead]' + @NL +
	'    ,[CanWrite]' + @NL +
	'    ,[CanDelete]' + @NL +
	'    ,[CanChangeAccess])' + @NL +
	'  SELECT' + @NL +
	'    newid()' + @NL +
	'    ,[ID]' + @NL +
	'    ,@AdminUnitID' + @NL +
	'    ,1' + @NL +
	'    ,1' + @NL +
	'    ,1' + @NL +
	'    ,1' + @NL +
	'  FROM INSERTED' + @NL +

Опять же, вместо последней единицы, вставляете ноль.

Ответить

Alimova Anna

11 июня 2012 14:27

С переделыванием триггеров таблицы есть нюансы - в случае, если Вами будет пересохранена таблица из конфигурации, триггер восстановится к коробочному состоянию. Для того, чтобы он не менялся, необходимо вносить изменения в хранимую процедуру, генерирующую триггеры - отдельно описывать данный конкретный триггер, а эта задача чересчур трудоемкая.

Рекомендую реализовать обходное решение на уровне конфигурации - при добавлении записи на AfterPost (т.е., когда уже сработали все триггеры) фильтровать в таблице прав нужную запись, и менять для нее право на раздачу доступа на false.

Ответить

Показать все комментарии