Добрый день!
Интересуют следующие моменты относительно прав на группы (например, группы обращений)

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

Скажите, пожалуйста, можно ли сделать так, чтобы пользователь-системный администратор не видел такие группы ( они как бы личные - в их доступе явно прописан только создатель группы)
Или быть может можно сделать так, чтобы пользователь-системный администратор по умолчанию не видел эти группы, а видел бы при выборе какого-то действия "отобразить все группы"?

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

Нравится

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

Здравствуйте!

1. Права пользователя с ролью "Системный администратор" можно ограничить исключительно изменением прав доступа на операции. Однако данное действие категорически не рекомендуется выполнять. Пользователь с ролью системный администратор имеет права на чтение, редактирование, удаление всех записей.

2. Права на группу изменяются в настройке прав на группу. Скриншот прилагаю:
Права

Добрый день!
Спасибо, но я не спрашивала, где надо менять права на группу - мне это известно...
Мой первый вопрос звучал так
1.
Скажите, пожалуйста, можно ли сделать так, чтобы пользователь-системный администратор не видел такие группы ( они как бы личные - в их доступе явно прописан только создатель группы)
Или быть может можно сделать так, чтобы пользователь-системный администратор по умолчанию не видел эти группы, а видел бы при выборе какого-то действия "отобразить все группы"?
Правильно я понимаю,
что ответ на мой первый пункт - "Нет, такой явной возможности сейчас нет" ?
Понятно, что права системного администратора не надо ничем ограничивать. Но было бы удобно, если бы у него в разделе бы не было бы видно сразу полного дерева групп, создаваемых разными пользователями. Было бы удобно, если бы те группы, на которые бы у него не было бы явного доступа, по умолчанию бы не отображались, а отображались бы при включении определенной галки..

2. Мой второй вопрос звучал так :
"Есть дерево групп в обращениях. Можно ли сделать так, чтобы пользователь, не являющийся системным администратором, мог бы создавать новые группы только в определенной ветке этого дерева?"
Настройка прав доступа в группе не отвечает на второй вопрос...

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

Добрый день!
По первому пункту была такая возможность в 3.х - было очень удобно. Собственно, поэтому и спрашивала.
По второму пункту - ну вы же предлагаете убрать у них право на чтение групп?)
понятное дело, что если пользователь не видит группы, то и создавать внутри них он ничего не сможет. Мой вопрос был не про это. Я бы хотела, чтобы пользователь видел группы, все какие ему необходимо - разные ветки групп, но новые группы создавал только в определенной ветке.
Но так понимаю, простого способа для этого нет?

Нет, я предлагаю оставить права на чтение, но убрать на изменение и удаление, установив для группы %ваш объект% требуемые настройки администрирования(по записи)

А на что это повлияет? Изменение - это ведь изменение конкретной записи-конкретной группы. При чем здесь то, что пользователь может создать внутри этой группы еще группы?

Здравствуйте, Дарья!

Как вариант в правах на операцию "Чтение любых данных" Вы можете понизить права роли "Системные администраторы", запретив таким образом просмотр всех данных. При этом пользователи с ролью "Системные администраторы" будут видеть записи согласно распределению прав в разделе "Доступ к объектам".

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

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

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

Скажите, пожалуйста, где можно посмотреть подобный пример реализации в конфигурации?

Нравится

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

Дарья, добрый день.

Выгрузите исходники согласно инструкции:

http://www.community.terrasoft.ru/blogs/8747

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

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

if (this.get("CanViewSysOperationAudit") != null) {
this.navigateToSysOperationAuditSection();
} else {
RightUtilities.checkCanExecuteOperation({
operation: "CanViewSysOperationAudit"
}, function(result) {
this.set("CanViewSysOperationAudit", result);
this.navigateToSysOperationAuditSection();
}, this);
}
}

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

