Форум сервиса Планфикс

Добавить в свойства задачи шаблон для подзадач по умолчанию
Желательно, наследуемый

При создании большого количества однотипных подзадач неудобно каждый раз выбирать шаблон из списка.
Их может быть много и шаблоны могут отличаться, например, списком исполнителей и участников.

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

Ну и до кучи добавить в свойства задачи вот это: http://forum.planfix.ru/viewtopic.php?f ... 1%82%D1%8C

Добавлено спустя 17 часов 36 минут 49 секунд:
Хочу добавить, что уровня проекта для назначения шаблонов недостаточно

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

Ну и до кучи добавить в свойства задачи вот это: http://forum.planfix.ru/viewtopic.php?f ... 1%82%D1%8C

Ссылка на комментарий, поэтому хочу уточнить: имеете в виду само первоначальное предложение в этой теме, т.е. справочник и аналитику по умолчанию?

да, справочник и аналитику по умолчанию

хочу добавить, что в подзадачах при создании эти параметры по умолчанию должны наследоваться

Добавлено спустя 14 часов 26 минут 39 секунд:
Есть еще более нативное место: вкладка "Детали задачи"
тогда будет однообразно с проектом

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

А не решается эта ситуация, если аналитика будет прописана в шаблоне и станет добавляться автоматически при создании подзадачи?

да, для аналитики, прикрепляемой к задаче, решается.

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

Добавлено спустя 2 часа 17 минут 44 секунды:
т.е. по аналогии с файлами проекта: чтобы можно было ограничивать область видимости

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

это сильно ограничит в выборе, и как следствие, упростит типовые операции.
а наследование ускорит создание задач.

Можно сделать все, вопросы обычно возникают такие:
- Скольким людям это нужно?
- Насколько это усложнит интерфейс?

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

- это нужно всем, но они пока этого не осознают. Это интуитивно понятно и значительно ускоряет работу.
- интерфейс не усложнится, поскольку во вкладке "проект" уже присутствует (для шаблонов)

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

кто-то делает много маленьких проектов
кто-то делает один большой проект, в котором много задач

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

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

С этим могу согласиться лишь частично. Я понимаю, что можно считать это одной сущностью, но есть плюсы и минусы в обоих подходах. Пока мы видим больше плюсов в том, чтобы проект был отдельной сущностью, если увидим, что плюсов в объединении больше - объединим, нам не привыкать.
 

почему разные?
есть область видимости для элементов управления - очень удобная вещь, на самом деле.
представьте, что у вас все файлы в корне диска находятся.
практически все люди пользуются директориями, т.е. по доброй воле искусственно ограничивают область видимости
и радуются этому, что характерно

Добавлено спустя 13 минут 1 секунду:
разделяя проект и задачу вы как-бы предлагаете свой подход к декомпозиции: "делайте проекты небольшими"
у нас, например, текущий проект, в котором 103 задачи (это не закончен первый этап, а всего их четыре)
там и конструкторские задачи и финансовые и управление.

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

почему разные?
есть область видимости для элементов управления - очень удобная вещь, на самом деле.
представьте, что у вас все файлы в корне диска находятся.
практически все люди пользуются директориями, т.е. по доброй воле искусственно ограничивают область видимости
и радуются этому, что характерно

Не совсем корректный пример, на мой взгляд. Если использовать аналогию с файлами, то она выглядела бы так: Вы просили бы возможность на уровне папки ограничивать типы файлов, которые могут в ней находиться - в этой только картинки, тут вордовские документы, а тут эксель и ppt. При этом я, конечно, могу придумать кому и для чего такой функционал может понадобиться - но основную массу пользователей он сбивал бы с толку самим фактом своего присутствия, т.к. непонятно зачем такие ограничения нужны.

разделяя проект и задачу вы как-бы предлагаете свой подход к декомпозиции: "делайте проекты небольшими"
у нас, например, текущий проект, в котором 103 задачи (это не закончен первый этап, а всего их четыре)
там и конструкторские задачи и финансовые и управление.

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

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

Этот пример я не до конца понял.

 Области видимости - все равно к этому придете в том или ином виде. Лучше заранее обдумать интуитивно понятную модель, единую для всех сущностей, иначе получится как со списками задач - я так и не понял, почему они трех видов, постоянно путаюсь.

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

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

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

