🔄 Исправлена логика переноса трудоустройств при изменении типа пользователя
Мы исправили ошибку в логике изменения типа пользователя (сотрудник ↔ заказчик), которая могла приводить к некорректному отображению списка компаний или потере данных о трудоустройстве.
🐞 Суть проблемы
В системе существовал следующий проблемный сценарий:
-
Заказчик был привязан к двум компаниям (имел 2 трудоустройства).
-
При переводе такого пользователя в сотрудники в его профиле оставалось только одно трудоустройство (первое из списка). Второе не отображалось.
-
Если затем добавить сотруднику новую компанию и перевести его обратно в заказчики, в профиле неожиданно появлялись все три трудоустройства, включая то, которое ранее "пропало".
🛠️ Что было исправлено
Мы переработали логику работы, чтобы обеспечить корректный и предсказуемый перенос данных о трудоустройстве:
-
При переводе Заказчика → Сотрудника:
-
В профиле сотрудника теперь сохраняются все актуальные трудоустройства, которые были у пользователя в статусе заказчика.
-
-
При переводе Сотрудника → Заказчика:
-
В профиле заказчика теперь остаются только те трудоустройства, которые были явно указаны в его форме как сотрудника. Это исключает появление "лишних" или исторических записей.
-
🎯 Результат для пользователей и администраторов
-
Предсказуемость: При изменении типа пользователя список его компаний (трудоустройств) больше не "теряется" и не "размножается" неожиданным образом.
-
Целостность данных: Информация о трудоустройстве переносится корректно и соответствует тому, что видит администратор в интерфейсе на момент изменения.
-
Стабильность: Исправление исключает появление ошибок в смежных процессах, которые могли опираться на некорректные данные о трудоустройстве пользователя.
📋 Расширена история изменений в заявках: теперь логируются материалы, дочерние заявки и акты
В систему HubEx добавлено детальное логирование изменений по трем важным вкладкам карточки заявки. Это повышает прозрачность, облегчает аудит и помогает восстановить ход работы над задачей.
🔍 Что теперь отслеживается?
1. Вкладка «Необходимые материалы»
Логируются все операции с материалами:
-
Добавление нового материала в заявку.
-
Удаление материала из списка.
-
Изменение количества уже добавленного материала.
2. Вкладка «Дочерние заявки»
Логируется привязка родительской заявки.
Система фиксирует номер заявки, для которой текущая задача становится дочерней. Это работает для обоих сценариев:
-
Когда заявку создают отдельно и вручную заполняют поле «Родительская заявка».
-
Когда дочернюю заявку создают напрямую из соответствующей вкладки родительской заявки.
3. Вкладка «Акт выполненных работ»
Логируются ключевые действия по закрывающему документу:
-
Получение подписи заказчика (фиксируется факт подписания).
-
Данные принявшего акт: ФИО и должность сотрудника.
🎯 Преимущества нововведения
-
Полная картина: Теперь история изменений заявки отражает работу не только с основными полями, но и с комплектацией, связанными задачами и документами.
-
Повышенная ответственность: Все операции фиксируются с указанием автора и времени, что способствует дисциплине и упрощает разбор спорных ситуаций.
-
Удобство аудита: Аналитикам и руководителям проще отслеживать ход выполнения сложных заявок, требующих материалов или состоящих из нескольких задач.
-
Восстановление данных: В случае ошибок легче понять, какие именно изменения были внесены и кем.
⚙️ Как посмотреть историю?
Все перечисленные изменения отображаются в общей истории изменений заявки (вкладка «История изменений»). Записи появляются автоматически при сохранении заявки после редактирования соответствующих вкладок.
🛡️ Безопасное удаление стадий заявок с проверкой на использование
Мы внедрили новую процедуру удаления стадий заявок, которая защищает от случайного нарушения настроенных бизнес-процессов. Теперь перед удалением система проверяет, используется ли стадия в жизненных циклах.
🔍 Что изменилось в интерфейсе?
Раньше при нажатии кнопки «Удалить» для стадии отправлялся запрос на удаление без каких-либо предупреждений.
Теперь перед удалением срабатывает проверка:
-
Система анализирует, в каких типах заявок и переходах участвует выбранная стадия.
-
Если стадия не используется нигде — появляется стандартное подтверждение удаления.
-
Если стадия используется — система покажет детальное предупреждение со списком всех типов заявок и переходов, где она задействована.
⚠️ Как выглядит новое предупреждение?
Если стадия используется, администратор увидит сообщение следующего формата:
«Данная стадия участвует в ЖЦ следующих типов заявок:
-
Ремонт
-
[Название удаляемой стадии]→ Завершить работу по заявке -
[Название удаляемой стадии]→ В пути -
Назначена →
[Название удаляемой стадии] -
Новая →
[Название удаляемой стадии]»
-
🎯 Зачем это нужно?
Новый механизм помогает администраторам:
-
Избежать ошибок: Исключает случайное удаление стадий, критичных для работы бизнес-процессов.
-
Предотвратить «битые» переходы: Защищает от появления «висящих» ссылок в жизненных циклах заявок.
-
Принять осознанное решение: Дает полную информацию перед выполнением необратимого действия.
-
Упростить аудит: Позволяет быстро понять, в каких процессах задействована стадия.
💡 Важные детали
-
Удаление все равно возможно: Система только предупреждает, но не блокирует удаление. Окончательное решение остается за администратором.
-
После исправлений: Если администратор зайдет в настройки жизненных циклов и удалит все переходы, связанные со стадией, то при следующей попытке удаления предупреждение не появится — будет стандартное окно подтверждения.
-
Полная картина: В предупреждении сначала перечисляются переходы ИЗ удаляемой стадии, затем переходы В неё, что делает список максимально наглядным.
🔧 Новая кнопка «Восстановить по умолчанию» в настройке формы заявки
Администраторы HubEx теперь могут одним кликом вернуть внешний вид формы заявки к исходному состоянию. Это упрощает настройку и исправление ошибок конфигурации.
🎯 Что делает новая функция?
В интерфейсе настройки формы заявки, рядом с другими кнопками действий, появилась новая опция «Восстановить по умолчанию». Она позволяет:
-
Сбросить все пользовательские изменения в расположении блоков и полей.
-
Вернуть форму к её изначальному, системному виду.
🔄 Как это работает?
-
В шапке раздела настройки формы заявки нажмите на кнопку меню (
⋮). -
В выпадающем списке выберите пункт «Восстановить по умолчанию».
-
Система мгновенно загрузит и применит стандартный шаблон формы.
-
Вы увидите форму в её первоначальной конфигурации.
💾 Что происходит после восстановления?
-
Если вы хотите сохранить дефолтный вид — просто нажмите основную кнопку «Сохранить». Система обновит конфигурацию формы.
-
Если вы передумали — нажмите «Отменить». Все изменения, сделанные кнопкой восстановления, будут отменены, и форма вернётся к своему последнему сохранённому состоянию.
Преимущества для администраторов:
-
Экономия времени: Не нужно вручную удалять или перемещать десятки полей для отката изменений.
-
Быстрый старт: Легко вернуться к чистой конфигурации для тестирования или создания новой кастомной формы «с нуля».
-
Исправление ошибок: Простой способ устранить проблемы с вёрсткой или некорректной настройкой полей.
⚙️ Оптимизация: планы помещений загружаются только при наличии прав
Мы оптимизировали работу веб-интерфейса при открытии формы объекта. Теперь запросы для отображения разделов «Планы помещений» загружаются только у пользователей, имеющих соответствующие права.
🎯 Что изменилось?
Раньше при открытии или редактировании карточки объекта система всегда отправляла запросы для получения данных о планах помещений, независимо от прав пользователя.
Теперь система проверяет права пользователя, полученные при авторизации, и загружает эти данные только при необходимости.
🔐 Какие права проверяются?
Система анализирует наличие двух полномочий:
-
«Планы помещений - планы на форме объекта» (право на просмотр).
-
«Планы помещений - добавление и модификация существующих планов» (право на управление).
⚡ Как это работает?
-
При открытии формы редактирования/копирования объекта система проверяет, есть ли у текущего пользователя хотя бы одно из двух указанных выше полномочий.
-
Если прав нет — запросы на получение плана объекта не отправляются:
-
Соответствующий раздел интерфейса («Планы помещений») не отображается.
-
-
Если права есть — запросы отправляются, данные загружаются, и раздел отображается как обычно.
🚀 Результат и преимущества
-
Ускорение загрузки формы: Для пользователей без соответствующих прав форма объекта теперь открывается быстрее, так как исключаются лишние сетевые запросы.
-
Снижение нагрузки: Уменьшается нагрузка как на браузер пользователя, так и на серверную часть приложения.
В случае возникновения проблем - пишите нам в поддержку Telegram @hubex_bot или на почту help@hubex.ru