Я бы хотела использовать операцию, чтобы в карточке делать недоступными для редактирования то или иное поле для тех групп пользователей.
Для того, чтобы делать активным поле в зависимости от каких-то условий надо использовать бизнес-правило.
Можно ли в качестве условия бизнес-правила использовать результат возвращения операции?

Предположила, что надо сделать виртуальный атрибут
"MyCanEditDateReact": {
dataValueType: Terrasoft.DataValueType.BOOLEAN,
value: null
},

создать метод для его заполнения
(т.е. аттрибут заполняется true,
если у пользователя есть право на операцию с кодом CanEditDateReact)
MethodCanEditDateReact: function() {

RightUtilities.checkCanExecuteOperation({
operation: "CanEditDateReact"
}, function(result) {
this.set("MyCanEditDateReact", result);

}, this);
}

вызвать метод этот в событии
onEntityInitialized: function() {
this.callParent(arguments);
this.MethodCanEditDateReact();
},

и уже в условиях бизнес-правила сравнивать заполняемый виртуальный аттрибут со значением true.
Но еще до прописывания самого бизнес-правила
наткнулась на ошибку в строке operation: "CanEditDateReact".

Возможно, что должна быть другая реализация? и в бизнес-правило надо по другому прописывать подобное условие?

Здравствуйте!

Коллеги, в пакете Nui есть замечательная схема RightsHelper. Там много примеров по использованию прав на операции.

Добрый день!
Спасибо, все получилось.
Использовала функцию checkCanExecuteOperation из схемы RightUtilites

Реализация такова была:

вызвала функцию в методе
MethodCanEditDateReact: function() {

RightUtilities.checkCanExecuteOperation({
operation: "CanEditDateReact"
}, function(result) {
this.set("MyCanEditDateReact", result);
}, this);
}

данный метод вызван в событии
onEntityInitialized: function() {
this.callParent(arguments);
this.MethodCanEditDateReact();
}

На поле наложено бизнес-правило
( если у пользователя есть право на операцию, то данное поля enabled для него)
rules {
"SatisfactionLevel": {
"EnableLevel1": {
//debugger
ruleType: BusinessRuleModule.enums.RuleType.BINDPARAMETER,
property: BusinessRuleModule.enums.Property.ENABLED,
conditions: [{
leftExpression: {
type: BusinessRuleModule.enums.ValueType.ATTRIBUTE,
attribute: "CanEditDateReact"
},
comparisonType: Terrasoft.ComparisonType.EQUAL,
rightExpression: {
type: BusinessRuleModule.enums.ValueType.CONSTANT,
value: true
}
}]
}

}

}

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

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

Нравится

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

Здравствуйте, Иван!

Принадлежность пользователя к определенной роли можно выяснить следующим образом:

1) Получить идентификатор пользователя и роли (это можно сделать, обращаясь к объектам Сотрудник и Объект Администрирования).
2) Проверять вхождение пользователя в роль, читая данные из объекта Роль Пользователя. В качестве условий передавать Пользователя и Роль. Если возвращает больше нуля, значит, пользователь входит в роль, иначе - нет.

Это понятно и вполне работает в EntitySchemaQuery, но в БП все сложнее...
Объект Роль Пользователя не доступен в фильтре элемента "Изменение прав доступа".
Добавить в фильтр результат выборки получается только один, а нужна все выборка..
Проблема остается.

Здравствуйте, Иван!

Определенная команда - это определенная роль? Если так, то почему нет возможности отфильтровать по ролям? Или необходимо давать права конкретным людям в определенной роли? Может я не правильно понял суть вопроса?

Команда - это роль(к примеру команда кассиры). Почему нет возможности фильтровать - этот вопрос меня тоже интересует)). В том то и дело, что нужно взять контакта, который входит в определенную роль и принадлежит к нужному филиалу, но в агрегирующем фильтре БП не доступны системные объекты, такие как VwSysAdminUnit. Вопрос в том как применить элемент Изменение прав доступа к нужной выборке сотрудников.

