Переменные в задачах

Мы выпустили переменные в задачах, которые много кому обещали. Работает круто, мы довольны

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

ПланФикс: Список переменных, доступных для использования в шаблоне задач
При создании задачи по шаблону, вместо переменной подставится ее текущее значение — и задача получит уникальное название или описание. Давайте сразу перейдем к примерам, они в данном случае все расскажут больше, чем долгие объяснения.

Нужен номер входящей заявки, которым удобно будет оперировать вам и клиенту? В шаблоне задачи добавляем в название переменную, содержащую ее номер:

Добавление автоматического номера заявки в шаблон задачи ПланФикса
и получаем желаемое автоматически для каждой новой заявки, создаваемой по этому шаблону — хоть вручную, хоть по почте:

Автоматический номер заявки клиента в ПланФиксе
Удобно использовать короткое название проекта в названиях всех его задач? Сделаем в проекте поле “Шифр проекта” и вставим переменную, которая ему соответствует, в шаблон каждой типовой задачи проекта:

ПланФикс: Добавляем в название задачи короткое обозначение проекта
Теперь вы всегда будете видеть, к какому проекту относится задача — к тому же, типовые задачи перестанут быть “близнецами”:

ПланФикс: задачи с коротким обозначением проекта в названии
Делаете ежемесячные отчеты? Добавьте в шаблоны периодических задач поле, содержащее название предыдущего месяца:

ПланФикс: добавление месяца в название задачи
и получите говорящие названия задач, которыми будет гораздо удобнее оперировать:

ПлоанФикс: отчеты по месяцам, автоматически сформированные названия повторяющихся задач
Ну что, вы уже придумали как можно использовать переменные в вашем аккаунте? Если еще нет — загляните в список доступных переменных в любом шаблоне задачи, он наведет вас на правильные мысли. Мы сразу постарались сделать его достаточно развернутым, например в нем есть:

  • почти 30 системных переменных, позволяющих отобразить в разных форматах время, дату, день недели, месяц и год;
  • все переменные, относящиеся к задаче, включая переменные для каждого созданного вами кастомного поля;
  • переменные для каждого реквизита любого справочника, который используется в полях задачи;
  • все переменные, относящиеся к проекту, в котором создается задача — включая, опять же, созданные вами поля проекта;
  • все переменные, относящиеся к контрагенту задачи — то есть, вы вполне можете включать в название и описание задачи любые данные из карточки клиента;
  • все переменные, относящиеся к надзадаче текущей задачи, включая данные из карточки ее контрагента или используемых в ней справочников.

Напоследок хочу проговорить два важных момента:

  1. Замена переменной на конкретное значение происходит однократно, в момент создания задачи по шаблону. Соответственно, в моем примере про краткое название проекта не стоит ожидать, что если в будущем вы поменяете значение в поле “Шифр проекта”, то у всех существующих задач оно изменится — любые изменения окажут влияние только на те задачи, которые будут создаваться после.
  2. Если задача по шаблону создается в статусе «Черновик», то переменные в ней не заменяются. Замена произойдет только в момент перевода задачи в один из рабочих статусов — например, «Новая». Это сделано на случай, если данные задачи будут изменяться в процессе нахождения ее в черновике — чтобы в итоге переменные заменились уже итоговыми данными, а не промежуточным вариантом.

Вроде бы все написал, ничего не забыл. Ну разве что еще правильным будет сказать, что переменные в задачах доступны только в платных и премиум-аккаунтах, владельцы бесплатных аккаунтов воспользоваться новыми благами цивилизации не смогут. А вот в течение пробного периода переменные работают — так что протестировать их работу может каждый.

Дмитрий Гончаренко Команда ПланФикса

 

В общем, пробуйте, проверяйте и пишите нам, что хотелось бы добавить в переменные или что работает не так, как вы ожидаете. Будем улучшаться и расти дальше 🙂

