Страница 1 из 1

Убрать возможность ручной смены статуса исполнителем

Добавлено: 07.02.2018 17:47
Игорь Верновский
ну или постановщиком.
 Если есть задача по шаблону, смена статуса происходит  кнопкой, которая запускает нужный сценарий.
Но у постановщика ( исполнителя) остается возможность сменить  статус  в обход кнопки, просто изменив статус в соответствующем меню. Таким образом сценарий не отрабатывается правильно, вся цепочка рушится.
Зачем они это делают- отдельный вопрос.
В общем задача: спрятать от исполнителя возможность ручной смены статуса, оставив только запуск сценария кнопкой.
Та же история со сменой исполнителей в деталях задачи. Нельзя ли это спрятать, при необходимости? Ну или ограничить соответствующие права в шаблоне.

Добавлено: 07.02.2018 18:30
Dmitry Goncharenko
Давайте начнем с простого варианта: можно в настройках переходов между статусами убрать возможность перевода в другие статусы, кроме одного нужного. Тогда пользователь физически не сможет этого сделать. Это решает проблему?

Добавлено: 07.02.2018 19:05
Игорь Верновский
Так он и переводит в другой , доступный статус. Только переводит не тот, кто должен перевести. А иногда ( по загадочной для меня причине) так делает тот, кто должен делать,  Т.е исполнитель вместо того, что бы нажать на кнопку, зачем то меняет статус в меню. 
Воспитание помогает, но частично.
Я понимаю, что это не документооборот, тут другая логика. Широкие возможности- это плюс Планфикса. Но хорошо бы иметь возможность эти возможности ( сори ) ограничивать.

Добавлено: 07.02.2018 19:22
Dmitry Goncharenko
А почему бы не закрыть переводы во все другие статусы, кроме единственно нужного?

Добавлено: 07.02.2018 19:23
Игорь Верновский
Так закрыто. Переводят. В нужный. Только не те, кому положено. Или кому положено, но не кнопкой,а из меню.

Добавлено: 07.02.2018 19:25
Dmitry Goncharenko
А в чем отличие перевода нужным сотрудником в нужный статус, но не кнопкой, а из списка? Не отрабатывает какой-то сценарий?

Добавлено: 07.02.2018 19:28
Игорь Верновский
Не отрабатывает. Должен? Что то неправильно делаем?

Добавлено: 07.02.2018 19:30
Dmitry Goncharenko
Должен, потому что сценарий привязан к смене статуса, а не к смене статуса именно кнопкой. Поэтому при правильном раскладе кто бы и каким бы образом ни изменил статус, сценарий должен отработать.

Добавлено: 07.02.2018 19:31
Игорь Верновский
Ок, проверим.
Но остается создатель задачи, который может менять статус там, где ему не положено

Добавлено: 07.02.2018 19:39
Dmitry Goncharenko
С ним тоже можно бороться, хотя и чуть сложнее.

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

Вариант 2: Вообще запретить смену статусов для всех пользователей и менять их исключительно сценариями. Тут используется хитрый эффект: сценарии могут делать вещи, запрещенные пользователям, поэтому на них запрет перевода из статуса в статус не распространяется. Это сделано специально для того, чтобы администратор мог настроить сложные исключения из общих правил. Минусом такого подхода в данном варианте будет то, что если запретить перевод в статус для пользователей, то не будет отображаться кнопка в интерфейсе и придется ее чем-то заменить. Например, полем типа "Список" в представлении "Плашки".

Добавлено: 07.02.2018 19:44
Игорь Верновский
клиент, который может начудить, не понимая последствия своих поступковЕсли бы только клиент..... да, про перевод в участники идея понятна. Возможно в нашем случае это выход.
Кнопка- это важно. Итак половина жмет не на ту или не замечает.
Но тоже понятно.
Спс. Жаль, что доступ к этим элементам нельзя ограничивать. Это сознательно сделано или "так склалось"? 
Мы используем систему в первую очередь как документооборот. Понимаю, что это не совсем оно, но нам очень даже подходит. Мы перебрали не одну. Но в документообороте несколько другой подход. Там пользователю стараются отрезать все что можно. Но тогда появляются другие проблемы

Добавлено: 07.02.2018 19:48
Dmitry Goncharenko
Жаль, что доступ к этим элементам нельзя ограничивать. Это сознательно сделано или "так склалось"?
Просто до сегодняшнего дня еще ни разу никто не просил убрать смену статуса из задачи) А так-то ничего невозможного нет.

Добавлено: 07.02.2018 19:50
Игорь Верновский
Аха, , ок, если никому больше не надо- мы переживем.
Тему можно убивать, если она ненужная.
Спасибо

Добавлено: 07.02.2018 19:50
Dmitry Goncharenko
Ненужных тем не бывает - пусть собирает товарищей по несчастью, вдруг да насобирает на релиз)

Добавлено: 18.02.2018 21:21
Илья Федоров
Добрый вечер Уважаемые коллеги. В моем проекте мы помимо статусов используем два дополнительных поля, настройка сценариев работы с которыми может решить проблему Игорь Верновский.
Итак что мы делаем.
Есть два поля типа списки доп. статусы и доп. действия. Устанавливая доп статусы Исполнитель фиксирует более подробный статус по системе. Устанавливая значения действия, он вызывает определенный сценарий который срабатывает только при условии выполнения ряда условие при которых учитывается и статус задачи и доп. статус, при этом "действие" может переводить статус на нужный. 
Можно настроить сценарий реакции на действие таким образом чтобы, учитывались ваши ограничения связанные с пользователями, например оно действует только если исполнители из определенной группы и т.д. Можно обойтись без действий и работать с полем доп статус, который в зависимости от ваших условий либо будет переводить типовой статус в нужное значение либо будет "писать в задачу ответку типа: "брат, ты не можешь это сделать ибо...". "Ответка" это либо действие, либо заполнение поля типа текст которое размещено на форме.
Чтобы визуально пользователю было привычнее удобнее отображайте списки в виде "плашек" (кнопок).