Добрый день!

Да. Оба пункта действительны. При изменении Last name или Middle name или First name, изменяется поле Full name и наоборот. 

Логика разделения ФИО контакта на Surname GivenName MiddleName настривается системной настройкой ContactFieldConverter, выбором необходимого с# конвертера, которые находятся в таблице ShowNamesBy.

В базовой функциональности существуют два конвертера First name [Middle name] Last name и Last name, First name [Middle name]. 

Оба шаблона включают Middle Name.

Указанные поля заполняются автоматически на основании данных, которые внесены в поле ФИО, с учетом разделителей. В качестве разделителя система распознает пробел и . , ;

Для заполнения по умолчанию используется конструкция "Фамилия, Имя и Отчество" и разделяется на "Имя" и "Фамилия" согласно формата ФИО (Фамилия Имя Отчество).

Правило, которое установлено в системной настройке ContactFieldConverter будет распространятся на новые или редактируемые контакты.

Илья, добрый день!

Не совсем понимаю, что вы подразумеваете под "концертной" программой? Это объект в системе наподоби контактов или контрагентов?

Илья, реализовать вашу логику можно несколькими вариантами. 

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

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

Добрый день.

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

Для определения, какие записи нужно удалять, Вы можете сделать отдельное представление, которое будет содержать все записи из справочника 'Черный список', которые были созданы год назад и раньше, и потом использовать его в БП.

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

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

Что Вы имеете введу  "сделать отдельное представление"  Создать отдельный раздел,  записывать туда все записи из черного списка с полем даты создания и в БП определить запись которая произведена год назад и если да, то удалить запись из раздела и из справочника ?

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

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

Tigran Gevorgyan пишет:

Что Вы имеете введу  "сделать отдельное представление"  Создать отдельный раздел,  записывать туда все записи из черного списка с полем даты создания и в БП определить запись которая произведена год назад и если да, то удалить запись из раздела и из справочника ?

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

А потом для работы с ним из конфигурации создать новую EntitySchema.

Чтобы связать EntitySchema с представлением, необходимо убедиться в соблюдении следующих условий:

1. В свойствах объекта установлен признак “Представление в базе данных”.

2. Название объекта соответствует названию представления в БД.

3. Структура объекта и представления идентичны.

Со стороны приложения View воспринимается как обычный объект.

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

Tigran Gevorgyan пишет:

Я думая это можно как-то осуществить через системные настройки

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

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

Спасибо))

Tigran Gevorgyan,

Если будут вопросы, обращайтесь

Добрый день!

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

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

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

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

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

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

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

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

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

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

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

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

Вильшанский Дмитрий, 

this.Terrasoft.SysSettings.querySysSettingsItem('SlaCalculationEnabled', function (slaEnabled) {console.log(slaEnabled)})

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

Добрый день.

Ошибка не совсем правильно передает суть проблемы. Дело в правах – т.е. у пользователя нет прав на данную настройку.

Дмитрий, 

Следующий код работает:

//Установить значение системной настройки
Terrasoft.Core.Configuration.SysSettings.SetValue(UserConnection, "SysSettingsName","SysSettingsValue");
 
//Установить значение системной настройки без учета прав
Terrasoft.Core.Configuration.SysSettings.SetValue(UserConnection, UserConnection.RootAdminUnitGroupId, "SysSettingsName", "SysSettingsValue");

Здравствуйте, Богдан!

Изменение значений системных настроек через OData не предусмотрено.

Есть два варианта решения этой задачи:
1) Создать собственный web сервис, который будет менять значения системных настроек в таблице SysSettingsValue
2) Создать объект, к которому будут идти обращения по OData. Логикой в созданном объекте (или триггерами в БД) необходимо будет переносить новые значения в таблицу SysSettingsValue.

Раньше было нельзя, только несколько таблиц с префиксом Sys открыты на запись

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

Системная настройка "Тип сравнения для строковых колонок" влияет только на поиск в быстром фильтре. В версии 7.9.0 поиск в быстром фильтре для справочных полей был доработан - при фильтрации по справочному полю система предлагает варианты, названия которых начинаются с введенного в поиске текста.

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

Спасибо за быстрый ответ :smile:, а как тогда можно поменять тип поиска в окне справочника, чтобы не осуществлять поиск с % ?

:smile:

Нужно заместить схему LookupPageViewModuleGenerator. Метод pushSelectFilters отвечает за тип поиска. В коробочной версии тип поиска START_WITH.

В замещающей схеме Вам необходимо заменить тип поиска на CONTAIN.

Поиск "%запрос%" отрабатывает значительно медленнее, чем поиск "запрос%".

Спасибо! :smile:
Возник еще такой вопрос по этой теме:
когда вбиваем текст просто в поле, то без % не находит туры:

а если через всплывающее окно, то нормально срабатывает:

Можно ли как-то реализовать, что бы и в поле поиск работал без % ?

Для изменения типа сравнения с первого скриншота, вам необходимо изменить возвращаемое значение метода "getLookupComparisonType" в файле all-combined, сделать это можно если у вас сайт on-site самостоятельно, если же на серверах bpm'online то через службу поддержки.

.