В некоторых разделах пользователи постоянно пользуются деревом групп, то хотелось бы, чтобы bpm запоминал не только выбранную группу, но и открыто ли дерево групп.А то слишком много действий - каждый раз в разделе нажимать "Фильтр" - "Показать группы"
1 комментарий

Владими, здравствуйте!

Благодарим за идею. Передали в департамент разработки, как предложение по развитию системы.

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

Добрый день.

Версия 7.2

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

Спасибо.

Нравится

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

Все нужные Вам методы есть в схеме SectionModule, и они доступны через песочницу (sandbox), так что Вы можете в Ваших схемах секции обращаться к ним следующим образом, и анализировать массив включенных фильтров-папок:

define('ContactSection', ['Contact', 'ContactSectionStructure', 'sandbox', 'ContactSectionResources'],
	function(Contact, structure, sandbox, resources) {
	structure.userCode = function() {
 
		// only for debug\test
		document.scc = this;
 
		this.methods.init = function() {
			// only for debug\test
			document.scc = this;
		};
 
		this.methods.GetFolderFilterArray = function() {
			return sandbox.publish("GetFolderFilter", null, [sandbox.id + "_QuickFilterModule"]);
		};
	};
 
	return structure;
});

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

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

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

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

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

Нравится

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

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

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

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

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

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

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

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

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

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

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

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

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

Встречайте новый видеурок по работе с группами в bpm'online!

Узнайте, как сформировать в bpm'online дерево групп, распределить права доступа к группам и работать с ними. В видеоуроке демонстрируется, как создать структуру групп и настроить необходимые условия фильтрации, от простых к сложным.

Видео доступно по ссылке: Работа с группами в bpm'online

Больше видеоуроков смотрите на сайте академии Terrasoft.

Нравится

Поделиться

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

Здравствуйте, Владимир!

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

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

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

Добрый день.
BPMOnline 7.3
Интересует следующее:
1. Как расположить новое поле на карточке перед уже существующими, не переопределяя положение всех этих полей(row)?
2. Как менять порядок расположения групп и деталей на карточке? Создается впечатление что положение меняется хаотично, при перемещении строк с описанием групп в коде.
3. Так же проблема с добавлением на новую деталь, уже поднималась на форуме но пока без ответа..

Нравится

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

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

Задачи по перемещению элементов на странице необходимо решать при помощи мастера разделов.
Касательно добавления на деталь, единственным условием для отображения кнопки Добавить является наличие карточки редактирования зарегистрированной в SysModuleEdit. Были проблемы в ранних сборках, в последнем релизе (745) проблем быть не должно.

Спасибо, будем обновляться!

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

Доброго дня всем!
Подскажите плиз, как эффективнее всего сделать справочник, который будет содержать области групп и фильтрации при вызове из других карточек редактирования? Нужно ли делать его в виде workspace? Также необходимо динамически добавлять в область групп этого справочника группу с выбранным в гриде контрагентом.
Заранее спасибо!

Нравится

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

Здравствуйте, Иван Александрович.
Сделайте в виде отдельного окна Workspace. Подобная реализация есть в базовой версии: выбор проекта в карточках счета, договора; добавление файла на деталь [Файлы] из библиотеки.

Спасибо Наталия, все получилось!

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

Привет сообществу Террасофта.
Не так давно начал познавать новое для меня направление (автоматизация бизнес процессов). Что это такое знаю хорошо.
Перечитал скорее всего весь форум и все блоги на предмет реализации прав доступа, но всё же не до конца понял поэтому прошу гуру данного вопроса помочь.
Принцип реализации я понял исходя из этого -> https://community.terrasoft.ru/developer/advice/sequrity

Вот пример:
Имеем допустим 2 Филиала.

Задача: Пользователи этих филиалов не должны вообще знать про работу друг друга.

