Добрый день.

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

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

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

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

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

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

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

Tigran Gevorgyan пишет:

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

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

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

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

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

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

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

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

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

Tigran Gevorgyan пишет:

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

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

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

Спасибо))

Tigran Gevorgyan,

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

А добавьте все необходимые колонки (Id, CreatedById, ModifiedById, ModifiedOn, ProccessListener - если наследуетесь от Base object) во View

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

1. Добавьте зависимость в атрибут схемы.

2. Добавьте фильтрацию к справочному полю.

Дамиан Викторович пишет:

1. Добавьте зависимость в атрибут схемы.

2. Добавьте фильтрацию к справочному полю.

Возможно есть другое решение?

Артём, можно настроить бизнес-правило пользовательскими средствами или средствами разработки.

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

Если первое, то нужно, чтобы на базе, куда переностите, уже была такая схема и создавшаяся по ней после публикации таблица в БД. Или же схема создавалась или дополнялась в том же пакете, что и данные в неё. А наполнение справочника затем переносить при помощи привязки данных к пакету.

Если второе, то нужно не создавать объект или замещающий объект вручную, а переносить с сайта-источника готовую схему (или путём выгрузки в md-файл, или через SVN, или пакетами).

Объект Tax — стандартный, у Вас в нём есть какие-то доработки?

Добрый день.

Проверка по правам доступа на операцию CanManageLookups выполняется для всех объектов, которые унаследованы от BaseLookup (Базовый справочник).

Можно попробовать сменить родителя у объекта Вашего справочника на BaseObject (Базовый объект).

В этом случае не забудьте добавить поля Name и Description, которые есть в базовом справочнике, но нет в базовом объекте.

Внесение таких изменений лучше выполнять на тестовой версии.

Алла, зачем менять родителя, просто во встроенном БП справочника перезатереть пустой функцию проверки CheckCanManageLookups.

public override void CheckCanManageLookups() {
}

Так сделано у ряда коробочных справочников, например, у Department.

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

Да, согласна. В данном случае твое решение является оптимальным.

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

Александр, спасибо за ответ. Буду пробовать в это направлении.

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

Алла, ваш вариант тоже подходит, так как использование справочника было лишь номинальным и для удобства администрирования - поля Name и Desc мне не нужны, так как используются поля других справочников: Account + 2 поля Int.

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

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

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

 

Вы можете вывести данный справочник как раздел. Тогда задача будет решена.

 

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

Добрый день! Пример данной реализации можете посмотреть, например, в объекте LeadProduct.

Справочник основан на объекте. Чтобы добавить в него связь с другими справочниками (=объектами) найдите объект справочника и добавьте туда поле с типом "Справочник" и укажите название справочника, связь с которым необходимо добавить, при необходимости выполнив замещение объекта в пользовательском пакете (подробнее читайте в академии)

Михаил, для того, чтобы сделать upsert, нужно выполнить patch-запрос с указанием id в списке полей. Раньше если записи не было, возвращало ошибку, сейчас производится вставка. А если есть, то и раньше, и сейчас — изменение. Готовых именно таких примеров нет, о patch есть в справочнике по API.

Добрый день. По первому пункту такое реализовано в справочнике "Приоритеты обращений" CasePriority (есть в продукте Service). Там можно провалиться в запись справочника и загрузить картинку.

Общий порядок действий примерно таков:

1) создать объект. назовем его BCActivityColor. Наследуем его от базового справочника и добавляем колонку BCImage (Ссылка на изображение).

Не забываем в настройках объекта установить "Изображение" - нашу колонку. запомним UID объекта

2) Создадим для справочника страницу редактирования (я взял коробочную CasePriorityLookupEditPageV2 и выкинул лишнее).  Реализуем там загрузку картинок.

страницу наследуем от Базовая страница справочника ( UIv2 ). пример: CasePriorityLookupEditPageV2

запомним UID странички

3) зарегистрируем нашу страницу редактирования для объекта (sql). 

Привяжем BCActivityColor_SysModuleEntity (указывается UId объекта который создали в п.1) и BCActivityColor_SysModuleEdit (указывается UId схемы странички которую создали в п.2)

не забыть перезайти в почистить кэш.

Пример регистрации страницы справочника CaseCasePriority_SysModuleEdit и CaseCasePriority_SysModuleEntity

4) после заполнения справочника не забыть привязать SysImage и значения нашего нового справочника.

Добрый день. Ошибка возникает при процессе удаления? Пару вариантов, которые могут быть причинами ошибки:

- у пользователя под которым выполняется данная операция (удалить), нет соответствующих прав;  

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

Добрый день.

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

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

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

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

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

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

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

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

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

Ещё длительное удаление может быть связано с логикой, которая добавлена во встроенном или отдельном БП на событии удаления для этого объекта.  В таком случае она отработает только при удалении средствами EntiteSchemaQuery (оно происходит и при удалении пользователем вручную). А при удалении средствами класса Delete она не вызывается: будет намного быстрее, но логика не отработает, что нужно будет учесть и реализовать нужные вычисления отдельно.