Дашборд
дашборды
аналитика
итоги
воронка продаж
права доступа
назначение прав доступа
7.13_()
sales_enterprise

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

Нравится

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

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

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

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

Показать все комментарии
назначение прав доступа
Установка и Администрирование
Разработка

Добрый день!

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

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

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

Нравится

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

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

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

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

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

Terrasoft XRM 3.3.1.146 MS SQL

Нравится

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

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

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

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

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

Можно посмотреть, но у меня сейчас нет доступа, поищите по слову DBEngine глобальным поиском. что-то вроде:
[javascript]
Connector.DBEngine.ExecuteCustomSQL("<имя процедуры>", Parameters);
[/javascript]
По умолчанию процедура вызывается от имени и имеет права создателя, если не указано явно, что она должна вызываться от имени пользователя.

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

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

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

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

Решил использовать вот такую процедуру:
[sql]
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
[/sql]

Выполняю следующий код при изменении ответственного в карточке контрагента:
[javascript]
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);
[/javascript]

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

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

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

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

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

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

[sql]
CREATE PROCEDURE .... WITH EXECUTE AS 'dbo'
[/sql]

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

Или так
[sql]
grant execute on [dbo].tsp_AddReadRightsToAccountHistory to public
[/sql]

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

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

Показать все комментарии
назначение прав доступа
Установка и Администрирование
Разработка

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

Нравится

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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