Имеем группу пользователей администраторы со всеми доступными правами, и ещё две группы филиалов со своими, и соответственно в каждой подгруппе филиала свои права для менеджеров по продажам и менеджеров по закупкам (это Важно!!).
Ещё нюанс: группе "Все пользователи" отключили все права (по логике это правильно исходя из того, что филиалы друг про друга не знают).

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

В результате: каждый пользователь видит только то, что дают права его группы + только его отдела (если он входит и в другой отдел, то и те записи доступны). При этом при добавлении новой записи пользователю вылетает окно (Данный элемент не входит в группу 'Название группы'. Добавить его в эту группу?) с кнопками да и нет. Если нажмёт да -> будет видеть этот элемент, иначе не будет.

Собственно сами вопросы:
1. В детале "Группы" к элементу нужно просто автоматом добавлять название группы и всё будет пучком. как это реализовать из террасофт?
2. Сделать доступными динамические подгруппы для каждого филиала в которых не показываются записи другого филиала.

Оба этих момента я думаю многим интересны. А мне очень нужны. Вся работа стоит.

Имеем Terrasoft 3.3.2.145 XRM Distribution

Нравится

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

"Заболоцкий Илья Анатольевич" написал:2. Сделать доступными динамические подгруппы для каждого филиала в которых не показываются записи другого филиала.

По 2-му вопросу было подобное обсуждение здесь -> http://www.community.terrasoft.ru/forum/topic/1537
Но можно ли это реализовать другими способами??? или ,если на то пошло, поподробнее кто-нибудь может объяснить как это сделать?

P.S. Ещё не знаком с программированием под Terrasoft, хотя веб-программист. Хотелось бы решить стандартными возможностями Terrasoft.

Добрый день!

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

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

Игорь, по 2-му вопросу.
Дело в том, что права на группу допустим документов стоят для определённой группы пользователей и администраторов (специально созданная группа).
И получается так, что из любой динамической подгруппы видно записи находящиеся в других группах раздела, которым права присвоены подобным образом для своих пользователей.

На сами записи присвоены права по умолчанию полные для администраторов и пользователя которым создана запись + чтение для текущей группы пользователей (именно для этой группы).

Каждый раздел выглядит так:

А по первому вопросу можете описать как это реализовать, если не сложно?

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

Илья, в Terrasoft наоборот. Чем "глубже" находится пользователь, тем больше у него прав.

Пример добавления записи в группу:

1. Открываем скрипт scr_Account
2. В конец функции SelfOnDatasetAfterPost добавляем код:

	var AccountGroupDataset = Services.GetSingleItemByUSI('ds_AccountInGroup');
	var AccountID = Dataset.Values('ID');
	var GroupID = '{6BC9D098-6C64-4142-8615-321E56714C2F}'; //ID нужной группы
	AccountGroupDataset.Open();
	AccountGroupDataset.Edit();
	AccountGroupDataset.Values('ID') = Connector.GenGUID();
	AccountGroupDataset.Values('AccountID') = AccountID;
	AccountGroupDataset.Values('GroupID') = GroupID;
	AccountGroupDataset.Post();

3. Сохраняем изменения

http://www.community.terrasoft.ru/system/files/06-07-2012_12-43-48.png

var GroupID - это значение формируется динамически или скажем так: берётся id выделенной группы при добавлении записи?

Сейчас попробовал добавить ваш код.

При добавлении контрагента:

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

"Гакало Игорь Александрович" написал:

GroupID в моем случае задан строго.

Илья, выгрузите, пожалуйста, Ваш скрипт, посмотрю, в чем проблема.

Добрый день.

Ваш пример был добавлен в Accounts->General->scr_account без каких либо изменений.

Конфигурация до этого не изменялась.
Скорее всего ругается на GroupID, у нас его скорее всего нет.
Где можно взять id уже существующей в базе группы? это нужно для тестирования.

"Заболоцкий Илья Анатольевич" написал:
Скорее всего ругается на GroupID, у нас его скорее всего нет.

