Вероятно, почти все, прикладные разработчики Directum RX задавались вопросом: "Как дать возможность редактировать используемые в коде константы администраторам, коллегам, друзьям и прохожим!?". Регулярный или внезапный перенос разработки на Prodact сервер звучит как-то не очень хорошо и даже угрожающе.
Так же, некоторые проблемы вызывают определенные моменты администрирования системы:
Решения всех этих проблем и вопросов разные, но при этом они логическим образом объединяется в одно универсальное решение для администратора и разработчика, которое можно использовать на любых проектах, а так же дополнять и расширять по своему усмотрению.
В состав решения входят модули:
Назначение: Объединяет дополнительные возможности доступные администратору системы, поскольку редактирование обложки "Администрирование" прикладному разработчику не доступно.
Права доступа: Доступ к обложке имеют только пользователи входящие в роль "Администраторы", для остальных пользователей модуль скрыт.
Назначение: Позволяет администратору снять блокировку объекта в системе, если пользователь закончил работать с объектом, а блокировка по разным причинам осталась в БД.
Права доступа: доступ к действию имеют только пользователи входящие в роль "Администраторы".
Форма диалога удаления блокировки
Примечание: Для выбора в диалоге доступны только активные на текущий момент блокировки.
Форма диалога подтверждения удаления блокировки
Примечание: Перед удаление блокировки запрашивается подтверждение действия.
Назначение: Позволяет разработчику создавать константы для хранения редактируемых значений, которые могут использоваться при разработке прикладного кода.
Права доступа (справочник Константы): роль "Администраторы" - редактирование, роль "Все пользователи" - просмотр (визуально справочник недоступен).
Права доступа (справочник Группы констант): роль "Администраторы" - редактирование.
Внимание: Создание, удаление записей запрещено для всех пользователей системы!
Доступные типы:
Примечание: Позволяет объединять константы в логические группы.
Пример формы карточки с типом - целочисленное значение (справочник "Константы")
Пример формы карточки с типом - список строк (справочник "Константы")
Назначение: Удаляет файлы с расширением *.log в папках (включая вложенные папки) старше N дней.
Используемые константы:
ClearLogsPaths – список путей для очистки лог файлов;
LogsLifeTime – время жизни лог файлов (в днях). (По умолчанию 10 дней).
Расписание запуска: Один раз в день, время запуска 7:00.
Назначение: Позволяет сформировать отчет об использовании текущего объекта в справочниках, документах или задачах.
Права доступа: роль "Все пользователи" имеют права на выполнение отчета.
Решение активно используется во всех, без исключения, проектах компании. Основным локомотивом развития решения, как не удивительно, выступил модуль с прикладными константами.
Данное решение пока не может облегчить прикладную разработку, но способно упростить поддержку разработанных решений и модулей.
Ждите новой статьи на Club Directum!
Обсудите реализацию с экспертом Directum
Комментарии (10)
Добрый день.
Решение выглядит интуитивно понятным и простым в использовании. Что очень здорово, учитывая то как часто поступают вопросы по решению вопросов с блокировками.
Уточните пожалуйста, реализована ли работа со сбором информации о всех блокировках и возможность массового снятия блокировок с объектов?
Александр, Спасибо.
Массового сбора информации (что-то типа истории) по блокировкам нет, т.к. о таком пока никто не просил. Есть функционал сбора статистики по количеству работающих пользователей в системе, но он в данное решение он не вошел поскольку это так же был единичный запрос. Реализация такого функционала не сложная делается в течении часа. Если я правильно понял вопрос! )))
Массовое снятие блокировок так же не делал, т.к. не было необходимости, но за идею спасибо. Появится часок свободного времени реализую, там не сложно.
Сергей, благодарю за ответ.
а как его правильно импортировать? я пока далек от разработки в RX, попробовал импортировать через утилиту импорта и получил ошибку, опубликуйте сначала решение. ну и база поломалась, восстановил из бэкапа. версия 3.5.24
Артем, А Вы импортировали в среду разработки или сразу в RX? По идее ошибки быть не должно, я обязательно проверю этот момент.
Решение импортируется разработчиком в среду, т.к. без этого кроме блокировок и очистки логов ничего работать не будет.
Сергей, сразу в RX, в среду не пробовал, но скоро обучусь и попробую)
Сергей, интересные решения получились. Упрощают жизнь администраторам и разработчикам.
Меня особо привлекло решение для администраторов по удалению лог-файлов. Скорее даже удивило. Ожидаешь, что при работе с системой сохраняется ее история. Чтобы в случае неожиданных ситуаций, найти зацепки. К примеру, может понадобиться лог по удалению важного документа, пропажу которого обнаружили через 2 недели. Из каких критериев\по каким причинам выбрали период в 10 дней? И рассматривали ли вариант архивирования логов вместо удаления? Если да, то почему отказались?
Сергей, добрый день.
Достаточно интересное решение.
Возник ряд вопросов к формированию отчета:
Также плюсую к вопросу Ксении относительно логов.
И надеюсь в будущем напишете по новому модулю для хранения функций. Очень хотелось бы посмотреть.
Успехов в развитии решения!
Ксения, За свою практику работы с D5 и RX, ни мне, ни коллегам не требовались для анализа логи старше скажем недели (за крайне редкими исключениями).
Если ошибка есть, то дистанции в 2-3 дня вполне достаточно для поиска и анализа. Логи можно архивировать, это не сложно, но для кого !? Тем более, логи типа Worker за день может увеличиться до сотен МБ при активной работе кучи процессов.
Ситуации, когда архив бы понадобился для какого-либо анализа, у меня не было, а вот когда система падает из-за переполнения системного диска, неоднократно.
Критерий в 10 дней настраивается через константы, это просто среднее значение.
P.S. Если мне не изменяет память, то история работы с документом храниться в БД, таблица DocHistory вроде.
Яков, Добрый день, спасибо.
1) Формирование происходит запросами к БД, поэтому без учета прав пользователя. Т.к. кнопку в объекте все равно делает разработчик, то и ограничить доступ к отчету не составит проблем, например в функции Can действия скрывать его от всех кроме администраторов или другой роли.
2) Да можно, но есть "ограничения". Т.к. отчет собран на коленке с прямыми запросами, из-за самой структуры БД нельзя однозначно идентифицировать какой-то объект, поскольку идентификатор записи теряет свою уникальность в разрезе других таблиц.
Другими словами, при использовании самого простого вызова в отчет неизбежно будет попадать мусор, который к текущей записи не имеет никакого отношения. Нужно либо проводить анализ разработки, для его нормального вызова с ограничениями, либо анализировать сам отчет.
3) В текущем варианте это сделать крайне, крайне сложно. Проще написать другой отчет, который будет собирать данные не через БД, а используя рефлексию C#, но времени на такие хотелки категорически нет.
P.S. Новая версия модуля есть, разного функционала туда добавил, функций для разработчиков, но на статью пока не хватает времени. Я сюда заглянул пока сборка проекта идет ))))