Гусейн, судя по одинаковой иконке, Вы добавили логику для справочника стадий по аналогии с выбором ответственного тут же левее. Так там уже есть множественный выбор, только добавлять ответственных нужно по одному:

Если для стадий реализовали аналогично, там тоже должно такое работать.

Идея в быстром фильтре добавить возможность множественного выбора значений уже зарегистрирована.

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

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

Атамогланов Гусейн пишет:

все работает криво(не подстраивается под нужный справочник)

Нужно смотреть, как именно доработали в OpportunitySectionV2, что в результате не так отрабатывает для функций из FixedFilterViewV2 и FixedFilterViewModelV2.

Павел, а в чём проблема, если в обоих случаях будет запускаться одна и та же функция с доработками?

И initCardPrintForms, и initSectionPrintForms применяются в BaseDataView, базовой странице раздела:

/**
 * Initializes print buttons menu.
 * @protected
 * @param {Function} callback Callback function.
 * @param {Object} scope Callback function scope.
 */
initPrintButtonsMenu: function(callback, scope) {
	this.initSectionPrintForms(this.initCardPrintForms, this);
	this.initModulePrintForms(callback, scope);
},

Там есть две кнопки печатных форм: одна — для раздельного режима, другая — для комбинированного:

{
	"operation": "insert",
	"name": "SeparateModeReportsButton",
	"parentName": "SeparateModeActionButtonsRightContainer",
	"propertyName": "items",
	"values": {
		"itemType": Terrasoft.ViewItemType.BUTTON,
		"caption": {"bindTo": "Resources.Strings.PrintButtonCaption"},
		"classes": {"wrapperClass": ["actions-button-margin-right"]},
		"controlConfig": {
			"menu": {"items": {"bindTo": "SectionPrintMenuItems"}},
			"visible": {"bindTo": "IsSectionPrintButtonVisible"}
		}
	}
},
...
{
	"operation": "insert",
	"name": "CombinedModePrintButton",
	"parentName": "CombinedModeActionButtonsCardRightContainer",
	"propertyName": "items",
	"values": {
		"itemType": Terrasoft.ViewItemType.BUTTON,
		"caption": {"bindTo": "Resources.Strings.PrintButtonCaption"},
		"classes": {"wrapperClass": ["actions-button-margin-right"]},
		"controlConfig": {"menu": {"items": {"bindTo": "CardPrintMenuItems"}}},
		"visible": {"bindTo": "IsCardPrintButtonVisible"}
	}
},

Ответ оказался прост

Добрый день.

Вы можете реализовать проверку на заполненность таблицы "Разрешенные типы контактов" простым селектом к этой таблице.

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

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

Виталий, а Вы случайно не стандартный механизм деактивации записи в справочнике изобрести пытаетесь?

Если одно или несколько значений справочника устарели и больше не используются, то такие значения можно деактивировать. Деактивированное значение не будет отображаться при выборе значений в справочных полях. При этом пользователи продолжат видеть это значение в тех записях, где оно было указано ранее, и смогут использовать его для фильтрации. По умолчанию возможность деактивировать значения справочника выключена. Разрешить деактивацию записей для нужного справочника можно в разделе [Конфигурация]. Подробнее о настройке читайте в статье “Деактивация записей объектов”.

 

Деактивированное значение справочника [Типы статей базы знаний]

Коллеги, спасибо за ответы.

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

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

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

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

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

Виталий Жилин пишет:

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

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

Уверенна, дорогу осилит идущий...

О, в этой теме ещё через view не предлагали.

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

Кстати, да, как вариант 

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

Подсказку для начала решения нашел вот здесь - это помогло вспомнить, что для subfilter путь к колонке указывается относительно подсхемы вышестоящего фильтра, а не root-схемы всего запроса, то что нужно.

Однако, получается, что всё равно невозможно составить запрос именно в том виде, что я описал изначально, т.к. вышестоящий фильтр всё же должен быть как-то связан с root-схемой. Поэтому здесь мне пришлось немножко одурачить esq и подсунуть связь там, где её на самом деле нет. Это можно сделать с помощью двух вложенных  фильтров - notexists внутри exists, причем внешний exists должен иметь связь с root схемой и быть true всегда. Например, exists (наш статус в справочнике статусов)

Таким образом, изначальный запрос 

select * from Contact where Contact.StateId = @someState
or not exists (select Id from AllowedStates) /* вот эту часть в чистом виде записать на esq нельзя, нет связи с Contact*/

превращается в

select * from Contact where Contact.StateId = @someState 
or exists (select Id from State where State.Id = Contact.StateId /*вот она нужная связь*/ and not exists (select StateId from AllowedStates)) /* true только тогда, когда true нужный нам notexists.*/

или на js это выглядит примерно так (root-схема Contact, код не проверял, т.к. в оригинале объекты совсем другие и связи запутаннее)