Где можно взять id уже существующей в базе группы? это нужно для тестирования.

Выполните следующий запрос на базе:

select ID, Name from tbl_AccountGroup

Он возвратит ID групп и названия.

Спасибо большое за помощь. Мне очень помогло для понимания структуры самого продукта.
Я решил эти вопросы немного другим способом.

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

В результате: пользователи нужной группы видят только то, что им показали. Например: Заявки закупку видят только менеджеры по закупкам, а Клиентские заявки - только менеджеры по продажам.

Один нюанс: при входе от администратора динамические группы выдают информацию по всем записям например документы.

Есть: 2 филиала, у каждого свои коммерческие предложения. Добавляю динамическую группу ком.предложения (филиал1) и для второго тоже самое. Добавляем фильтр: ТИП - коммерческое предложение.
И в результате в этой подгруппе видны все коммерческие предложения для 2-х филиалов, а нужно только одного.Уточню: это только из под администратора, у остальноых пользователей всё как нужно.
Может быть знаете как это побороть?

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

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

В принципе модель Доступа в Террасофте сделана не плохо, при ваших требованиях к видимости и доступности объектов, Вам надо раздать грамотно Права по умолчанию по Группам Пользователей:
1. Допустим есть объекты, которые доступны всем пользователям на филиале - Контрагенты к примеру, соответственно группам Филиал1 и Филиал2, нужно в правах по-умолчанию таблицы Контрагенты - добавить группу Филиал1 и Филиал2, соответственно с правами ТОЛЬКО ЧТЕНИЕ, и аналогично поступить для общих объектов доступных на чтение/запись объектов всем пользователям филиалов.
2. Добавить индивидуальные группы для пользователей Менеджеры по Закупкам Ф1 и т.д., где уже более глубоко настроить Права по умолчанию, к примеру дать той же Группе пользователей уже ПОЛНЫЙ доступ по-умолчанию к объектам, которые создают пользователи в этой группе.
У меня модель доступа 3-уровневая для пользователей:
Все пользователи - мин. набор прав - контрагенты, библиотека, база знаний на чтение.
Менеджеры - общие права на доступ к Группам Таблиц
Индивидуальные группы для каждого направления, которое обслуживают менеджеры - в общем случае отдельная группа на пользователя, с индивидуальной настройкой прав по-умолчанию, где большая часть объектов доступна для пользователей Группы, это позволяет допустим оперативно добавлять пользователя для видимости объектов и возможности работы с ними(Контрагенты, Контакты, Задачи)(допустим пользователь в отпуске, больничный, уволился)
по поводу автоматической фильтрации объектов по филиалам(вряд ли это нужно самим пользователям филиалов - они и так при правильной настройке Прав по умолчанию видят только объекты своего филиала). Вам надо реализовать автоматическое добавление Группы в каждый раздел в зависимости от принадлежности Сотрудника(пользователя) к тому или иному подразделению, т.к. думаю вряд ли в текущей конфигурации можно добавить Динамическую группу с фильтром по Подразделению Ответственного... можно конечно посмотреть в эту сторону, чтоб доработать раздел фильтрации на более глубокую вложенность фильтра по Ответственному...

"Черных Руслан" написал:1. Допустим есть объекты, которые доступны всем пользователям на филиале - Контрагенты к примеру, соответственно группам Филиал1 и Филиал2, нужно в правах по-умолчанию таблицы Контрагенты - добавить группу Филиал1 и Филиал2, соответственно с правами ТОЛЬКО ЧТЕНИЕ, и аналогично поступить для общих объектов доступных на чтение/запись объектов всем пользователям филиалов.
2. Добавить индивидуальные группы для пользователей Менеджеры по Закупкам Ф1 и т.д., где уже более глубоко настроить Права по умолчанию, к примеру дать той же Группе пользователей уже ПОЛНЫЙ доступ по-умолчанию к объектам, которые создают пользователи в этой группе.

