Коллеги, добрый день. 

 

Не могу найти информацию о том, как настроить права доступа на вкладки "Обращение". 

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

Нравится

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

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

 

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

 

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

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

Добрый день.

 

Реализовал процесс, во время которого происходит добавление данных в справочник. 

Но выходит ошибка "Текущий пользователь не имеет прав на запуск администрируемой операции с кодом "CanManageLookups".

Как можно решить данную проблему?

Или необходимо полностью доступ к справочникам давать.

 

Нравится

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

Вариант 1. 

1. Зайдите в   Управление конфигурации - Права доступа на операции - 
2. Найдите операцию с кодом "CanManageLookups"
3. Добавьте нужному пользователю или роли права на эту операцию.
Вариант 2. 
Для объекта справочника измените Родительский объект на "Базовый объект", а не "Базовый справочник" и опубликуйте (при этом слетят базовые поля Name и Description)
 

Вариант 1. 

1. Зайдите в   Управление конфигурации - Права доступа на операции - 
2. Найдите операцию с кодом "CanManageLookups"
3. Добавьте нужному пользователю или роли права на эту операцию.
Вариант 2. 
Для объекта справочника измените Родительский объект на "Базовый объект", а не "Базовый справочник" и опубликуйте (при этом слетят базовые поля Name и Description)
 

Коновалов Игорь,

 

Спасибо за ответ.

Второй вариант помог. Пришлось конечно везде, где чтение данных было, заново условия и объект чтения поменять, т.к. выдавало ошибку что "Элемент коллекции с именем Name не найден".

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

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

Нравится

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

Добрый день!
Да, заходите в системную настройку, указываете пункт "Разрешить по операции". Системную операцию используете существующую, либо создаете новую.

Добрый день!
Да, заходите в системную настройку, указываете пункт "Разрешить по операции". Системную операцию используете существующую, либо создаете новую.

Сидоров Александр В.,

в 7.12 такого нет, наверно это в более новой версии

Ещё один повод обновиться сразу до актуальной.

Зверев Александр,

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

Можно попробовать развернуть демку новой версии и точечно портировать логику прав на системные настройки (если она не вынесена частично в ядро). Но когда дойдёт очередь до планового обновления, может выйти боком.

Вот потому и думаю, и так обновления проходят не без проблем, а так ещё добавятся

В таком случае стоит обновляться. В версии 7.13 права уже есть.

У нас сейчас 7.12.4, будет стимул проставить на прод. Спасибо

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

Коллеги, добрый день. 

 

Имеется ли в системе какой-то инструмент, который позволит узнать имя объектов. 

Задача - отобрать права у пользователей, убрать строку из меню "дизайнер системы". 

В интерфейсе не нашёл информацию по данному меню. 

В реестре прав доступа не могу понять как называется объект. 

Нравится

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

Посмотреть названия элементов интерфейса можно через инспектор объектов в браузере.

Это меню реализовано в модуле LeftPanelTopMenuModule.

Вам нужно внести изменения в метод setSystemDesignerVisible, который реализован в этом модуле и отвечает за видимость данного пункта меню.

Посмотреть названия элементов интерфейса можно через инспектор объектов в браузере.

Это меню реализовано в модуле LeftPanelTopMenuModule.

Вам нужно внести изменения в метод setSystemDesignerVisible, который реализован в этом модуле и отвечает за видимость данного пункта меню.

Алла Савельева, я правильно понимаю, что под модулем Вы понимаете "пакет" ? 

Sunrise challenge,

Не, пакет - это пакет, а модуль - это модуль. Модуль - это ClientUnitSchemaManager, скриншот ниже:

Алла Савельева, волей-неволей вспоминается - "стою на асфальте, в лыжи обутый...". Не нахожу его 

Sunrise challenge,

Проверьте, не включена ли фильтрация в нижней панели окна сервисов (на скриншоте выделила красным):

Алла Савельева,

Вы оказались правы. Как-то не очевидно, что он установлен. 

Метод я нашёл, но сохранить изменения он не даёт: 

"Невозможно сохранить изменения элемента "LeftPanelTopMenuModule", так как он создан сторонним издателем или установлен из файлового архива"

Sunrise challenge,

Вам нужно заместить модуль LeftPanelTopMenuModule.

Посмотрите вот этот пост - там описан общий подход к внесению изменений в модуль.

Алла Савельева,

Спасибо за подсказки. В дополнение - есть ли более простой способ скрыть данное всплывающее меню или убрать из списка "Дизайнер системы"  ? 

Sunrise challenge,

Я не нашла никакой системной настройки, с помощью которой можно было бы управлять этой функциональностью.

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

Зверев Александр,

Это не совсем правильно, ибо не нужно агентам и пользователям знать о лишнем функционале, во избежание путаницы. И поиска не регламентированных возможностей. 

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

Зверев Александр пишет:
Вообще, если бы такое настраивалось, то не в системных настройках, а в правах доступа на операции.

Это была описка - речь шла о правах доступа на операции.

Зверев Александр пишет:
Да, было бы логично иметь там право на просмотр дизайнера системы. Если и дорабатывать, то в таком ключе. Добавить новое право и при отображении пунктов меню и главной страницы проверять его наличие у текущего пользователя и если нет, то этот пункт не отображать.

Саша, а ты можешь это внести в список пожеланий от клиента? Я на 100% согласна, что такая настройка должна быть в базовой версии. 

Алла, такое пожелание уже заведено раньше.

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

Добрый день, подскажите пожалуйста, как дать (пользователю, роли и т.д.) доступ к разделу со справочниками?

Нравится

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

доступ по операциям —> поиск по коду "CanManageLookup" —> добавляете пользователей

Ок, спасибо. Получилось

Варфоломеев Данила,

Cкажите, а откуда вы это знаете? Поделитесь, пожалуйста, источником в целях обучения.

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

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

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 комментария

Добрый день!

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

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

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

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

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