https://academy.terrasoft.ru/search/%D0%97%D0%B0%D0%B1%D0%BB%D0%BE%D0%B…

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

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

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

А может все же существует вариант с переопределением какого-либо метода родительской схемы? Если мы будем использовать механизм прав, то, как я понимаю, чтобы перенести потом нужные настройки с тестового сервера на рабочий с помощью WorkspaceConsole, необходимо во-первых, будет дополнительно переносить пакет Custom, поскольку мы ведем разработку в другом пакете, а при включении администрируемости автоматически создается замещающий объект в пакете Custom, а во-вторых, необходимо будет через вкладку Данные раздела Конфигурация сохранить наполнение объекта SysQualifyStatusRight, верно?. Опять же, сохранять данные также в пакете Custom, а не в нашем основном пакет разработки?

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

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

Андрей, здравствуйте!

Посмотрите на два места:
1. getLookupFilterValue: function(filter) - в клиентском модуле провайдера фильтрации схем объектов (EntitySchemaFilterProviderModule). Метод получает значение для справочной колонки.
2. pushSelectFilters: function(select) - в клиентском модуле представления страницы выбора значения из справочника (LookupPageViewModelGenerator). Добавляет фильтры в select.

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

Пример для случая:
При выборе контактов по полю Ответственный в окне выбора выводить толькло контакты, которые являтся пользователями системы.
Реализовать для двух разделов: Контрагенты и Контакты

Шаги:
1. Создать Замещающий клиентский модуль для EntitySchemaFilterProviderModule (провайдер фильтрации схем объектов).
Переопределить метод getLookupFilterValue и в объект config добавить дополнительное свойство addContactUserFilter, по которому дальше в методе pushSelectFilters клиентского модуля LookupPageViewModelGenerator будет выполняться наложение фильтрации по контактам, которые являются пользователями системы (есть в таблице SysAdminUnit, связка по полю ContactId).

2. Создать замещающий клиентский модуль LookupPageViewModelGenerator и переопределить метод pushSelectFilters, в котором по переданному конфигу (lookupInfo) мы определяем, что нужно наложить фильтр по контактам-пользвоателям системы. Для использования стандартного фильтра OwnerFilter подключить модуль BaseFiltersGenerateModule.

Анастасия, если правильно Вас поняла, то речь идет о переносе доработок через SVN, а не полная подмена БД? Если да, то права и так не должны перезатиреться. Ну а в принципе, как на счет того, чтоб не переносить таблицы с правами? Или сделать бекап таблицы в базе данных и в случае чего просто через update вернуть как было.

"Байбородин Николай" написал:Существующая логика, когда привязка зависит от типа контакта

А как она зависит от типа контакта?

Цитата из переписки с саппортом: "Привязка контакта к Email сообщению происходит следующим образом: фильтруются все записи у кого на детали «Средства связи» в поле «Email» указан адрес из поля «От кого», затем происходит фильтрация по полю «Тип» не равно «Сотрудник», после этого происходит привязка первой записи из результирующего списка."
Я, честно говоря, не понял, зачем это делалось, теперь ищу, где исправить и сделать как надо.

В документации в разделе "КАК ЗАПОЛНЯЮТСЯ ПОЛЯ EMAIL-СООБЩЕНИЙ, ЗАГРУЖЕННЫХ В
BPM’ONLINE" читаю:

При загрузке почты в bpm’online автоматически производится первичная обработка
полученных email-сообщений:
1. Значение поля [От кого] сопоставляется со средствами связи зарегистрированных в
bpm’online контрагентов и контактов. Если в системе будут найдены совпадения, то на
странице такого email-сообщения будут автоматически заполнены поля [Контрагент],
[Контакт].
2. Если по значению поля [От кого] в системе не найдено совпадений, анализируются
значения полей [Кому], [Копия], [Скрытая копия]. Если по этим полям в системе
будут найдены совпадения, то на странице такого email-сообщения также будут
заполнены поля [Контрагент], [Контакт].

К «Сотрудникам» письма тоже привязываются, только на странице контакта не отображается деталь, если тип контакта = «Сотрудник»