Так я и сделал.
Я и пытался найти решение для самих разделов.
Т.е. если я добавляю контрагента в группу "филиал 1" - Terrasoft ругается на то, что запись не добавлена в группу. добавить?
Нужно было сделать только автоматическое добавление группы к новой записи на детале "группы".
А как это реализовать - я не знаю. Может у Вас есть решение?

Добрый день!
Илья, Terrasoft не ругается, а выдает сообщение :) Если вопрос в том, как сообщение отключить с учетом утвердительного ответа, то это легко.

1. Зачем Вам разбивать объекты, которые вводят пользователи на Группы?
2. В моем случае, это разбиение нужно ТОЛЬКО для руководителей, они по кол-венным показателям контрагентов и контактов по филиалам делают определенные выводы. Я вышел из ситуации без доработки кода, в карточках Контагентов и Контактов есть поле "Территория" - Нам это поле в принципе не нужно. Я в справочник Территорий добавил нужные мне Объекты - Филиалы и сделал в свойствах датасета ds_Contact и ds_Account это поле обязательным для заполнения(еще до начала работы в Террасофт), и пользователи заполняя поле Территория в "ручном" режиме указывают Филиал.
Вариант автоматической привязки Статической группы, которые вы добавите в Панель Групп и будете автоматом привязывать дано выше пользователем "Гакало Игорь Александрович", можно добавить анализ в скрипт , к какой группе Пользователей пренадлежит Автор записи и добавлять в эту Группу Организаций(Контрагентов) карточку автоматически.

1. Это нужно для того, чтобы объекты были не видны друг другу.
Допустим даже есть одна организация и имеет несколько отделов : it, отдел розничной продажи светильников, отдел оптовой продажи кирпича, столовая (в которой едят все) и т.д.
Все эти отделы работают по своему. Неужели нельзя разделить видимость между ними созданных записей?

И должна быть эта возможность:

"Черных Руслан" написал:это разбиение нужно ТОЛЬКО для руководителей, они по кол-венным показателям контрагентов и контактов по филиалам делают определенные выводы

а вот это и нужно сделать:

"Черных Руслан" написал:можно добавить анализ в скрипт , к какой группе Пользователей пренадлежит Автор записи и добавлять в эту Группу Организаций(Контрагентов) карточку автоматически

только как? никак не разберусь

"Гакало Игорь Александрович" написал:

Добрый день!

Илья, Terrasoft не ругается, а выдает сообщение :) Если вопрос в том, как сообщение отключить с учетом утвердительного ответа, то это легко.

А как? это было бы решение всех проблем. Как правило пользователи нажмут и нажимают "нет".
Такие вопросы решаются легко, если есть опыт))) Для меня это сложно на данный момент, но очень нужно.

"Заболоцкий Илья Анатольевич" написал:1. Это нужно для того, чтобы объекты были не видны друг другу.

Для того, чтоб Объекты(Контакты, Контрагенты и т.д.), были НЕ ВИДНЫ пользователям разных групп, нужно настроить Доступ по-умолчанию.
Постараюсь объяснить модель доступа в Террасофте:
1. Доступ можно настраивать для двух субъектов - Пользователя и Группы пользователей.
2. Доступ регламентируется на Объекты - Группы таблиц, это как правило разделы, где настраиваются права на Чтение/Создание/Редактирование/Удаление объекта.
3. По- умолчанию, к объектам, которые создал Пользователь ДОСТУП(даже на чтение) имеет ТОЛЬКО Пользователь-владелец(автор) и Администратор системы. Для того чтоб раздать доступ по-умолчанию другим пользователям или группам пользователей есть специальный раздел Права доступа по-умолчанию, где задается соответствие между Пользователем(Группой пользователей)- автором - это панель слева в окне Администрирование; Объектом(Группой таблиц) -основной раздел и Остальными пользователями - это Деталь Досуп по умолчанию раздела Администрирования, куда добавляются Пользователи и Группы, которые будут иметь доступ к Объектам, которые создал Пользователь(Группа пользователей)-Автор(ы).
Соответственно видимость объектов элементарно настраивается с помощью Доступа по-умолчанию. Если при создании Объекта в любом Разделе Террасофта в детали- Доступ у Вас группа Все пользователи имеет Доступ на чтение или другие уровни доступа к Объекту, то значит так у Вас настроено в разделе Доступ по-умолчанию. Установите курсор на Группу все пользователи и пройдитесь по всем Объектам системы, и удалите из детали Доступ по умолчанию группу Все пользователи, там где это не нужно.

