Мы выпустили переменные в задачах, которые много кому обещали. Работает круто, мы довольны
Добавить переменные можно в любой шаблон задачи. Когда вы создаете или редактируете шаблон, подсказка с полным списком доступных переменных находится под рукой:
При создании задачи по шаблону, вместо переменной подставится ее текущее значение – и задача получит уникальное название или описание. Давайте сразу перейдем к примерам, они в данном случае все расскажут больше, чем долгие объяснения.
Нужен номер входящей заявки, которым удобно будет оперировать вам и клиенту? В шаблоне задачи добавляем в название переменную, содержащую ее номер:
и получаем желаемое автоматически для каждой новой заявки, создаваемой по этому шаблону – хоть вручную, хоть по почте:
Удобно использовать короткое название проекта в названиях всех его задач? Сделаем в проекте поле “Шифр проекта” и вставим переменную, которая ему соответствует, в шаблон каждой типовой задачи проекта:
Теперь вы всегда будете видеть, к какому проекту относится задача – к тому же, типовые задачи перестанут быть “близнецами”:
Делаете ежемесячные отчеты? Добавьте в шаблоны периодических задач поле, содержащее название предыдущего месяца:
и получите говорящие названия задач, которыми будет гораздо удобнее оперировать:
Ну что, вы уже придумали как можно использовать переменные в вашем аккаунте? Если еще нет – загляните в список доступных переменных в любом шаблоне задачи, он наведет вас на правильные мысли. Мы сразу постарались сделать его достаточно развернутым, например в нем есть:
- почти 30 системных переменных, позволяющих отобразить в разных форматах время, дату, день недели, месяц и год;
- все переменные, относящиеся к задаче, включая переменные для каждого созданного вами кастомного поля;
- переменные для каждого реквизита любого справочника, который используется в полях задачи;
- все переменные, относящиеся к проекту, в котором создается задача – включая, опять же, созданные вами поля проекта;
- все переменные, относящиеся к контрагенту задачи – то есть, вы вполне можете включать в название и описание задачи любые данные из карточки клиента;
- все переменные, относящиеся к надзадаче текущей задачи, включая данные из карточки ее контрагента или используемых в ней справочников.
Напоследок хочу проговорить два важных момента:
- Замена переменной на конкретное значение происходит однократно, в момент создания задачи по шаблону. Соответственно, в моем примере про краткое название проекта не стоит ожидать, что если в будущем вы поменяете значение в поле “Шифр проекта”, то у всех существующих задач оно изменится – любые изменения окажут влияние только на те задачи, которые будут создаваться после.
- Если задача по шаблону создается в статусе “Черновик”, то переменные в ней не заменяются. Замена произойдет только в момент перевода задачи в один из рабочих статусов – например, “Новая”. Это сделано на случай, если данные задачи будут изменяться в процессе нахождения ее в черновике – чтобы в итоге переменные заменились уже итоговыми данными, а не промежуточным вариантом.
Вроде бы все написал, ничего не забыл. Ну разве что еще правильным будет сказать, что переменные в задачах доступны только в платных и премиум-аккаунтах, владельцы бесплатных аккаунтов воспользоваться новыми благами цивилизации не смогут. А вот в течение пробного периода переменные работают – так что протестировать их работу может каждый.
Дмитрий Гончаренко Команда ПланФикса
В общем, пробуйте, проверяйте и пишите нам, что хотелось бы добавить в переменные или что работает не так, как вы ожидаете. Будем улучшаться и расти дальше 🙂
Красавцы! Спасибо, ждали этот функционал)
Спасибо! Очень полезное обновление 🙂
Прекрасно!
Теперь ждем триггеры
Тригеры приобрели официальное название Автоматические сценарии, так что они уже выпущены.
Вчера заметил, сразу применил. Очень полезно! Спасибо!
А будет ли это работать в Напоминаниях и задачах-чек-листах внутри задачи?
Теоретически это возможно, но достаточно много работы. Пока не планировали этого делать, но если будут регулярные запросы – запланируем и сделаем.
1. Обнаружила проблему с переменными при переименовании кастомных полей.
Сценарий:
1) создаем кастомное поле “Шифр проекта”.
2) Привязываем к шаблонам задач переменную.
3) Создаем задачу. Всё ок. Задачи создаются с использованием переменной.
4) Переименовываем поле “Шифр проекта” в “Шифр клиента”.
5) Смотрим в перечень переменных.
Все ок: видим переменную с таким же именем, как и переименованное кастомное поле.
6) Создаем новую задачу. Задача создается некорректно, поскольку в поле по-прежнему указано предыдущее наименование переменной (которое было до переименования кастомного поля)
7) Смотрим в шаблоны задач, к которым была привязана переменная до переименования кастомного поля.
Видим, что во всех шаблонах задач по-прежнему указана переменная с предыдущим наименованием (уже не существующим).
Т.е. мы поменяли наименование кастомного поля, а переменная, при этом, автоматом не переняла это обновление (вероятно, старая переменная была удалена, новая создана).
В результате этого, для того, чтобы после переименования кастомного поля работало корректно — нужно наново проставлять переменную во все шаблоны задач, которые использовали переменную до момента переименования кастомного поля.
2. А можно реализовать, чтобы, при создании новой задачи (с использованием переменной) сразу подтягивалось само значение переменной в поле?
Сейчас это происходит после сохранения задачи, а в момент создания видим поле (не расширяемое по мере ввода символов), в котором крупным шрифтом, проставлено {{Какая-то очень-очень длинная переменная}}, а само название поля в поле уже не поместилось и нужно прокручивать, чтобы его прочитать.
1. Так как переменная, добавленная в тему или описание задачи, это просто текст, то мы не заменяем ее другим текстом в случае изменения поля – слишком уж много может быть всяких нюансов.
Так что тут только руками, как Вы и написали. Глобальный поиск поможет найти все места, где встречается старая переменная.
2. Мы думали над этим в самом начале, но пришли к тому, что это существенно снижает количество переменных, которые можно использовать, так как многие появляются или уточняются только в момент создания задачи. Например, номер задаче присваивается в момент создания (сохранения), а не в момент вызова формы. Точное время создание – тоже.
Ну и любое значение любого реквизита задачи, как стандартного, так и кастомного, может быть изменено уже после вызова формы создания задачи, непосредственно в процессе заполнения данных, соответственно отображаться будет не то. А отлавливать любое изменение поля и тут же перерисовывать значения переменных в этой же форме достаточно накладно, и в разработке, и в последующей работе (будет притормаживать форма, некомфортно).
Насчет длинных названий переменных посмотрим, если будут серийные жалобы на них – придумаем что-то, чтобы их маскировать.
Дмитрий, спасибо за оперативный ответ!
Да, вот то, что это “просто текст” немного настораживает. Мне ок, но коллегам, которые просто создают задачи по шаблонам, пока объясняю в формате “Не трогайте вот то, что в фигурных скобочках” 🙂
За сам функционал большое спасибо, был нужен 🙂
Рад помочь)
Поделитесь опытом через некоторое время – если будут повторяющиеся проблемы, значит надо что-то менять.
Спасибо!
Что если обновление поля содержащего переменные привязать к сценариям?
Пример. Наименование задачи содержит наименование контрагента, указанного в задаче. Создали задачу. Контрагента не заполнили. В определенный момент заполнили контрагента. Срабатывает сценарий по обновлению наименования задачи.
Так не получится, Андрей – после создания задачи, переменных в ней не остается, соответственно изменять нечего.
А где взять шифр проекта или задачи. В предложенных опциях нет шифров
Сделать самостоятельно такое поле в проекте и заполнить его, а потом использовать в шаблонах задач.
Добавлю: я в тексте старался оставлять ссылки на справочные статьи, которые помогут сделать то, о чем пишет Михаил.
Ссылки почему-то серым выделены, они плохо видны в тексте. Текст черный, ссылки чуть чуть светлее. Сливаются, может быть поэтому их не замечают?
Возможно. Понаблюдаем за этим.
Ура, большое спасибо!
А в документации будет информация по переменным в задачах?
Хотелось бы для каждой переменной, кроме тех, конечно, которые относятся к кастомным полям увидеть описание.
А по каким есть непонимание, что они означают?
Например:
Системные.месяц.текущий.
Там далее 3 варианта. Не пробуя создать задачу с каждым не могу определить, что каждый значит.
Понял, спасибо.
Подскажите, пожалуйста, как организовать автоинкрементный счётчик в названии задачи?
Работаем на стыке двух систем (планфикс и сервис рассылок), задачи и всю подготовку ведём в планфиксе.
Все рассылки упорядочены по номерам, это очень упрощает ориентирование среди них.
Сейчас название автоматической задачи на еженедельную рассылку выглядит так: “Рассылка №”, исполнитель каждый раз заходит в задачу и меняет название, например на “Рассылка №23”.
Использовать в данном случае “Шифр” (номер задачи из планфикса) не удобно, так как они четырехзначные и не предсказуемые, из-за этого будет сложно ориентироваться, какая рассылка была перед какой.
Возможным решением была бы переменная “Задача.Количество подзадач 1-го уровня”.
Или более универсальное решение с использованием текущего значения переменной и шага инкремента в справочнике. Создание новой задачи по шаблону будет изменять текущее значение переменной в справочнике на величину шага, заданного там же.
На текущий момент есть решение для фиксированного шага инкремента +1:
– делаем кастомное поле числового типа с автоинкрементом;
– используем переменную, соответствующую этому полю, в названии задачи;
– инициализируем поле текущим значением номера рассылки, добавляя его в первую созданную задачу вручную.
Должно работать.
Огромное спасибо!
Буду пробовать.
Для украинского и английского сегмента пользователей ПФ использование переменных осложняется тем, что, если нужно создавать задачи/файлы, с использованием переменных на украинском/английском — нужно переходить на соответствующий интерфейс системы.
Укр- и и англ интерфейсы в бета-версии.
Английский, может, получше, а укр такой, что без слез нельзя пользовать, помесь языков 🙁
До сих пор использовали русскую версию ПФ.
Но для генерирования файлов счетов, допустим, нужно обязательно системные укр-переменные (указание месяцев на укр), которые “подтягиваются” только если задача/файл генерируются в укр-интерфейсе.
Сами системные укр-переменные ок, без ошибок, но интерфейс… просто плачу над ним 🙁
А совместить использование русского интерфейса с применением укр-системных переменных нет возможности.
От переменных отказаться не готовы никак. Мы их ждали.
Пока придумали только условный “хак”: одного пользователя перевести на укр-интерфейс и создавать задачи с файлами по шаблонам с переменными от его имени, чтобы в файлы подтягивались укр-переменные, а далее задачи отправлялись уже другим пользователям, работающим в русском интерфейсе.
Но неудобно и неизвестно, не будет ли попутно возникать дополнительных проблем с созданием автоповторяющихся задач.
Спасите, помогите 🙂
Какой вообще процент укр- и англ-пользователей ПФ, если не секретная информация?
Может быть стоит сделать переменные на Английском по умолчанию?
Хотя тут опять же сразу возникнут тонкости перевода.
Не подойдет. В документы (счета, акты и т.д) нужно вставлять переменные не на английском, есть стандарты. Для укр-документации все должно быть на украинском.
Причем решение использовать в датах формат “01/07/2016” не везде допустим, часто требуется указывать именно название месяцев в именительном и родительном падежах.
Хорошо бы, если бы была опция выбора использования системных переменных: рус, укр, англ.
Желательно даже дифференцировано при создании шаблонов документов/задач… или хотя бы единократная настройка для аккаунта.
Думаю, нужно делать настройку на уровне шаблона. Действительно, вполне нормальной является ситуация, когда сотрудник использует один язык интерфейса, а документы должен генерировать на другом (требования государства, корпоративных стандартов и т.п.) Обсудим этот вариант в команде.
P.S. Это, конечно, не снимает необходимости с нашей стороны плотнее взяться за приведение к норме украинской версии интерфейса. Сложность в том, что функционал появляется новый быстрее, чем мы добираемся до перевода – а так как основной язык разработки русский, все интерфейсные элементы по умолчанию реализуются на нем, отсюда и ядерная смесь при переключении на другие языки. Но это наши организационные проблемы, которые мы должны решать самостоятельно.
Сделали выбор языка на уровне шаблона, проверьте пожалуйста, решаются ли сейчас все вопросы?
Подскажите плиз,
Есть последовательная задача, необходимо выводить на всех под-задачах описание корневой задачи. В шаблонах под-задач вставляю {{Задача.Описание задачи}}, но ничего не выводится
Если описание нужно из надзадачи, то следует использовать переменную {{Задача.Надзадача.Описание задачи}}
Нельзя ли создать свою собственную переменную со своим собственным текстовым полем статичным? Чтобы потом например использовать в POST запросах
Можно. Создайте системное поле (Управление аккаунтом / Настраиваемые поля / Системные поля) – и для него автоматически появится переменная, которая всегда будет отдавать настроенное вами значение.
Добрый день!
Переменные нельзя будет использовать в пользовательских полях? Например создали поле регистрационный номер для договоров и писем, и хотелось бы чтобы рег. номер состоял из порядкого номера и префикса например “Исх”, “У/22”, “КП”. Порядковый номер берем из поля счетчик задачи.
Здравствуйте, Александр!
Заполнить пользовательское поле можно при помощи сценария. В сценариях есть операция “Вычислить значение поля”, она поможет: