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

Нравится

2 комментария
Лучший ответ

Думаю что вам может помочь это бесплатное приложение.

Думаю что вам может помочь это бесплатное приложение.

Григорий Чех, спасибо Вам большое.

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

Добрый день!

Пытаюсь дать права группе пользователей на деталь Чат.
В закладке "Права доступа на группу таблиц" добавила новую группу таблиц. Проверила в базе, что такая роль появилась.
Дальше в администраторе указала таблице чата группу таблиц.
После дала права нужной группе в "Права доступа на группу таблиц".

Права на чтение и добавление работают.
А вот на изменение и удаление нет. Кнопка "изменить" активна, но при нажатии выскакивает сообщение "Правом на это действие обладает Администратор"

Подскажите как быть? может я что-то упускаю?

Нравится

1 комментарий

Вопрос снимаю, оказалось, что запрет на изменение был прописан прямо в коде

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

Нужно реализовать проставление прав доступа на чтение для указанного контакта для следущих сущностей вращающихся вокруг контрагента:
1. Задачи (у задачи есть связка с контрагентом - поле "Контрагент")
2. Договора (у договора есть связка с контрагентом - поле "Клиент")
3. Счета (у счета есть связка с контрагентом - поле "Клиент")
4. Расходные накладные (у расходной накладной есть связка с контрагентом - поле "Получатель")

Использоваться этот функционал будет в бизнес-процессе передачи контрагента другому ответственному. Я так понимаю, что выполнение раздачи прав на чтение ответственному нужно выполнять на стороне SQL-сервера. Помогите понять как это сделать. Нужно создать хранимую процедуру и вызывать ее? Как это делается правильно? Если можно, дайте пример.

Terrasoft XRM 3.3.1.146 MS SQL

Нравится

14 комментариев

Хранимой процедуре может не хватить прав, лучше делать триггером.
Мы реализовывали специальное расширение, которое позволяет управлять такой раздачей прав на уровне пользователя (триггеры генерируются автоматически):
http://community.terrasoft.ua/catalog/4879

"Валерий Андрусик" написал:Хранимой процедуре может не хватить прав, лучше делать триггером.

Почему может не хватить? Можно же ее снабдить необходимыми правами. А триггеры сложнее отлаживать.

А пример можно какой-то? Или может в стандартной конфигурации есть что посмотреть по этому поводу?

Можно посмотреть, но у меня сейчас нет доступа, поищите по слову DBEngine глобальным поиском. что-то вроде:

Connector.DBEngine.ExecuteCustomSQL("<имя процедуры>", Parameters);

По умолчанию процедура вызывается от имени и имеет права создателя, если не указано явно, что она должна вызываться от имени пользователя.

"Раловец Ольга" написал:Почему может не хватить? Можно же ее снабдить необходимыми правами. А триггеры сложнее отлаживать.

Зависит от версии MSSQL у топик-стартера.
Для корректной раздачи прав доступа процедура должна выполняться с правами владельца базы. По-моему в MSSQL 2000 еще не было возможности указать процедуре выполняться AS OWNER.

"Валерий Андрусик" написал:Зависит от версии MSSQL у топик-стартера.

У меня версия MS SQL 2005. Думаю использовать хранимую процедуру, чтобы хоть какая-то наглядность была, когда читаешь код конфигурации.

Решил использовать вот такую процедуру:

set ANSI_NULLS ON
set QUOTED_IDENTIFIER ON
go
 
 
CREATE procedure [dbo].[tsp_AddReadRightsToAccountHistory]
	@AccountID uniqueidentifier,
	@OwnerID uniqueidentifier