Всё это я сделал. С разделом администрирование подружился. Возможно я неправильно понял Ваш ответ.
Все записи видны только нужным пользователям, но: нужно решить только один вопрос, видеть всю картину с "филиалами" должны только администраторы и руководители, для этого и был вопрос:

"Заболоцкий Илья Анатольевич" написал:1. В детале "Группы" к элементу нужно просто автоматом добавлять название группы и всё будет пучком. как это реализовать из террасофт?

Игорь сказал что это не сложно:

"Гакало Игорь Александрович" написал:Илья, Terrasoft не ругается, а выдает сообщение :) Если вопрос в том, как сообщение отключить с учетом утвердительного ответа, то это легко.

а как?

Цель:
1. просмотр от администратора информации отдельно взятого "филиала".
2. удобство работы для пользователей
3. масштабируемость (за счёт добавления филиалов и покупки новых лицензий)

"Заболоцкий Илья Анатольевич" написал:

а как?


Решил таким образом для контрагентов:

В скрипте scr_AccountsWorkspace изменил следующую функцию:

function dlAccountsOnDatasetRefreshRecord(Dataset, KeyValue, 
		AddNewRecordOnPage) {
	if (AddNewRecordOnPage) {
//////////////////////////////////////////////////////////////////////////
		AddItemInGroup(BaseWorkspace.GroupsDataset, 'ds_AccountInGroup', 
			KeyValue, 'AccountID', true); 
////////////////////////////////////////////////////////////////////////
	}
	RefreshDetails();
}

Если необходимо это сделать для всех разделов, то можно изменить функцию AddItemInGroup скрипта scr_DB, закомментировав строки

	if (!SilentAdd) { 
	        if (System.MessageDialog(FormatStr(AddItemInGroupAsk, GroupName), mdtWarning, 
			mdbYes + mdbNo, 0) != wmrYes) {
		        return;
	        }
	}

"Гакало Игорь Александрович" написал: if (!SilentAdd) {
if (System.MessageDialog(FormatStr(AddItemInGroupAsk, GroupName), mdtWarning,
mdbYes + mdbNo, 0) != wmrYes) {
return;
}
}

Для всех разделов только это закомментировать нужно? Не могу найти такую часть в скрипте.

Для версии 3.3.2 эти строки имеют следующий вид (в этой же функции AddItemInGroup)

	if (System.MessageDialog(FormatStr(AddItemInGroupAsk, GroupName), mdtWarning, 
			mdbYes + mdbNo, 0) != wmrYes) {
		return;
	}

Закоментировал эти строки:

"Гакало Игорь Александрович" написал:

Для версии 3.3.2 эти строки имеют следующий вид (в этой же функции AddItemInGroup)

        if (System.MessageDialog(FormatStr(AddItemInGroupAsk, GroupName), mdtWarning,

                        mdbYes + mdbNo, 0) != wmrYes) {

                return;

        }

И всё заработало так, как мне было нужно. Спасибо большое
Вопрос закрыт

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