Если сделать хотя бы шаблоны на уровне задач и подзадач, то ими будет не относительно, а абсолютно удобно манипулировать.Даешь абсолютное удобство - вот наш девиз! 

Этот пример я не до конца понял.

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

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

Области видимости - все равно к этому придете в том или ином виде. Лучше заранее обдумать интуитивно понятную модель, единую для всех сущностей, иначе получится как со списками задач - я так и не понял, почему они трех видов, постоянно путаюсь.

Очень может быть. Но пока у меня в голове эта интуитивно понятная модель не сложилась.

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

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

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

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

очень рад этому, надеюсь, простоит недолго

Очень может быть. Но пока у меня в голове эта интуитивно понятная модель не сложилась.

Полностью согласен с вами, что пока модель не сложилась, не стоит вносить изменения.
Опыты на людях показывают, что при взаимодействии с продуктом у пользователей в мозгу складывается модель системы, даже если они не могут ее объяснить.
На мой взгляд, при проектировании системы очень важно спроектировать алгоритм так, чтобы модель, складывающаяся в мозгу на основе опыта, соответствовала модели, которую заложил программист.
Отрицательный пример - MS Word. Очень много возможностей по просьбам пользователей, но еще не встречал гуру, который может объяснить автоматическую расстановку нумерованных списков и стилей. В итоге: юристы и бухгалтеры повсеместно используют форматирование пробелами.

Добавлено спустя 17 часов 53 минуты 26 секунд:
Предлагаю на рассмотрение вариант:
(специально объясняю так, как объяснял бы своему бухгалтеру)

1. Объекты информации (аналитики, справочники, отчеты) хранятся в общей БД, доступ к просмотру содержимого БД возможен через соответствующие кнопки (уже реализовано).
2. В этих БД они лежат в едином хранилище, как книги в библиотеке. То что мы видим в ПФ - ссылки на эти объекты, как карточки в библиотечном каталоге. Находим карточку, отдаем библиотекарю - он приносит книгу. т.е. Нажимаем на ссылку - отправляем ссылку в БД, которая открывает файл.
3. Искать среди карточек, которые все лежат в одном ящике, неудобно. Поэтому ссылки на объекты могут быть рассортированы по группам как карточки в библиотечных каталожных ящиках (уже реализовано).
4. Объекты могут иметь ссылки в нескольких группах (уже реализовано для файлов). Книга может иметь несколько карточек в разных каталожных ящиках, чтобы ее можно было найти разным поиском - шкафы по авторам, по темам, по ключевым словам и т.п.
5. При удалении ссылки на объект (карточки из каталога), в случае, если в других группах нет ссылок на него, объект тоже удаляется (книга списывается, если ее карточки нет ни в одном каталоге, все равно ее уже не найти). Или переходит в группу "Корзина" с ограниченным временем хранения (книга помещается в ящик "на списание", который очищается раз в неделю).
6. Доступ из задачи возможен только к разрешенным объектам или группам (уже реализовано для файлов на уровне проекта). Для каждого проекта создается отдельный каталожный ящик, в котором хранятся карточки используемых книг.
   1. можно сделать то же самое для справочников и аналитик, т.е. автоматически создавать группу с именем проекта, в которую можно будет копировать ссылки и целые группы.
   2. При создании задачи автоматически создается группа, которая наследует группы и объекты из надзадачи. Т.е. в каталожном ящике могут быть помеченные коробки с карточками, в них другие коробки (вообще-то, обычно бухгалтеры представляют, что такое каталоги и файлы). Допустим, мы хотим найти карточку и примерно помним, где она была. Тогда мы сначала смотрим в той коробке, где помним. Если не нашли - смотрим в той коробке, в которой стояла первоначальная коробка (во всей коробке, включая все внутри) и т.п.
      1. Т.е. принцип такой: из задачи видны все объекты в ней и ее подзадачах (как сейчас можно посмотреть файлы).
      2. Из задачи можно перемещаться вверх по дереву задач, при этом становятся видно все больше объектов.
      3. Таким образом вводится понятие - уровень видимости. Можно задавать его по умолчанию в свойствах задачи для каждого типа объектов. Он может быть абсолютным (например, имя надзадачи), чтобы можно было его наследовать в шаблонах и подзадачах. Может быть уровнем текущей задачи, тогда наследуется уровень новой задачи.
      4. можно область видимости прямо вручную указывать при выборе объекта, например в выпадающем списке показывать путь по дереву