Здравствуйте, Иван!

Действительно, можно выбрать либо конкретную "Роль - группу пользователей в иерархии", либо контакта/ов по определенным условиям (без роли). Но я предлагаю пойти немного иным путем - на странице контакта есть поле "Роль", добавьте в справочник "Роль", необходимое значение, например "Кассир_1" и тогда можно будет по данному условию отфильтровать именно необходимого пользователя или группу.

Приятного дня!

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

Добрый день!
Террасофт 3.3.2.252
У некоторых пользователей в реестре продуктов не отображаются некоторые продукты. (в настройках доступа к группам таблицам права у этих пользователей на чтение продуктов имеются) и какие-то продукты в реестре отображаются. Соответственно те продукты, которые не отображаются в реестре продуктов отсутствуют и в деталях договоров (строки есть,даже суммы есть, а названий продуктов нет)
В чем может быть сбой? Как то возможно отредактировать права доступа на отдельные продукты?

Нравится

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

Олеся, Вам необходимо раздать права доступа на существующие продукты (те, которые не отображаются у пользователей). Права на существующие записи распределяются через деталь [Доступ].
Т.е. Вам необходимо:
1. Под пользователем с правами администратора авторизоваться в Terrasoft.
2. Перейти в раздел [Продукты]. Через деталь [Доступ] изменить уровень прав для пользователей на требуемые продукты.

Если таких записей много, обратите внимание на скрипты: 1 и 2

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

Добрый день!
Система BPMOnline 7.3
Стоит такая задача: Пользователь, который входит в группу менеджеры должен видеть в разделе контакты свои записи(в кот. он ответственный) и контакты из группы руководителей отдела продаж(т.е. контакты своих руководителей). Если с первым пунктом проблем нет, то со вторым есть...
Подскажите пожалуйста, есть ли возможность реализовать это без программной доработки или нет?

Нравится

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

Добрый день!

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

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

Для этого достаточно на каждый контакт из группы руководителей вручную дать права на чтение группе менеджеров. То есть открыть карточку контакта одного из руководителей, Действия-Права доступа и добавить группу менеджеров. Так нужно проделать с каждым контактом из группы руководителей.

В принципе может этим и обойдемся, спасибо!

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

Добрый день! Поднялся такой вопрос: есть группа менеджеров, у них стоит доступ к карточке "Контрагента" - только на чтение. Такая задача: нужно что бы появился доступ на поле "Ответственный", а на все остальные остались права "Только на чтение". Подскажите как это можно реализовать.

Нравится

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

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

Здравствуйте, Николай Николаевич!

Александр абсолютно верно говорит.

Необходимо раздать доступ группе менеджеров на нужные записи в разделе "Контрагенты", после чего в Настройке прав доступа к полям карточки Контрагента установить право "Только на чтение" для всех полей, кроме поля "Ответственный".

Раздать право на изменение группе менеджеров для всех записей в разделе "Контрагенты" можно следующим скриптом:

update tbl_AccountRight set CanWrite = 1 where AdminUnitID = (select ID from tbl_AdminUnit where Name = 'Группа менеджеров')

Если на детали "Доступ" Группа Менеджеров отсутствует вовсе, Вы можете ее добавить для всех записей следующим скриптом:

insert into tbl_AccountRight (RecordID, AdminUnitID, CanRead, CanWrite, CanDelete, CanChangeAccess)
select A.ID, AU.ID, 1, 1, 0, 0
from tbl_Account A
join tbl_AdminUnit AU on AU.ID = (select ID from tbl_AdminUnit where Name = 'Группа менеджеров') 
Показать все комментарии

Доброе утро.
Как можно открыть права доступа для пользователя, не являющимся администратором, на бизнес-процессы других пользователей в Terrasoft XRM 3.4?

Нравится

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

Добрый день, Анастасия.
Для реализации задачи нужно в приложении Terrasoft Administrator открыть сервис Workflow\General\Main Grid\tbl_Workflow и включить для него Администрирование по записям.

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