На этапе внедрения раздела "библиотека" столкнулся с такой проблемой. Пользователи внося новые записи и распределяя их по группам постоянно удаляют их физически из раздела.
Т.е человек создал в группе1 запись1, отнес запись1 еще к группе2 и группе3. Потом, через некоторое время, решил, что в группе3 ему запись1 не нужна и нажал кнопку удалить в реестре записей группы, тем самым удалив физически запись1 из всех групп и бд. Хотелось бы этого избежать, понял, что нравоучениями этот вопрос не решить и нужно идти на встречу пользователю и делать как ему удобно.
Написав в тех поддержку я предложил на кнопку удалить, которая в реестре записей, назначить действие удалить из группы и добавить в контекстное меню кнопки удалить еще 2 действия "удалить из группы", "удалить запись" , но мне ответили, что это не рационально. Может кто сталкивался с такой проблемой и может подсказать как реализовать?

Нравится

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

"Кудрявцев Андрей" написал:Хотелось бы этого избежать, понял, что нравоучениями этот вопрос не решить и нужно идти на встречу пользователю и делать как ему удобно

IMHO административно (терпеливым обучением пользователей либо радикально удаленная запись = -$5) решить лучше, так как аналогичный механизм во всех разделах Terrasoft:wink:
Либо модифицировать всю систему насквозь. Как вариант реализовать при удалении записи проверку входит ли она в более чем одну группу, отличную от корневой - и окошко предупреждения - "А вот уверены ли вы?". Но это путь, повторюсь, тяжелее.

 

"Александр Кудряшов" написал:MHO административно (терпеливым обучением пользователей либо радикально удаленная запись = -$5) решить лучше, так как аналогичный механизм во всех разделах Terrasoft:wink:
Либо модифицировать всю систему насквозь. Как вариант реализовать при удалении записи проверку входит ли она в более чем одну группу, отличную от корневой - и окошко предупреждения - "А вот уверены ли вы?". Но это путь, повторюсь, тяжелее.

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

Андрей, спасибо за замечание. Ваш запрос передан в отдел разработки как пожелание для реализации в следующих версиях.

Мы обязательно сообщим Вам, как только данная возможность будет реализована.

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

1. Створити сервіси для груп по аналогії дерева груп розділу.
2. Створити сервіс dq_DetailInGroup для таблиці tbl_DetailInGroup, з двома параметрами (GroupID, DetailID), порівняльними фільтрами по цим параметрам й відповідним полям таблиці.
3. У вікні реєстру вибраної деталі створити контейнер для стандартного вікна груп і відповідно налаштувати, як у груп розділу.
4. Додати у вікні реєстру для групи кнопок "Видалити" і в контекстному меню опції для видалення запису з групи (Напр.:amiDeleteFromCurrentGroup, amiDeleteFromGroup)
5. Для вікна реєстру створити скрипт обробки. Приклад вказаний нижче (Замість слова "Detail" можна вставити свою код. назву деталі).

//-----------------------------------------------------------------------------
// wnd_DetailGridAreaScript
//-----------------------------------------------------------------------------

var Script = {};

function InitializeWindowGroups(Window) {
 InitializeGroups('tbl_DetailGroup', 'ds_DetailInGroup', 'DetailID');
 OpenGroupsDataset();
}

function InitializeGroups(GroupTableUSI, ItemInGroupDatasetUSI, ParentItemFieldName, GroupDatasetUSI , ParentIDFieldName) {
 var GroupsWindow = wndGroups.Window;
 GroupsWindow.ComponentsByName('amiAddDynamicGroup').IsVisible = false;
 Script.GroupsWindow = GroupsWindow;
 if (IsEmptyValue(GroupDatasetUSI)) {
  GroupDatasetUSI = 'ds_ItemGroup';
 }
 if (IsEmptyValue(ParentIDFieldName)) {
  ParentIDFieldName = 'ParentGroupID';
 }
 SetAttribute(GroupsWindow, 'DatasetUSI', GroupDatasetUSI);
 Script.GroupParentIDFieldName = ParentIDFieldName;
 SetAttribute(GroupsWindow, 'TableUSI', GroupTableUSI);
 SetAttribute(GroupsWindow, 'IDFieldName', 'ID');
 SetAttribute(GroupsWindow, 'ParentIDFieldName', ParentIDFieldName);
 SetAttribute(GroupsWindow, 'NameFieldName', 'Name');
 SetAttribute(GroupsWindow, 'ItemInGroupDatasetUSI', ItemInGroupDatasetUSI);
 SetAttribute(GroupsWindow, 'ParentItemFieldName', ParentItemFieldName);
 SetAttribute(GroupsWindow, 'WorkspaceWindow', Self);
 GroupsWindow.Prepare();
 var Dataset = GetDatasetFromWindow(GroupsWindow, DefDatasetLinkName);
 Script.GroupsDataset = Dataset;
 Script.GroupsTreeGrid = GroupsWindow.ComponentsByName('grdData');
 dlGroups.Dataset = Dataset;
}