35 Comments

    1. Дмитрий Гончаренко

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

  1. 1. Обнаружила проблему с переменными при переименовании кастомных полей.
    Сценарий:
    1) создаем кастомное поле «Шифр проекта».
    2) Привязываем к шаблонам задач переменную.
    3) Создаем задачу. Всё ок. Задачи создаются с использованием переменной.
    4) Переименовываем поле «Шифр проекта» в «Шифр клиента».
    5) Смотрим в перечень переменных.
    Все ок: видим переменную с таким же именем, как и переименованное кастомное поле.
    6) Создаем новую задачу. Задача создается некорректно, поскольку в поле по-прежнему указано предыдущее наименование переменной (которое было до переименования кастомного поля)

    7) Смотрим в шаблоны задач, к которым была привязана переменная до переименования кастомного поля.
    Видим, что во всех шаблонах задач по-прежнему указана переменная с предыдущим наименованием (уже не существующим).

    Т.е. мы поменяли наименование кастомного поля, а переменная, при этом, автоматом не переняла это обновление (вероятно, старая переменная была удалена, новая создана).

    В результате этого, для того, чтобы после переименования кастомного поля работало корректно — нужно наново проставлять переменную во все шаблоны задач, которые использовали переменную до момента переименования кастомного поля.

    2. А можно реализовать, чтобы, при создании новой задачи (с использованием переменной) сразу подтягивалось само значение переменной в поле?

    Сейчас это происходит после сохранения задачи, а в момент создания видим поле (не расширяемое по мере ввода символов), в котором крупным шрифтом, проставлено {{Какая-то очень-очень длинная переменная}}, а само название поля в поле уже не поместилось и нужно прокручивать, чтобы его прочитать.

    1. Дмитрий Гончаренко

      1. Так как переменная, добавленная в тему или описание задачи, это просто текст, то мы не заменяем ее другим текстом в случае изменения поля — слишком уж много может быть всяких нюансов.
      Так что тут только руками, как Вы и написали. Глобальный поиск поможет найти все места, где встречается старая переменная.

      2. Мы думали над этим в самом начале, но пришли к тому, что это существенно снижает количество переменных, которые можно использовать, так как многие появляются или уточняются только в момент создания задачи. Например, номер задаче присваивается в момент создания (сохранения), а не в момент вызова формы. Точное время создание — тоже.

      Ну и любое значение любого реквизита задачи, как стандартного, так и кастомного, может быть изменено уже после вызова формы создания задачи, непосредственно в процессе заполнения данных, соответственно отображаться будет не то. А отлавливать любое изменение поля и тут же перерисовывать значения переменных в этой же форме достаточно накладно, и в разработке, и в последующей работе (будет притормаживать форма, некомфортно).

      Насчет длинных названий переменных посмотрим, если будут серийные жалобы на них — придумаем что-то, чтобы их маскировать.

      1. Дмитрий, спасибо за оперативный ответ!
        Да, вот то, что это «просто текст» немного настораживает. Мне ок, но коллегам, которые просто создают задачи по шаблонам, пока объясняю в формате «Не трогайте вот то, что в фигурных скобочках» 🙂
        За сам функционал большое спасибо, был нужен 🙂

        1. Дмитрий Гончаренко

          Рад помочь)
          Поделитесь опытом через некоторое время — если будут повторяющиеся проблемы, значит надо что-то менять.

  2. Спасибо!

    Что если обновление поля содержащего переменные привязать к сценариям?
    Пример. Наименование задачи содержит наименование контрагента, указанного в задаче. Создали задачу. Контрагента не заполнили. В определенный момент заполнили контрагента. Срабатывает сценарий по обновлению наименования задачи.

    1. Дмитрий Гончаренко

      Так не получится, Андрей — после создания задачи, переменных в ней не остается, соответственно изменять нечего.

    1. Дмитрий Гончаренко

      Добавлю: я в тексте старался оставлять ссылки на справочные статьи, которые помогут сделать то, о чем пишет Михаил.

  3. Подскажите, пожалуйста, как организовать автоинкрементный счётчик в названии задачи?

    Работаем на стыке двух систем (планфикс и сервис рассылок), задачи и всю подготовку ведём в планфиксе.
    Все рассылки упорядочены по номерам, это очень упрощает ориентирование среди них.

    Сейчас название автоматической задачи на еженедельную рассылку выглядит так: «Рассылка №», исполнитель каждый раз заходит в задачу и меняет название, например на «Рассылка №23».
    Использовать в данном случае «Шифр» (номер задачи из планфикса) не удобно, так как они четырехзначные и не предсказуемые, из-за этого будет сложно ориентироваться, какая рассылка была перед какой.

    Возможным решением была бы переменная «Задача.Количество подзадач 1-го уровня».
    Или более универсальное решение с использованием текущего значения переменной и шага инкремента в справочнике. Создание новой задачи по шаблону будет изменять текущее значение переменной в справочнике на величину шага, заданного там же.

    1. Дмитрий Гончаренко

      На текущий момент есть решение для фиксированного шага инкремента +1:
      — делаем кастомное поле числового типа с автоинкрементом;
      — используем переменную, соответствующую этому полю, в названии задачи;
      — инициализируем поле текущим значением номера рассылки, добавляя его в первую созданную задачу вручную.

      Должно работать.

  4. Для украинского и английского сегмента пользователей ПФ использование переменных осложняется тем, что, если нужно создавать задачи/файлы, с использованием переменных на украинском/английском — нужно переходить на соответствующий интерфейс системы.

    Укр- и и англ интерфейсы в бета-версии.
    Английский, может, получше, а укр такой, что без слез нельзя пользовать, помесь языков 🙁

    До сих пор использовали русскую версию ПФ.

    Но для генерирования файлов счетов, допустим, нужно обязательно системные укр-переменные (указание месяцев на укр), которые «подтягиваются» только если задача/файл генерируются в укр-интерфейсе.

    Сами системные укр-переменные ок, без ошибок, но интерфейс… просто плачу над ним 🙁

    А совместить использование русского интерфейса с применением укр-системных переменных нет возможности.

    От переменных отказаться не готовы никак. Мы их ждали.

    Пока придумали только условный «хак»: одного пользователя перевести на укр-интерфейс и создавать задачи с файлами по шаблонам с переменными от его имени, чтобы в файлы подтягивались укр-переменные, а далее задачи отправлялись уже другим пользователям, работающим в русском интерфейсе.

    Но неудобно и неизвестно, не будет ли попутно возникать дополнительных проблем с созданием автоповторяющихся задач.

    Спасите, помогите 🙂

    Какой вообще процент укр- и англ-пользователей ПФ, если не секретная информация?

  5. Не подойдет. В документы (счета, акты и т.д) нужно вставлять переменные не на английском, есть стандарты. Для укр-документации все должно быть на украинском.
    Причем решение использовать в датах формат «01/07/2016» не везде допустим, часто требуется указывать именно название месяцев в именительном и родительном падежах.

    Хорошо бы, если бы была опция выбора использования системных переменных: рус, укр, англ.
    Желательно даже дифференцировано при создании шаблонов документов/задач… или хотя бы единократная настройка для аккаунта.

    1. Дмитрий Гончаренко

      Думаю, нужно делать настройку на уровне шаблона. Действительно, вполне нормальной является ситуация, когда сотрудник использует один язык интерфейса, а документы должен генерировать на другом (требования государства, корпоративных стандартов и т.п.) Обсудим этот вариант в команде.

      P.S. Это, конечно, не снимает необходимости с нашей стороны плотнее взяться за приведение к норме украинской версии интерфейса. Сложность в том, что функционал появляется новый быстрее, чем мы добираемся до перевода — а так как основной язык разработки русский, все интерфейсные элементы по умолчанию реализуются на нем, отсюда и ядерная смесь при переключении на другие языки. Но это наши организационные проблемы, которые мы должны решать самостоятельно.

  6. Подскажите плиз,
    Есть последовательная задача, необходимо выводить на всех под-задачах описание корневой задачи. В шаблонах под-задач вставляю {{Задача.Описание задачи}}, но ничего не выводится

    1. Дмитрий Гончаренко

      Можно. Создайте системное поле (Управление аккаунтом / Настраиваемые поля / Системные поля) — и для него автоматически появится переменная, которая всегда будет отдавать настроенное вами значение.

Добавить комментарий