Возможность создания "служебных" полей для авто-отображения во всех задачах/контактах и шаблонах

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

Добрый день, Уважаемые коллеги.
Прошу поддержать эту идею - возможность добавления "служебных кастомных полей". Суть идеи.
Нужна возможность создать поле задачи или контакта и пометить его специальным признаком "служебное".
Особенность таких полей заключается в том что данное поле нет необходимости вручную прописывать в шаблонах, они автоматически отображаются во всех шаблонах в специальное группе (можно предусмотреть порядок их отображения единый для всех шаблонов) и может быть заполнено для всех задач/контактов.
Для чего это нужно.
Например в одном из проектов во все задачи добавляем не менее 10 служебных полей, часть которых компенсирует отсутствие типовых полей, а часть для выполнения контрольных функций, например:
- Дата отмены задачи (системного/типового нет);
- Замечание;
- Замечание время;
- Замечание Автор;
- Контроль замечания
- Контроль время отмены
- Сложность;
- Причины отказа;
- Подтверждение отказа
и т.п.
Каждый раз когда возникает необходимость добавить еще одно такое поле приходится вручную менять все шаблоны задач (на текущий момент 29 по задачам, 4 по контактам). Трудоемкость изменений повышается и также постоянно надо проверять все ли служебные поля добавлены корректно, одинаково ли они расположены и т.п.
В качестве альтернативы можно сделать возможность отметки шаблонов и добавления поля через пункт изменить без открытия каждого шаблона (по аналогии с массовым изменений значений полей задач).

http://joxi.ru/8An7zkwujPw6Xr

[Асия Аскаровна Ахметова]

мне необходимо поле Причина отказа при переходе в статус Завершенная, обязательное для заполнения

[Павел Кочетков]

Считаю, что такую задачу необходимо решать наследованием полей, при создании шаблонов на базе другого шаблона.

И если изменяется родительский шаблон, то подчиненные шаблоны тоже принимают эти изменения (хотя бы в плане добавления)

словно говоря есть " шаблон1". На базе него создается "Шаблон 10"- Шаблон 15". и если в Шаблон 1 добавлено поле, то оно должно добавиться во все шаблоны, созданные на базе Шаблона1. А если поле добавляется в Шаблон2, то оно добавляется в шаблоны созданные на базе него, т.е. в шаблоны 20-29.

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

мне необходимо поле Причина отказа при переходе в статус Завершенная, обязательное для заполнения

Асия, ваше сообщение не совсем об этом.
Данная задача может решаться двумя способами:
1. Создать сценарий (или несколько сценариев) на событие изменено значение поля Статус,
Условия Статус = Завершенная;
Не Содержит значение в поле Причина отказа.
Действие, Изменить статус = <Предыдущее значение>
Почему может понадобится два или более сценариев? Например в статус Завершенная можно перейти из двух статусов В работе и Выполненная.
Тогда нам нужно будет два сценария
- один для проверки Условия Предыдущий статус = В работе и действия Изменить статус В работе.
- второй для проверки Условия Предыдущий статус = Выполненная и действия Изменить статус Выполненная.


2. В настройках статусов процесса Закрываете возможность пользователям выбирать статус Завершенная. Создаете кнопку с названием Завершить задачу, условие отображения только в том случае если заполнено поле Причина отказа. Действие при нажатии Изменить статус = Завершенная.

Мне больше нравится вариант 2, но увы есть ограничение на количество кнопок, и даже на самом дорогом тарифе их количество ограничено 15, и например у меня по одному процессу лимит уже исчерпан (при этом 5 кнопок ушло на кнопки общие для всех процессов).

P.S. И дополнительный комментарий, по мне так методически неверно "отказные" задачи переводить в завершенные, для этих целей есть другой типовой статус "Отмененная". В моей картине мира Завершенная это успешно выполненная задача, достигшая цели постановщика. А отмененная это задача по которой не получен нужный результат.
Например задача-сделка. Завершенная если договор заключен и сделка свершилась, Отмененная если Клиент отказался от сделки.

[Dmitry Goncharenko]

В общем согласен с Ильей, 2 комментария:

Почему может понадобится два или более сценариев? Например в статус Завершенная можно перейти из двух статусов В работе и Выполненная.
Тогда нам нужно будет два сценария
- один для проверки Условия Предыдущий статус = В работе и действия Изменить статус В работе.
- второй для проверки Условия Предыдущий статус = Выполненная и действия Изменить статус Выполненная.

Возможно, это слишком глубоко и достаточно одного сценария на событие "Задача изменена и стала соответствовать условиям" с условием "Статус = Завершенная". Он закрывает переход в статус "Завершенная" из любого статуса.

P.S. И дополнительный комментарий, по мне так методически неверно "отказные" задачи переводить в завершенные, для этих целей есть другой типовой статус "Отмененная". В моей картине мира Завершенная это успешно выполненная задача, достигшая цели постановщика. А отмененная это задача по которой не получен нужный результат.
Например задача-сделка. Завершенная если договор заключен и сделка свершилась, Отмененная если Клиент отказался от сделки.

Это верно и я тоже не стал бы так делать. Но отмечу, что в стандартной конфигурации Управление сделками используется несколько другой подход: сделки в любом случае переходят в статус "Завершенная", а за успешность/неуспешность отвечает отдельный признак. Возможно, Асия использует эту конфигурацию, и именно поэтому возник вопрос именно в связке со статусом "Завершенная".

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

В общем согласен с Ильей, 2 комментария:

Почему может понадобится два или более сценариев? Например в статус Завершенная можно перейти из двух статусов В работе и Выполненная.
Тогда нам нужно будет два сценария
- один для проверки Условия Предыдущий статус = В работе и действия Изменить статус В работе.
- второй для проверки Условия Предыдущий статус = Выполненная и действия Изменить статус Выполненная.

Возможно, это слишком глубоко и достаточно одного сценария на событие "Задача изменена и стала соответствовать условиям" с условием "Статус = Завершенная". Он закрывает переход в статус "Завершенная" из любого статуса.

Два сценария в данном случае нужны для того чтобы вернуть задачу обратно именно в тот статус который был до выбора статусы Завершенная (я специально обратил внимание на ситуацию когда в завершенные можно перескочить из разных статусов. Если бы в была возможность выполнить действие Изменить статус = Предыдущий стату, то можно было бы обойтись одним сценарием.
Для себя уже решил что в о всех новых процессах (а на текущем проекте и старые подкоррективал) всегда буду методически прописывать обязательное использование четкой цепочки "Выполненная" -> Завершенная. Уже натолкнулся на сложность в оценки даты точки достижения конечного результата/цели задачи, что усложняет отчеты (приходится ветвить условия и проверять несколько параметров вместо одного).

[Сергей Голубев]

Поддерживаю и исходную идею общих полей для всех шаблонов и идею наследования (правда, не ясно, насколько она осуществима).

Так со всеми проблемами, перечисленными Ильей сталкивался.