function OpenGroupsDataset() {
 var Dataset = dlGroups.Dataset;
 OpenDatasetWithDisabledEvents(Dataset);
 Script.GroupsWereInitialized = true;
 LocateToRootGroup(Dataset, Script.GroupParentIDFieldName);
 ExpandCurrentNode(Script.GroupsTreeGrid);
}

function RefreshGrid() {
 dlData.Dataset.Close();
  dlData.Dataset.Open();
}

function DeleteFromCurrentGroup() {
 var GridDataset = dlData.Dataset;
 var GroupsDataset = dlGroups.Dataset;
 if ((GridDataset.State == dstInactive) || GridDataset.IsEmptyPage ||
  (GroupsDataset.State == dstInactive) || GroupsDataset.IsEmptyPage) {
  return;
 }
 var DetailID = GridDataset('ID');
 var GroupID = GroupsDataset('ID');
 if (ShowConfirmationDialog("Видалити запис з групи?") != mrYes) {
  return;
 }
 var DeleteQuery = GetSingleItemByCode('dq_DetailInGroup', 'DeleteFromCurrentGroup');
 var Parameters = DeleteQuery.Parameters;
 Parameters('DetailID').Value = DetailID;
 Parameters('GroupID').Value = GroupID;
 DeleteQuery.Execute();
 RefreshGrid();
}

//-----------------------------------------------------------------------------
// Event handler
//-----------------------------------------------------------------------------

function wnd_DetailGridAreaOnPrepare(Window) {
 wnd_BaseGridAreaOnPrepare(Window);
 InitializeWindowGroups(Window);
}

function dlGroupsOnDatasetAfterPositionChange(Dataset) {
 if (Script.GroupsWereInitialized){
  RefreshGrid();
 }
}

function dlGroupsOnDatasetRefreshRecord(Dataset, KeyValue, AddNewRecordOnPage) {
  RefreshGrid();
}

function dlGroupsOnDatasetAfterPositionChange(Dataset) {
 RefreshGrid();
}

function dlDataOnDatasetBeforeOpen(Dataset, DoOpen) {
 EnableDatasetFilters(dlData.Dataset, false, 'GroupID');
 ApplyDatasetGroupIDFilter(Script.GroupsDataset, dlData.Dataset);
}

function wnd_DetailGridAreaOnNotify(ScriptableService, Sender, Message, Data) {
  wnd_BaseGridAreaOnNotify(ScriptableService, Sender, Message, Data);
}

function amiDeleteFromGroupOnExecute(ActionMenuItem, Sender) {
 DeleteFromCurrentGroup();
}

function amiDeleteFromCurrentGroupOnExecute(ActionMenuItem, Sender) {
 DeleteFromCurrentGroup();
}

function dlDataOnDatasetRefreshRecord(Dataset, KeyValue, AddNewRecordOnPage) {
 if (AddNewRecordOnPage) {
  AddItemInGroup(dlGroups.Dataset, 'ds_DetailInGroup', KeyValue, 'DetailID');
 }
 RefreshGrid();
}

Благодарність Артёму Репко за допомогу у вирішенні даного питання.

Нравится

Поделиться

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