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

[Игорь Верновский]

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

[Dmitry Goncharenko]

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

[Игорь Верновский]

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

[Dmitry Goncharenko]

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

[Игорь Верновский]

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

[Dmitry Goncharenko]

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

[Игорь Верновский]

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

[Dmitry Goncharenko]

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

[Игорь Верновский]

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

[Dmitry Goncharenko]

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

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

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

[Игорь Верновский]

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

[Dmitry Goncharenko]

Жаль, что доступ к этим элементам нельзя ограничивать. Это сознательно сделано или "так склалось"?

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

[Игорь Верновский]

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

[Dmitry Goncharenko]

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

[Илья Федоров]

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