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

Аватара пользователя
Игорь Верновский
Сообщения: 9
Зарегистрирован: 06.12.2016 20:31

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

07.02.2018 17:47

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

Аватара пользователя
Dmitry Goncharenko
Сообщения: 4118
Зарегистрирован: 06.06.2012 13:54

07.02.2018 18:30

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

Аватара пользователя
Игорь Верновский
Сообщения: 9
Зарегистрирован: 06.12.2016 20:31

07.02.2018 19:05

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

Аватара пользователя
Dmitry Goncharenko
Сообщения: 4118
Зарегистрирован: 06.06.2012 13:54

07.02.2018 19:22

А почему бы не закрыть переводы во все другие статусы, кроме единственно нужного?

Аватара пользователя
Игорь Верновский
Сообщения: 9
Зарегистрирован: 06.12.2016 20:31

07.02.2018 19:23

Так закрыто. Переводят. В нужный. Только не те, кому положено. Или кому положено, но не кнопкой,а из меню.

Аватара пользователя
Dmitry Goncharenko
Сообщения: 4118
Зарегистрирован: 06.06.2012 13:54

07.02.2018 19:25

А в чем отличие перевода нужным сотрудником в нужный статус, но не кнопкой, а из списка? Не отрабатывает какой-то сценарий?

Аватара пользователя
Игорь Верновский
Сообщения: 9
Зарегистрирован: 06.12.2016 20:31

07.02.2018 19:28

Не отрабатывает. Должен? Что то неправильно делаем?

Аватара пользователя
Dmitry Goncharenko
Сообщения: 4118
Зарегистрирован: 06.06.2012 13:54

07.02.2018 19:30

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

Аватара пользователя
Игорь Верновский
Сообщения: 9
Зарегистрирован: 06.12.2016 20:31

07.02.2018 19:31

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

Аватара пользователя
Dmitry Goncharenko
Сообщения: 4118
Зарегистрирован: 06.06.2012 13:54

07.02.2018 19:39

С ним тоже можно бороться, хотя и чуть сложнее.

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

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

Аватара пользователя
Игорь Верновский
Сообщения: 9
Зарегистрирован: 06.12.2016 20:31

07.02.2018 19:44

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

Аватара пользователя
Dmitry Goncharenko
Сообщения: 4118
Зарегистрирован: 06.06.2012 13:54

07.02.2018 19:48

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

Аватара пользователя
Игорь Верновский
Сообщения: 9
Зарегистрирован: 06.12.2016 20:31

07.02.2018 19:50

Аха, , ок, если никому больше не надо- мы переживем.
Тему можно убивать, если она ненужная.
Спасибо

Аватара пользователя
Dmitry Goncharenko
Сообщения: 4118
Зарегистрирован: 06.06.2012 13:54

07.02.2018 19:50

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

Аватара пользователя
Илья Федоров
Сообщения: 492
Зарегистрирован: 21.01.2018 18:09

18.02.2018 21:21

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

 
Вложения
RPF доп статусы и действия.jpg

Ответить