Доступность смены статуса для групп пользователей, пользователя, проекта

[7OH]

Необходимо реализовать настройку доступности смены статусов (как в карточке задачи, так и на канбан доске).
Настраиваться должно С какого статуса и НА какой можно менять - группе пользователей, пользователю.
В карточке - при выборе статуса - показывать только доступные.
В канбан доске - при начале и окончании перетаскивания определять возможность.
Так работает в JIRA - удобно - не даёт разработчику перекинуть задачу из "В процессе" в "Архив" или, например, "К оплате".

[BlizD]

А где хранится такая настройка? По идее это необходимо указывать в самом статусе.
Может использовать для этого новую ТЧ "ДоступныеДляПереходаСтатусы" в спр. узСтатусыЗадач

[milanse]

У меня есть похожее решение.
Выглядит так:

Реализовано через РС, текущий статус, новый статус, наименование команды. Но тут надо еще права пользователей смотреть. И, по хорошему, в разрезе проектов.

[7OH]

Может использовать для этого новую ТЧ "ДоступныеДляПереходаСтатусы" в спр. узСтатусыЗадач

Где-то так и хочется - да.

У меня есть похожее решение.

Делись ) - попробуем адаптировать.

[milanse]

Ну у меня без учета прав, просто РС. Я сам заманался каждый раз выбирать нужный статус )

[7OH]

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

[milanse]

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

[7OH]

За мерж можно и отдельное спасибо сказать будет )))))

[7OH]

Решил добить задачу.
Давайте освежим.
Настройка использования механизма ограничений должна быть в разрезе Проекта\Основной задачи ?
Если да - тогда реквизит надо добавить в обе сущности - если хоть в одной заполнено - используется.
Дальше регистр возможности смены - изменения:
Проект\ОсновнаяЗадача
Пользователь\Группа
СтатусНачальный
СтатусКонечный
Показатели:
Отключить (чтобы запись не удалять при необходимости)

Доступность выбирается максимальная : если проекту доступно 1, а задаче 2 - по итогу доступно и 1 и 2.
Аналогично с пользователь\группа.

Ок ?

[7OH]

Сделал только про проекту.
Изменения:
РегистрСведений.узДоступностьСменыСтатусовЗадач - добавлен
Подсистема.узУправлениеЗадачами - добавлен РегистрСведений
Роли : узПолныеПрава, узПользователь, узПользовательОграничениеДоступаЧтение, узПользовательОграничениеДоступаИзменение - права на РегистрСведений
Справочник.узЗадачи.ФормаЭлемента - код по ограничению смены статусов
Справочник.узПроекты - новый реквизит ОграничиватьСменуСтатусов + вывод его на все формы справочника
Обработка.узКанбанДоска.ФормаДинамическая - код проверки смены статуса

Файл на диске - https://disk.yandex.ru/d/w0MDjl0sPtqFwQ

[BlizD]

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

[BlizD]

@7OH
Мне не очень нравится идея с отдельным регистром сведений.

Поэтому предлагаю переделать на новую табличную часть "ДоступныеДляПереходаСтатусы" в справочнике узСтатусыЗадачи

1. Реквизиты ТЧ:

• Проект - (Справочник.узПроекты);
• Пользователь - Справочник.ГруппыПользователей, Справочник.Пользователи ;
• Основная задача - Справочник.узЗадачи;
• СтатусНачальный - Справочник.узСтатусыЗадачи ;

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

2. код проверки разместить в модуле объекта узЗадачи в событии ПередЗаписью.

3. на форме задачи и канбан доски - можно не ограничивать выбор статусов, пусть будут доступны все. Проверка сработает при попытке перевести.

[7OH]

А как видеть сводные данные по группе пользователей ?
Удобство ввода уйдёт.
Сейчас пляшем от проекта , для каждого пользователя группы - сразу видна цепочка доступностей.
Как вводить понятно при хранении в статусе - я пока не представляю

[BlizD]

Думаю лучше будет сделать запрещающую таблицу "ТЧ ЗапрещеныДляПереходаСтатусы" в этом случае по идее настроек будет меньше нужно вводить.

Давай здесь попробуем смоделировать разные настройки

https://docs.google.com/spreadsheets/d/1P-horjncEp3jK9_TQZqgRG3cWnqmPVML/edit?usp=sharing&ouid=111332701158750307557&rtpof=true&sd=true

[7OH]

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

[BlizD]

Ок, вернул разрешающие "ДоступныеДляПереходаСтатусы"

[7OH]

А чем не нравится регистр ?
Всегда же советуют, чтобы не записывать лишний раз сущность - создавать отдельный регистр с отдельными правами.
Чтобы понять в задаче - всё равно нырять куда-то - что в статус, что в регистр.
По поводу проверки перед записью - могу не согласиться.
Пример: я не знаю, что мне доступно и буду на каждый статус пытаться записью задачи проверять. А при ограничении сразу в поле ввода - я на ходу вижу - можно или нет.

[BlizD]

>А чем не нравится регистр ?
Всегда же советуют, чтобы не записывать лишний раз сущность - создавать отдельный регистр с отдельными правами.
Чтобы понять в задаче - всё равно нырять куда-то - что в статус, что в регистр.

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

>По поводу проверки перед записью - могу не согласиться.

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

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

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

[7OH]

Ок - добавлю проверку и в модуль объекта - согласен.
На канбан доске проверка уже есть.

[7OH]

Ещё вопрос - как разрешить (в случае хранение в ТЧ статуса) изменение из Готово в любой ?
Это надо писать во все доступные статусы строку?
Учитывая, что мы согласились работать с разрешениями - мы теряем возможность смены в любой новый.
Сейчас красиво разрешение на все действия реализованы одной строкой - с двумя пустыми статусами.

[BlizD]

Да, что то не взлетает.
Поэтому и хотел запрещающие статусы сделать. Если нет записи в тч, значит все разрешено

[7OH]

Может на следующих выходных всё таки взглянуть на текущее решение ещё раз ?
Минимум записей - и не пропускаем ничего от будущих изменений.
Всё запрещено - разрешения вносим.
Что-то внесли новое - никуда в разрешения не попадёт.
Ну и регистр, так как пустые записи с обоих сторон.

[BlizD]

Можешь в том ексель. Привести примеры настроек в случае с регистром?

[7OH]

Немного расписал плюсы минусы - детально не стал - вроде и так прозрачно выходит.
Поправил в форме ввода в одном месте.
Добавил проверку для записи программной в модуле задачи (такую же как в конбан доске).
Файл на диске - https://disk.yandex.ru/d/Pf81DQy98_AkYA

[BlizD]

@7OH Залил изменения, провел рефакторинг.
Убрал форму для заполнения, оставил простую форму записи.
Разместил на форме проекта настройку списка доступных.

Подготовил инструкцию https://github.com/BlizD/Tasks/wiki/Как-настроить-доступные-смены-статусов-для-задач