Не нашла ответа на форуме:

Клиенту важно, чтобы пользователи не имели возможность выгрузить клиентов из базы.
В клиенте ТС такие возможности позакрывали, а как быть с SQL Serverом? Пользователь может зайти под своим логином/паролем например в Management Studio и вытянуть из таблиц в файл данные. Как запретить?

Нравится

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

Здравствуйте, Анна.

Если запретить пользователям на уровне БД выполнять SELECT'ы к БД, то и Terrasoft не будет работать. Поэтому тут нужно администрировать на уровне Windows - т.е. запретить устанавливать новый софт (MS SQL Management Studio), если он уже имеется - запретить его запуск всем, кроме администратора (к примеру).

Тут вариант - прятать в бинарник логины/пароли и запускать ТС с них. Или как еще?

Можно сделать триггер на вход в систему, и проверять на то, какая программа пытается законнектиться, например, если это не sa и программа не TSClient.exe - то не давать войти в систему.

Вот пример из справки MS SQL

Можно использовать триггеры входа для проверки и управления сеансами сервера, например для отслеживания входов в систему, ограничения входов в SQL Server или ограничения числа сеансов для конкретного имени входа. Например, в следующем коде триггер входа запрещает попытки входа на SQL Server, инициированные под именем входа login_test, если уже созданы три пользовательских сеанса под этим именем входа.

USE master;
GO
CREATE LOGIN login_test WITH PASSWORD = '3KHJ6dhx(0xVYsdf' MUST_CHANGE,
    CHECK_EXPIRATION = ON;
GO
GRANT VIEW SERVER STATE TO login_test;
GO
CREATE TRIGGER connection_limit_trigger
ON ALL SERVER WITH EXECUTE AS 'login_test'
FOR LOGON
AS
BEGIN
IF ORIGINAL_LOGIN()= 'login_test' AND
    (SELECT COUNT(*) FROM sys.dm_exec_sessions
            WHERE is_user_process = 1 AND
                original_login_name = 'login_test') > 3
    ROLLBACK;
END;

Евгений, спасибо за публикацию варианта решения вопроса.
Анна, если возникнут дополнительные вопросы - обращайтесь.

нужна трехзвенка, все остальное обходится
или использовать терминальный сервер

А как обходится вариант с использованием триггера на logon?

А что делает триггер, смотрит название файла программы? Кстати, как? Так файл и переименовать можно.
Или обменивается с клиентом какими-то незадокументированными позывными?

"Миxалыч" написал:

нужна трехзвенка


?

"Анна Проненко" написал:
Миxалыч пишет:

нужна трехзвенка

?


Здравствуйте, Анна. Скорее всего имеется ввиду "Трёхуровневая архитектура":
Ссылка

Здравствуйте.

Следующий набор таблиц поможет решить проблему с точной идентификацией на триггере (for logon):

sys.dm_exec_sessions
sys.dm_exec_connections
sys.sysprocesses

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

Часто возникает потребность раздавать права доступа после назначения ответственного. Дело в том, что принцип раздачи прав на записи действует не всюду. В случае задач все будет происходить именно таким образом.
Но, к примеру, для контрагентов это не действует. Чтобы это действовало для необходимых разделов, следует в Terrasoft Administrator’e открыть скрипт обработки датасета, в нем найти функцию SelfOnDatasetAfterPost и дописать следующую строку:

GiveRightsToRecordOwner(Dataset);

Затем сохраните изменения.

/system/files/04.05.png

Нравится

Поделиться

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

О, Боже, а мы строили такие безумные схемы... :)
Спасибо!

А при импорте из Excel этого происходить не будет?

Нет, при импорте права раздаются по настройкам прав доступа по умолчанию.

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

Добрый день!