Это что касается ограничения видимости. В принципе, для файлов все примерно так и сделано.
Есть и обратная задача - объекты, которые должны быть везде видны.

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

Добавлено спустя 2 часа 12 минут 43 секунды:
Еще хочу отметить, что группы объектов должны иметь такой же интерфейс, как и объекты. Это сделано, например, для прав доступа для групп пользователей.
Для других объектов (аналитики, отчеты, справочники) тоже неплохо было бы сделать управление группами

Мне нравится как Вы мыслите, Тимур - в описанной модели есть стройность, этим она подкупает.
Не хочу обещать, что мы сделаем прямо так, как написано, но задуматься нас Вы заставили.
 

Спасибо. Оценил вашу дипломатичность

Да нет, тут не просто дипломатичность - это сухая констатация фактов :)

Работа накладывает отпечаток - проектирование встроенных систем с ограниченным HMI тренирует тщательное обдумывание.
В общем-то, ПланФикс был выбран из-за курса разработчиков на понятность модели.

Поясните, пожалуйста, сейчас у меня в проекте указан шаблон по умолчания ШаблонА, есть задача 1 в проекте с этим ШаблономА. У этой задачи 1 есть несколько чеклистов. Когда я преобразую чеклист в подзадачу - эта новая подзадача создается с шаблоном "Стандартный шаблон". Можно как-то сделать, чтобы она создавалась с шаблоном ШаблонА?

Поясните, пожалуйста, сейчас у меня в проекте указан шаблон по умолчания ШаблонА, есть задача 1 в проекте с этим ШаблономА. У этой задачи 1 есть несколько чеклистов. Когда я преобразую чеклист в подзадачу - эта новая подзадача создается с шаблоном "Стандартный шаблон". Можно как-то сделать, чтобы она создавалась с шаблоном ШаблонА?

Я бы вообще убрал сущность чек-листы, а создавал сразу все подзадачами, пусть и без сроков... В чек листе нельзя "отписаться" — добавить комментарий, а это всегда в любом случае понадобится, у пункта чек-листа всего 2 статуса (есть и нет) и этот набор статусов нельзя поменять...

Добавлено спустя 8 минут 44 секунды:

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

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

Добавлено спустя 16 минут 37 секунд:
По чек листам вообще ведь почти ничего делать не надо: некий простой пользователь как делал списки чек-листов, так и будет делать, только они сразу будут подзадачами со ссылками для более детального разбирательства. Не хочет он более детально, ну и не надо. А продвинутому пользователю не надо будет каждый раз жать как минимум 2 кнопки чтобы превратить чужой чек-лист в подзадачу.

 Поясните, пожалуйста, сейчас у меня в проекте указан шаблон по умолчания ШаблонА, есть задача 1 в проекте с этим ШаблономА. У этой задачи 1 есть несколько чеклистов. Когда я преобразую чеклист в подзадачу - эта новая подзадача создается с шаблоном "Стандартный шаблон". Можно как-то сделать, чтобы она создавалась с шаблоном ШаблонА?

Пока нет, но скоро мы сделаем такое поведение для системы по умолчанию.
 

прошу отметить как выполнено

На КИП2023 был вопрос, почему при удалении из задачи файла, указанного по ссылке, он удаляется из папки ДОКУМЕНТЫ, в которой был первоначально размещен

Кажется, я нашел ответ на этот вопрос в этом обсуждении:

5. При удалении ссылки на объект (карточки из каталога), в случае, если в других группах нет ссылок на него, объект тоже удаляется (книга списывается, если ее карточки нет ни в одном каталоге, все равно ее уже не найти). Или переходит в группу "Корзина" с ограниченным временем хранения (книга помещается в ящик "на списание", который очищается раз в неделю).

Тут не был предусмотрен случай, когда файл размещается не через задачу, а сразу в папку ДОКУМЕНТЫ.
Поэтому имеет смысл добавить условие:

Если файл добавлен через ДОКУМЕНТЫ, поставить флаг "в документах"
Если файл удален из задачи, то проверить флаг "в документах", если флаг отсутствует, то проверить ссылки и удалить, если ссылок нет.
Если файл удален из ДОКУМЕНТЫ, то снять флаг "в документах", проверить ссылки и удалить, если ссылок нет.