var allowedStateFilterGroup = Ext.create("Terrasoft.FilterGroup");
allowedStateFilterGroup.logicalOperation = this.Terrasoft.LogicalOperatorType.OR;
var stateFilter = Terrasoft.createColumnFilterWithParameter(Terrasoft.ComparisonType.EQUAL,
	"State", someState);	
var notExistsStateFilter = Terrasoft.createExistsFilter("[State:Id:State].Id");
notExistsStateFilter.subFilters.addItem(Terrasoft.createColumnFilterWithParameter(Terrasoft.ComparisonType.EQUAL, "Id", someState));
notExistsStateFilter.subFilters.addItem(Terrasoft.createNotExistsFilter("[AllowedStates:State].Id"));
allowedStateFilterGroup.add("StateFilter", stateFilter);
allowedStateFilterGroup.add("NotExistsStateFilter", notExistsStateFilter);

Esq вообще удивительно гибкая штука, стоит только заглянуть чуть глубже привычного createColumnFilterWithParameter.

Как я предполагал, всё что нужно делается прямо внутри функции filters, не нужны тут никакие view, ужас какой, не путайте людей.

Не совсем понятно, что значит «почты из почтового ящика MS Outlook». Это может быть или корпоративный Exchange-сервер Вашей организации, или веб-почта Outlook.com (бывший Hotmail).

Только в старых версиях системы: 3.Х, 5.Х и первые версии 7.Х интегрировались с почтовой программой на локальном компьютере, а сейчас 7.Х работает с сервером напрямую по протоколам IMAP/SMTP или MS Exchange.

Следовательно, держать компьютер включенным нет необходимости, папки и правила существуют на сервере.

Как выбрать нужную папку, описано в статье:

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

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

 Добрый день! Спасибо за ответ!

Поясню ситуацию: есть корпоративный почтовый сервер MS Exchange, на котором хранится почта пользователей. В этой почте очень много лишних писем, которые нет смысла загружать в CRM, и соответственно есть переписка с клиентами, которую хотелось бы загружать в CRM.

На сколько я знаю, правила MS Outlook, которые пользователь создает для распределениям почты по папкам, работают только на стороне клиента, т.е. если мой Outlook не запущен, то все письма будут скапливаться в папке "входящие", до тех пор пока не запустится клиент Outlook и не отработаются правила.

Вручную переносить почту по папкам нет никакой возможно, это нужно автоматизировать.

Соответственно вопрос: можно ли как-то модифицировать стандартную процедуру загрузки почты, чтоб была возможность настраивать различные фильтры, например, загружать только ту почту, чьи адреса совпадают с адресами клиентов в базе CRM.. или просто загружать только почту с адресов, которые хранятся в некотором списке.

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

Вот и вот информация, как настраиваются правила на уровне сервера Exchange:

You can use mail flow rules (also known as transport rules) to identify and take action on messages that flow through the transport pipeline in your Exchange 2016 and Exchange 2019 organization. Mail flow rules are similar to the Inbox rules that are available in Outlook and Outlook on the web (formerly known as Outlook Web App). The main difference is mail flow rules take action on messages while they're in transit, and not after the message is delivered to the mailbox. Mail flow rules contain a richer set of conditions, exceptions, and actions, which provides you with the flexibility to implement many types of messaging policies.

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

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

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

Вот и вот информация, как настраиваются правила на уровне сервера Exchange:

Спасибо за информацию, будем изучать!

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

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

Т.е. доработать эти процессы можно самостоятельно или с помощью сторонних разработчиков (партнёров террасофт)? Эти процессе не закрыты от модификации?

Для доработки нужно создавать свои схемы в пакете Custom  и переопределять в них базовую логику.

Учтите, что замещать можно не всё (например, модули специально запрещено), да и часть логики сделана вообще в ядре и недоступна для просмотра и правок, судя по:

using Terrasoft.ExchangeApi.Interfaces;
using Terrasoft.Sync.Exchange;

В конфигурации этих схем нет.

Мобильное приложение не загрузило метаданные модели SysUserInRole.

Добавьте в манифест вот такую секцию:

ApplicationRequiredModels: ["SysUserInRole"]

Кривонос Максим,

 Благодарю, сработало.

В расширенных фильтрах

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

Спасибо за совет, но строка с указанием сплава имеет вид - #Наименование сплава# (#Металл1##Металл2##Металл3##Металл4#) Например: Мельхиор (CuNi)

Вариантов много я бы посмотрел в сторону

1) Искать начинающиеся на #Арб

2) или изменить структуру хранения данных о составе металла

3) а лучше всего, создать свой фильтр в котором вы обработаете вашу строку с указанием сплава. (Например разобьете в массив со списком металлов и его отфильтруете)

А что мешает искать по «(Cu»?

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

Спасибо за совет, хорошая идея!