Как Вы знаете, в карточке редактирования может быть представлено несколько представлений. Иногда требуется ограничить доступ к этому представлению некоторой группе пользователей. Этот функционал можно дополнительно реализовать средствами Terrasoft Administrator. Ниже приведу сам алгоритм, на примере карточки редактирования раздела "Продукты", в которой существует представление "Движение по складу", доступ к которому мы ограничим.

Итак, прежде всего необходимо открыть скрипт wnd_OfferingEditScript и в конец скрипта добавить следующую функцию:

function IsUserInGroup(GroupID)
{
        var Dataset = Services.GetSingleItemByUSI('ds_AdminUnit');
        ApplyDatasetFilter(Dataset, 'UserContactID', Connector.CurrentUser.ContactID, true);
        Dataset.Open();
        var UserID = Dataset.ValAsGUID(IDFieldName);
        Dataset.Close();
        var Dataset = Services.GetSingleItemByUSI('ds_UserInGroup');
        ApplyDatasetFilter(Dataset, 'GroupID', GroupID, true);
        ApplyDatasetFilter(Dataset, 'UserID', UserID, true);
        Dataset.Open();
        var Is = (Dataset.RecordsCount > 0);
        Dataset.Close();
        return Is;
}

Приведенная выше функция, в случае если текущий пользователь системы входит в указанную нами группу пользователей, возвращает значение true, в ином случае - false.

Далее необходимо отредактировать функцию function wnd_OfferingEditOnPrepare(Window). В ней добавим следующую проверку:

function wnd_OfferingEditOnPrepare(Window) {
        scr_BaseDBEdit.wnd_BaseDBEditOnPrepare(Window);
        Initialize(Window);            
        if(!Connector.CurrentUser.IsAdmin)
        {
                var UsrDataset = Services.GetSingleItemByUSI('ds_UserInGroup');                  
                var GroupName = 'Название';
                //где 'Название' - имя группы пользователей, для которых нужно ограничить доступ к представлению         
                ApplyDatasetFilter(UsrDataset, 'GroupName', GroupName, true);
                //тут следует не забыть создать фильтр сравнения в сервисе sq_UserInGroup (см. скриншот ниже)
                UsrDataset.Open();             
                var GroupID = UsrDataset.Values('GroupID');
                if(IsUserInGroup(GroupID))
                {
                        //скрываем само представление, установив свойству IsVisible значение false
                        pgOfferingAnalytic.IsVisible = false;  
                }
                UsrDataset.Close();
        }
       
}

Так же, перед тестированием результатов, следует создать фильтр сравнения в сервисе sq_UserInGroup:

2
3

После этого не забудьте сохранить изменения и перезапустить клиентское приложение Terrasoft.

Нравится

Поделиться

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

Воспользовался вашим примером переработав функцию получения группы пользователя, у меня она выглядит так:

    var GroupDataset = Services.GetSingleItemByUSI('ds_UserInGroup');
    ApplyDatasetFilter(GroupDataset, 'UserID', UserID, true);
	     GroupDataset.Open();
	      GroupDataset.GotoNext();     //берем второе значение, так как первая по порядку группа 'Все пользователи'                 
         var GroupID = GroupDataset.ValAsStr('GroupID'); 
         GroupDataset.Close();

Большое спасибо за Ваш пример, очень пригодился!

В принципе есть базовая функция в scr_Access называется GetIsUserInGroup, делает примерно тоже самое только немного написана по другому

function GetIsUserInGroup(UserName, GroupID) {
	var sqGetIsUserInGroup = GetSingleItemByCode('sq_GetIsUserInGroup');
	SetParameterValue(sqGetIsUserInGroup.Parameters, 'GroupID', GroupID);
	SetParameterValue(sqGetIsUserInGroup.Parameters, 'UserName', UserName);
	var dsRes = sqGetIsUserInGroup.Open();
	try {
		return dsRes('IsExists') != 0;
	} finally {
		dsRes.Close();
	}
}
Показать все комментарии