Чтобы отображать, надо заместить один метод на ContactPageV2

	methods: {
			setIsEmailDetailVisible: function() {
				this.set("IsEmailDetailVisible", true);
			}
		},

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

			initLeadManagementButtonVisibility: function(entity) {
/*				entity = entity || this.getEntity();
				if (Ext.isEmpty(entity)) {
					return;
				}
 				var isNewMode = ((this.isNewMode && this.isNewMode()) === true);
				var visible = false;
				if (isNewMode === false) {
					var primaryColumnValue = entity.get(entity.primaryColumnName);
					var qualifyStatusId = this.getQualifyStatus(primaryColumnValue);
					var qualifyStatus = LeadConfigurationConst.LeadConst.QualifyStatus;
					visible = (qualifyStatusId === qualifyStatus.Qualification ||
						qualifyStatusId === qualifyStatus.Distribution ||
						qualifyStatusId === qualifyStatus.TransferForSale);
				}
				this.set("LeadManagementButtonVisible", visible); */
				this.set("LeadManagementButtonVisible", false);
			},

Причем сделать это и в LeadPageV2, и в LeadSectionV2. Также не забыть деактивировать процесс Управление лидом в библиотеке процессов.

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

Насколько я понял, речь идет все же не о конфигурации, а о пакете. Конечно, необходимо создать свой пакет, в котором указать зависимость от крайнего базового пакета и в нем уже создавать замещабщие схемы LeadSectionV2 и LeadPageV2.

Сталкивались, но в другом сервисе, конфигурационном PurchaseService.
Тогда оказалось, что:

Похоже, дело в формате даты. Вы передаёте:
<ns1:Date>2013-08-20T00:00:00+04:00</ns1:Date>
А надо:
<ns1:Date>2013-08-20T00:00:00</ns1:Date>
Если написать в этом формате, веб-сервис отрабатывает без ошибки.

"Зверев Александр" написал:

Сталкивались, но в другом сервисе, конфигурационном PurchaseService.

Тогда оказалось, что:

Похоже, дело в формате даты. Вы передаёте:

<ns1:Date>2013-08-20T00:00:00+04:00</ns1:Date>

А надо:

<ns1:Date>2013-08-20T00:00:00</ns1:Date>

Если написать в этом формате, веб-сервис отрабатывает без ошибки.

А если так, как в моём примере, первом и втором?

Здравствуйте, Анастасия!

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

Также проверьте есть ли в Вашем процессе элемент "Привязать объект к процессу" для привязывания записи лида к экземпляру процесса.

"Демьяник Алексей" написал:

Здравствуйте, Анастасия!

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

Также проверьте есть ли в Вашем процессе элемент "Привязать объект к процессу" для привязывания записи лида к экземпляру процесса.

Спасибо, Алексей. С автогенерируемыми страницами вопрос решился! Но осталась проблема:
при создании активностей через бизнес-процессы активности появляются в дашборде только после сброса кеша

Из уже существующих для этой цели больше всего подходит раздел "Обращения". Но, если нужно было был для себя, то сделала бы отдельный раздел "Заявки" специально для отдельной группы пользователей.

Здравствуйте,
Что вы подразумеваете под сделать «левый грид», желательно со скриншотами, а также зачем Вам это нужно (бизнес задача), т.к. в силу того, что Вы новичок, возможно есть более простые способы реализации того что Вам необходимо либо обходные пути.

"Мотков Илья" написал:

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

Что вы подразумеваете под сделать «левый грид», желательно со скриншотами, а также зачем Вам это нужно (бизнес задача), т.к. в силу того, что Вы новичок, возможно есть более простые способы реализации того что Вам необходимо либо обходные пути.

Здравствуйте,
Изначально бизнес задача звучала как Воссоздание представления раздела планирование ( по аналогии с разделом Активности, вкладка планирование ) в другом разделе.

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

P.S: раньше задавал этот вопрос, ответ был один: смотреть в сторону реализации этого представление из пакета FieldForce, но из-за того, что реализация данного представления очень жёстко завязана на объекте активности и модулях раздела активности, не удалось даже воссоздать грид.

Удалось только создать представление:

Был бы весьма признателен за информацию по данному вопросу.

Спасибо.

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