Добавить в свойства задачи шаблон для подзадач по умолчанию
Желательно, наследуемый
При создании большого количества однотипных подзадач неудобно каждый раз выбирать шаблон из списка.
Их может быть много и шаблоны могут отличаться, например, списком исполнителей и участников.
Я, например, вспоминаю про шаблон к задаче, когда половину полей заполнил. А другие, вообще про шаблон к конкретной задаче могут не знать и не использовать его.
Ну и до кучи добавить в свойства задачи вот это: http://forum.planfix.ru/viewtopic.php?f ... 1%82%D1%8C
Добавлено спустя 17 часов 36 минут 49 секунд:
Хочу добавить, что уровня проекта для назначения шаблонов недостаточно
Прикреплять к задаче шаблон для подзадач
-
- Сообщения: 344
- Зарегистрирован: 16.07.2012 19:37
-
- Сообщения: 4133
- Зарегистрирован: 06.06.2012 13:54
Шаблон для подзадач по умолчанию в принципе можно реализовать - есть достаточно нативное место, где его можно выбирать (вкладка "Подзадачи" в карточке задачи, есть достаточно понятный кейс использования этого функционала. Добавлю задачу по этому поводу, зафиксируем, чтобы не затерялось.
Ссылка на комментарий, поэтому хочу уточнить: имеете в виду само первоначальное предложение в этой теме, т.е. справочник и аналитику по умолчанию?Ну и до кучи добавить в свойства задачи вот это: http://forum.planfix.ru/viewtopic.php?f ... 1%82%D1%8C
-
- Сообщения: 344
- Зарегистрирован: 16.07.2012 19:37
-
- Сообщения: 4133
- Зарегистрирован: 06.06.2012 13:54
-
- Сообщения: 344
- Зарегистрирован: 16.07.2012 19:37
да, для аналитики, прикрепляемой к задаче, решается.
Добавлено спустя 13 минут 1 секунду:
а можно сделать, чтобы кроме прикрепленных к задаче аналитик, другие не были бы видны при выборе в комментарии?
Добавлено спустя 2 часа 17 минут 44 секунды:
т.е. по аналогии с файлами проекта: чтобы можно было ограничивать область видимости
например, при выборе аналитики, справочника и т.п. было 2 пункта в выпадающем списке: "аналитики для задачи" и "все аналитики"
это сильно ограничит в выборе, и как следствие, упростит типовые операции.
а наследование ускорит создание задач.
Добавлено спустя 13 минут 1 секунду:
а можно сделать, чтобы кроме прикрепленных к задаче аналитик, другие не были бы видны при выборе в комментарии?
Добавлено спустя 2 часа 17 минут 44 секунды:
т.е. по аналогии с файлами проекта: чтобы можно было ограничивать область видимости
например, при выборе аналитики, справочника и т.п. было 2 пункта в выпадающем списке: "аналитики для задачи" и "все аналитики"
это сильно ограничит в выборе, и как следствие, упростит типовые операции.
а наследование ускорит создание задач.
-
- Сообщения: 4133
- Зарегистрирован: 06.06.2012 13:54
Можно сделать все, вопросы обычно возникают такие:
- Скольким людям это нужно?
- Насколько это усложнит интерфейс?
От ответа на эти вопросы зависит быть или не быть изменению.
В данном случае мне кажется что интерфейс придется усложнять достаточно ощутимо, а новых запросов на подобные ограничения мы пока не получали, поэтому пока с включением этой доделки в планы мы не торопимся.
- Скольким людям это нужно?
- Насколько это усложнит интерфейс?
От ответа на эти вопросы зависит быть или не быть изменению.
В данном случае мне кажется что интерфейс придется усложнять достаточно ощутимо, а новых запросов на подобные ограничения мы пока не получали, поэтому пока с включением этой доделки в планы мы не торопимся.
-
- Сообщения: 344
- Зарегистрирован: 16.07.2012 19:37
- это нужно всем, но они пока этого не осознают. Это интуитивно понятно и значительно ускоряет работу.
- интерфейс не усложнится, поскольку во вкладке "проект" уже присутствует (для шаблонов)
Для меня непонятно вообще, почему проект и задача должны быть разными с точки зрения интерфейса и настроек. Проект это суперзадача. У пользователей просто разные подходы к декомпозиции:
кто-то делает много маленьких проектов
кто-то делает один большой проект, в котором много задач
- интерфейс не усложнится, поскольку во вкладке "проект" уже присутствует (для шаблонов)
Для меня непонятно вообще, почему проект и задача должны быть разными с точки зрения интерфейса и настроек. Проект это суперзадача. У пользователей просто разные подходы к декомпозиции:
кто-то делает много маленьких проектов
кто-то делает один большой проект, в котором много задач
-
- Сообщения: 4133
- Зарегистрирован: 06.06.2012 13:54
Ну, нельзя сравнивать шаблоны задач с ограничением видимости справочников или аналитик - это все же очень разные по сути вещи.
С этим могу согласиться лишь частично. Я понимаю, что можно считать это одной сущностью, но есть плюсы и минусы в обоих подходах. Пока мы видим больше плюсов в том, чтобы проект был отдельной сущностью, если увидим, что плюсов в объединении больше - объединим, нам не привыкать.Для меня непонятно вообще, почему проект и задача должны быть разными с точки зрения интерфейса и настроек. Проект это суперзадача.
-
- Сообщения: 344
- Зарегистрирован: 16.07.2012 19:37
почему разные?
есть область видимости для элементов управления - очень удобная вещь, на самом деле.
представьте, что у вас все файлы в корне диска находятся.
практически все люди пользуются директориями, т.е. по доброй воле искусственно ограничивают область видимости
и радуются этому, что характерно
Добавлено спустя 13 минут 1 секунду:
разделяя проект и задачу вы как-бы предлагаете свой подход к декомпозиции: "делайте проекты небольшими"
у нас, например, текущий проект, в котором 103 задачи (это не закончен первый этап, а всего их четыре)
там и конструкторские задачи и финансовые и управление.
вот, например, менеджер сейчас отправляет заявки на контрактное производство.
он делает шаблон и создает подзадачи по нему, выискивая каждый раз из кучи других
потом передает задачу другому менеджеру, тот про шаблон ничего не знает - в общем, неудобно
есть область видимости для элементов управления - очень удобная вещь, на самом деле.
представьте, что у вас все файлы в корне диска находятся.
практически все люди пользуются директориями, т.е. по доброй воле искусственно ограничивают область видимости
и радуются этому, что характерно
Добавлено спустя 13 минут 1 секунду:
разделяя проект и задачу вы как-бы предлагаете свой подход к декомпозиции: "делайте проекты небольшими"
у нас, например, текущий проект, в котором 103 задачи (это не закончен первый этап, а всего их четыре)
там и конструкторские задачи и финансовые и управление.
вот, например, менеджер сейчас отправляет заявки на контрактное производство.
он делает шаблон и создает подзадачи по нему, выискивая каждый раз из кучи других
потом передает задачу другому менеджеру, тот про шаблон ничего не знает - в общем, неудобно
-
- Сообщения: 4133
- Зарегистрирован: 06.06.2012 13:54
Не совсем корректный пример, на мой взгляд. Если использовать аналогию с файлами, то она выглядела бы так: Вы просили бы возможность на уровне папки ограничивать типы файлов, которые могут в ней находиться - в этой только картинки, тут вордовские документы, а тут эксель и ppt. При этом я, конечно, могу придумать кому и для чего такой функционал может понадобиться - но основную массу пользователей он сбивал бы с толку самим фактом своего присутствия, т.к. непонятно зачем такие ограничения нужны.почему разные?
есть область видимости для элементов управления - очень удобная вещь, на самом деле.
представьте, что у вас все файлы в корне диска находятся.
практически все люди пользуются директориями, т.е. по доброй воле искусственно ограничивают область видимости
и радуются этому, что характерно
Почему? Ведь есть деревья задач любой вложенности - это позволяет при необходимости выстраивать структуру с ограниченным количеством задач на каждом уровне, которыми относительно удобно манипулировать.разделяя проект и задачу вы как-бы предлагаете свой подход к декомпозиции: "делайте проекты небольшими"
у нас, например, текущий проект, в котором 103 задачи (это не закончен первый этап, а всего их четыре)
там и конструкторские задачи и финансовые и управление.
Этот пример я не до конца понял.вот, например, менеджер сейчас отправляет заявки на контрактное производство.
он делает шаблон и создает подзадачи по нему, выискивая каждый раз из кучи других
потом передает задачу другому менеджеру, тот про шаблон ничего не знает - в общем, неудобно
-
- Сообщения: 344
- Зарегистрирован: 16.07.2012 19:37
Области видимости - все равно к этому придете в том или ином виде. Лучше заранее обдумать интуитивно понятную модель, единую для всех сущностей, иначе получится как со списками задач - я так и не понял, почему они трех видов, постоянно путаюсь.
Нужны шаблоны для групп задач.
эти группы задач можно оформить в виде отдельного проекта - например: "проект поиск контрактного производителя корпуса, или SMD монтажа" (кстати, участники форума - пишите, если что). При этом документы для обмена документацией придется брать из других проектов - например, "разработка корпуса" - там своя группа исполнителей/участников и т.п. по умолчанию. Ну и так для каждой группы задач придется делать отдельный проект. Не вижу плюсов в этом никаких.
Т.е. существует конфликт:
Методика передачи задачи реализована просто и понятно - сменил исполнителя и далее автоматом: исполнитель увидел среди задач новую и т.п.
Методики передачи шаблонов нет.
Вариант решения: вписывать вручную название шаблона в описании задачи, например.
Но это отстой, на мой взгляд, а на ваш?
Еще пример - у сотрудника (особенно руководителя) есть куча разных задач с разными шаблонами, держать их в голове достаточно тяжело, т.е. либо разделять на минипроекты (см.выше), либо шаблоны в половине случаев не используются.
Вариант решения: венгерской записью шаблоны называть, типа название проекта/задачи/шаблона и тогда сотрудник при создании подзадачи в первую очередь ищет в списке шаблонов.
Но это тоже отстой, на мой взгляд, а на ваш?
Очень просто: я могу шаблон по умолчанию сделать только для всего проекта. В рамках этого проекта в задачах разного типа (закупки, производство, разработка и т.п.) единый шаблон не используется.Почему? Ведь есть деревья задач любой вложенности - это позволяет при необходимости выстраивать структуру с ограниченным количеством задач на каждом уровне, которыми относительно удобно манипулировать.
Нужны шаблоны для групп задач.
эти группы задач можно оформить в виде отдельного проекта - например: "проект поиск контрактного производителя корпуса, или SMD монтажа" (кстати, участники форума - пишите, если что). При этом документы для обмена документацией придется брать из других проектов - например, "разработка корпуса" - там своя группа исполнителей/участников и т.п. по умолчанию. Ну и так для каждой группы задач придется делать отдельный проект. Не вижу плюсов в этом никаких.
Т.е. существует конфликт:
- обмен информацией предусматривает ограничение в виде проекта, т.е. проект должен включать все работы с этой информацией (быть большим).
- шаблоны задач можно сделать только на весь проект, т.е. проект должен содержать задачи только по этим шаблонам (быть маленьким)
Поясню: сотрудник создал задачу и шаблон для подзадач, передал другому. Тот создает подзадачи. Если у него есть шаблон - создает быстро. Если нет шаблона - создает долго и может ошибиться. Шаблон есть, но в списке среди других шаблонов.Этот пример я не до конца понял.
Методика передачи задачи реализована просто и понятно - сменил исполнителя и далее автоматом: исполнитель увидел среди задач новую и т.п.
Методики передачи шаблонов нет.
Вариант решения: вписывать вручную название шаблона в описании задачи, например.
Но это отстой, на мой взгляд, а на ваш?
Еще пример - у сотрудника (особенно руководителя) есть куча разных задач с разными шаблонами, держать их в голове достаточно тяжело, т.е. либо разделять на минипроекты (см.выше), либо шаблоны в половине случаев не используются.
Вариант решения: венгерской записью шаблоны называть, типа название проекта/задачи/шаблона и тогда сотрудник при создании подзадачи в первую очередь ищет в списке шаблонов.
Но это тоже отстой, на мой взгляд, а на ваш?
-
- Сообщения: 4133
- Зарегистрирован: 06.06.2012 13:54
Очень может быть. Но пока у меня в голове эта интуитивно понятная модель не сложилась.Области видимости - все равно к этому придете в том или ином виде. Лучше заранее обдумать интуитивно понятную модель, единую для всех сущностей, иначе получится как со списками задач - я так и не понял, почему они трех видов, постоянно путаюсь.
Вариант решения: вписывать вручную название шаблона в описании задачи, например.
Но это отстой, на мой взгляд, а на ваш?
На мой тоже - но мы с Вами уже договорились по шаблонам подзадач что их можно сделать, я по этому поводу добавил задачу в нашем аккаунте, стоит в очереди.Вариант решения: венгерской записью шаблоны называть, типа название проекта/задачи/шаблона и тогда сотрудник при создании подзадачи в первую очередь ищет в списке шаблонов.
Но это тоже отстой, на мой взгляд, а на ваш?
-
- Сообщения: 344
- Зарегистрирован: 16.07.2012 19:37
очень рад этому, надеюсь, простоит недолгоНа мой тоже - но мы с Вами уже договорились по шаблонам подзадач что их можно сделать, я по этому поводу добавил задачу в нашем аккаунте, стоит в очереди.
Полностью согласен с вами, что пока модель не сложилась, не стоит вносить изменения.Очень может быть. Но пока у меня в голове эта интуитивно понятная модель не сложилась.
Опыты на людях показывают, что при взаимодействии с продуктом у пользователей в мозгу складывается модель системы, даже если они не могут ее объяснить.
На мой взгляд, при проектировании системы очень важно спроектировать алгоритм так, чтобы модель, складывающаяся в мозгу на основе опыта, соответствовала модели, которую заложил программист.
Отрицательный пример - MS Word. Очень много возможностей по просьбам пользователей, но еще не встречал гуру, который может объяснить автоматическую расстановку нумерованных списков и стилей. В итоге: юристы и бухгалтеры повсеместно используют форматирование пробелами.
Добавлено спустя 17 часов 53 минуты 26 секунд:
Предлагаю на рассмотрение вариант:
(специально объясняю так, как объяснял бы своему бухгалтеру)
- Объекты информации (аналитики, справочники, отчеты) хранятся в общей БД, доступ к просмотру содержимого БД возможен через соответствующие кнопки (уже реализовано).
- В этих БД они лежат в едином хранилище, как книги в библиотеке. То что мы видим в ПФ - ссылки на эти объекты, как карточки в библиотечном каталоге. Находим карточку, отдаем библиотекарю - он приносит книгу. т.е. Нажимаем на ссылку - отправляем ссылку в БД, которая открывает файл.
- Искать среди карточек, которые все лежат в одном ящике, неудобно. Поэтому ссылки на объекты могут быть рассортированы по группам как карточки в библиотечных каталожных ящиках (уже реализовано).
- Объекты могут иметь ссылки в нескольких группах (уже реализовано для файлов). Книга может иметь несколько карточек в разных каталожных ящиках, чтобы ее можно было найти разным поиском - шкафы по авторам, по темам, по ключевым словам и т.п.
- При удалении ссылки на объект (карточки из каталога), в случае, если в других группах нет ссылок на него, объект тоже удаляется (книга списывается, если ее карточки нет ни в одном каталоге, все равно ее уже не найти). Или переходит в группу "Корзина" с ограниченным временем хранения (книга помещается в ящик "на списание", который очищается раз в неделю).
- Доступ из задачи возможен только к разрешенным объектам или группам (уже реализовано для файлов на уровне проекта). Для каждого проекта создается отдельный каталожный ящик, в котором хранятся карточки используемых книг.
- можно сделать то же самое для справочников и аналитик, т.е. автоматически создавать группу с именем проекта, в которую можно будет копировать ссылки и целые группы.
- При создании задачи автоматически создается группа, которая наследует группы и объекты из надзадачи. Т.е. в каталожном ящике могут быть помеченные коробки с карточками, в них другие коробки (вообще-то, обычно бухгалтеры представляют, что такое каталоги и файлы). Допустим, мы хотим найти карточку и примерно помним, где она была. Тогда мы сначала смотрим в той коробке, где помним. Если не нашли - смотрим в той коробке, в которой стояла первоначальная коробка (во всей коробке, включая все внутри) и т.п.
- Т.е. принцип такой: из задачи видны все объекты в ней и ее подзадачах (как сейчас можно посмотреть файлы).
- Из задачи можно перемещаться вверх по дереву задач, при этом становятся видно все больше объектов.
- Таким образом вводится понятие - уровень видимости. Можно задавать его по умолчанию в свойствах задачи для каждого типа объектов. Он может быть абсолютным (например, имя надзадачи), чтобы можно было его наследовать в шаблонах и подзадачах. Может быть уровнем текущей задачи, тогда наследуется уровень новой задачи.
- можно область видимости прямо вручную указывать при выборе объекта, например в выпадающем списке показывать путь по дереву
Есть и обратная задача - объекты, которые должны быть везде видны.
- Можно опять же сделать глобальные группы на уровне проекта или даже выше и прямо указывать на эти группы в проекте или задаче. Так уже сделано для групп пользователей.
Еще хочу отметить, что группы объектов должны иметь такой же интерфейс, как и объекты. Это сделано, например, для прав доступа для групп пользователей.
Для других объектов (аналитики, отчеты, справочники) тоже неплохо было бы сделать управление группами
-
- Сообщения: 4133
- Зарегистрирован: 06.06.2012 13:54
-
- Сообщения: 344
- Зарегистрирован: 16.07.2012 19:37
-
- Сообщения: 4133
- Зарегистрирован: 06.06.2012 13:54
-
- Сообщения: 344
- Зарегистрирован: 16.07.2012 19:37
-
- Сообщения: 10
- Зарегистрирован: 20.06.2015 13:18
Поясните, пожалуйста, сейчас у меня в проекте указан шаблон по умолчания ШаблонА, есть задача 1 в проекте с этим ШаблономА. У этой задачи 1 есть несколько чеклистов. Когда я преобразую чеклист в подзадачу - эта новая подзадача создается с шаблоном "Стандартный шаблон". Можно как-то сделать, чтобы она создавалась с шаблоном ШаблонА?
-
- Сообщения: 465
- Зарегистрирован: 23.05.2013 21:46
Я бы вообще убрал сущность чек-листы, а создавал сразу все подзадачами, пусть и без сроков... В чек листе нельзя "отписаться" — добавить комментарий, а это всегда в любом случае понадобится, у пункта чек-листа всего 2 статуса (есть и нет) и этот набор статусов нельзя поменять...Поясните, пожалуйста, сейчас у меня в проекте указан шаблон по умолчания ШаблонА, есть задача 1 в проекте с этим ШаблономА. У этой задачи 1 есть несколько чеклистов. Когда я преобразую чеклист в подзадачу - эта новая подзадача создается с шаблоном "Стандартный шаблон". Можно как-то сделать, чтобы она создавалась с шаблоном ШаблонА?
Добавлено спустя 8 минут 44 секунды:
Согласен с высказыванием. Я уже пол года собираюсь с мыслями, чтобы сесть и прочитать наконец чем задача отличается от проекта и не могу сделать над собой такого усилия, потому что мне вполне хватает просто задач с подзадачами. Дайте какую то киллер фичу проектов которой нет у задач, чтобы мне их захотелось использовать... Иначе не вижу в них надобности...Для меня непонятно вообще, почему проект и задача должны быть разными с точки зрения интерфейса и настроек. Проект это суперзадача. У пользователей просто разные подходы к декомпозиции:
Добавлено спустя 16 минут 37 секунд:
По чек листам вообще ведь почти ничего делать не надо: некий простой пользователь как делал списки чек-листов, так и будет делать, только они сразу будут подзадачами со ссылками для более детального разбирательства. Не хочет он более детально, ну и не надо. А продвинутому пользователю не надо будет каждый раз жать как минимум 2 кнопки чтобы превратить чужой чек-лист в подзадачу.
-
- Сообщения: 4133
- Зарегистрирован: 06.06.2012 13:54
Пока нет, но скоро мы сделаем такое поведение для системы по умолчанию.Поясните, пожалуйста, сейчас у меня в проекте указан шаблон по умолчания ШаблонА, есть задача 1 в проекте с этим ШаблономА. У этой задачи 1 есть несколько чеклистов. Когда я преобразую чеклист в подзадачу - эта новая подзадача создается с шаблоном "Стандартный шаблон". Можно как-то сделать, чтобы она создавалась с шаблоном ШаблонА?
-
- Сообщения: 262
- Зарегистрирован: 16.12.2015 16:50
-
- Сообщения: 39
- Зарегистрирован: 18.10.2022 09:32
Re: Прикреплять к задаче шаблон для подзадач
На КИП2023 был вопрос, почему при удалении из задачи файла, указанного по ссылке, он удаляется из папки ДОКУМЕНТЫ, в которой был первоначально размещен
Кажется, я нашел ответ на этот вопрос в этом обсуждении:
Поэтому имеет смысл добавить условие:
Если файл добавлен через ДОКУМЕНТЫ, поставить флаг "в документах"
Если файл удален из задачи, то проверить флаг "в документах", если флаг отсутствует, то проверить ссылки и удалить, если ссылок нет.
Если файл удален из ДОКУМЕНТЫ, то снять флаг "в документах", проверить ссылки и удалить, если ссылок нет.
Кажется, я нашел ответ на этот вопрос в этом обсуждении:
Тут не был предусмотрен случай, когда файл размещается не через задачу, а сразу в папку ДОКУМЕНТЫ.5. При удалении ссылки на объект (карточки из каталога), в случае, если в других группах нет ссылок на него, объект тоже удаляется (книга списывается, если ее карточки нет ни в одном каталоге, все равно ее уже не найти). Или переходит в группу "Корзина" с ограниченным временем хранения (книга помещается в ящик "на списание", который очищается раз в неделю).
Поэтому имеет смысл добавить условие:
Если файл добавлен через ДОКУМЕНТЫ, поставить флаг "в документах"
Если файл удален из задачи, то проверить флаг "в документах", если флаг отсутствует, то проверить ссылки и удалить, если ссылок нет.
Если файл удален из ДОКУМЕНТЫ, то снять флаг "в документах", проверить ссылки и удалить, если ссылок нет.