as
begin
	set nocount on
 
	declare @AuOwnerID uniqueidentifier
	declare @TaskID uniqueidentifier
	declare @ContractID uniqueidentifier
	declare @InvoiceID uniqueidentifier
	declare @OfferingMovementID uniqueidentifier
 
	if @AccountID is NULL OR @OwnerID is NULL return
 
	SET @AuOwnerID = (SELECT ID FROM tbl_AdminUnit
                          WHERE UserContactID = @OwnerID)
 
	IF @AuOwnerID IS NULL return
 
	-- Проставление доступа на чтение для задачи привязанных к указанному контрагенту
	declare c_Task cursor FOR
	  SELECT ID FROM tbl_Task
	  WHERE AccountID = @AccountID
 
	OPEN c_Task
	FETCH NEXT FROM c_Task INTO @TaskID
	WHILE @@FETCH_STATUS=0
	BEGIN
        INSERT INTO tbl_TaskRight
        (ID, RecordID, AdminUnitID, CanRead, CanWrite, CanDelete, CanChangeAccess)
        VALUES (NewID(), @TaskID, @AuOwnerID, 1, 0, 0, 0)		
		FETCH NEXT FROM c_Task INTO @TaskID
	END
	CLOSE c_Task
	DEALLOCATE c_Task
 
	-- Проставление доступа на чтение для всех договоров контрагента
	declare c_Contract cursor FOR
	  SELECT ID FROM tbl_Contract
	  WHERE CustomerID = @AccountID
 
	OPEN c_Contract
	FETCH NEXT FROM c_Contract INTO @ContractID
	WHILE @@FETCH_STATUS=0
	BEGIN
        INSERT INTO tbl_ContractRight
        (ID, RecordID, AdminUnitID, CanRead, CanWrite, CanDelete, CanChangeAccess)
        VALUES (NewID(), @ContractID, @AuOwnerID, 1, 0, 0, 0)		
		FETCH NEXT FROM c_Contract INTO @ContractID
	END
	CLOSE c_Contract
	DEALLOCATE c_Contract
 
	-- Проставление доступа на чтение для всех счетов контрагента
	declare c_Invoice cursor FOR
	  SELECT ID FROM tbl_Invoice
	  WHERE CustomerID = @AccountID
 
	OPEN c_Invoice
	FETCH NEXT FROM c_Invoice INTO @InvoiceID
	WHILE @@FETCH_STATUS=0
	BEGIN
        INSERT INTO tbl_InvoiceRight
        (ID, RecordID, AdminUnitID, CanRead, CanWrite, CanDelete, CanChangeAccess)
        VALUES (NewID(), @InvoiceID, @AuOwnerID, 1, 0, 0, 0)		
		FETCH NEXT FROM c_Invoice INTO @InvoiceID
	END
	CLOSE c_Invoice
	DEALLOCATE c_Invoice
 
	-- Проставление доступа на чтение для всех расходных накладных контрагента
	declare c_OffMov cursor FOR
	  SELECT ID FROM tbl_OfferingMovement
	  WHERE RecipientID = @AccountID
 
	OPEN c_OffMov
	FETCH NEXT FROM c_OffMov INTO @OfferingMovementID
	WHILE @@FETCH_STATUS=0
	BEGIN
        INSERT INTO tbl_OfferingMovementRight
        (ID, RecordID, AdminUnitID, CanRead, CanWrite, CanDelete, CanChangeAccess)
        VALUES (NewID(), @OfferingMovementID, @AuOwnerID, 1, 0, 0, 0)		
		FETCH NEXT FROM c_OffMov INTO @OfferingMovementID
	END
	CLOSE c_OffMov
	DEALLOCATE c_OffMov	
end

Выполняю следующий код при изменении ответственного в карточке контрагента:

var Parameters = CreateSPParameters();
CreateSPParameter(Parameters, 'AccountID', pdtGUID, AccountID);
CreateSPParameter(Parameters, 'OwnerID', pdtGUID, OwnerID);
var SQLText = 'exec [tsp_AddReadRightsToAccountHistory] :AccountID, :OwnerID';
Connector.DBEngine.ExecuteCustomSQL(SQLText, Parameters);

Всем спасибо за советы :smile:

Проверьте, работает ли под обычным пользователем, не администратором.
Возможно после CREATE PROCEDURE надо добавить ключевые слова:

  CREATE PROCEDURE .... WITH EXECUTE AS OWNER
  AS
    ...

"Валерий Андрусик" написал:Проверьте, работает ли под обычным пользователем, не администратором.

Пока нареканий не было. Посмотрим.

"Валерий Андрусик" написал:Проверьте, работает ли под обычным пользователем, не администратором.
Возможно после CREATE PROCEDURE надо добавить ключевые слова:
CREATE PROCEDURE .... WITH EXECUTE AS OWNER
AS
...

Попробовал, почему-то все равно не хочет запускаться под другими пользователями. Сейчас ищу решение.

CREATE PROCEDURE .... WITH EXECUTE AS 'dbo'

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

Или так

grant execute on [dbo].tsp_AddReadRightsToAccountHistory to public

"Кулак Олег" написал:GRANT execute ON [dbo].tsp_AddReadRightsToAccountHistory TO public

Спасибо :) Так удобней

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

Разбираюсь с назначением прав доступа, и в разделе "Администрирования" на закладке "Права доступа по умолчанию" вместе с таблицами теперь есть и Группы таблиц, однако в описании "Руководства администратора" эта закладка называется просто "Права доступа на таблицы по умолчанию" и про группы таблиц там ничего не говориться. Можно узнать как работает механизм доступа по умолчанию на группу таблиц и как этот механизм взаимодействует с назначением прав на группы таблиц на закладке "Права доступа к группам таблиц"?

Нравится

7 комментариев

Добрый день, Руслан!

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

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

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

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

А зачем тогда на закладку "Права доступа по умолчанию" были добавлены объекты Группы таблиц? т.е. раньше были только таблицы, я думал, может новая фича?

А зачем тогда на закладку "Права доступа по умолчанию" были добавлены объекты Группы таблиц? т.е. раньше были только таблицы, я думал, может новая фича?

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

В версиях начиная с 3.2.0.x реализовано администрирование таблиц групп раздела (т.е. содержимого дерева групп в каждом разделе). Отношения к группам таблиц эти группы не имеют.

В смысле, если пользователю не дать права на создание "Групп Контрагентов", то он не сможет сохранять фильтр динамических групп и создавать группы в разделе Контрагентов? Так? Т.е. если необходимо иметь стандартный вариант динамических и статических групп в разделе, то можно в "доступе по умолчанию" к группам для нужного раздела, дать пользователям доступ только на чтение. Потом, создать под администратором необходимый набор групп, и уже в соответствующем разделе(по правой клавише на группе) раздать доступ на чтение нужным группам пользователей и пользователям, правильно?

Да, совершенно верно.

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

Спасибо, за ответ, сейчас занимаюсь проектированием прав доступа, это очень помогло :-)

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