Support Forum

[SchAndrew]

В соответствии с п. 3.1. Implementation Guide необходимо последовательно выполнять шаги по созданию новой конфигурации.
Создание workflow до создания catrgories не создаст далее проблем?
Workflow нужно создавать для root folder, созданного в п.4?

[admin]

В соответствии с п. 3.1. Implementation Guide необходимо последовательно выполнять шаги по созданию новой конфигурации.
Создание workflow до создания catrgories не создаст далее проблем?

Нет, при создании категории ее нужно сразу связывать с workflow, т.е. workflow уже должно быть.
Хотя можно создать категорию с произвольным workflow, потом создать workflow, потом изменить настройки категории.

Workflow нужно создавать для root folder, созданного в п.4?

Можно для любого таска, но workflow будет доступна только этого таска и для подзадач этого таска.

Посмотрите flash tutorial, там процесс показан в деталях.

[SchAndrew]

Нет, при создании категории ее нужно сразу связывать с workflow, т.е. workflow уже должно быть.
Хотя можно создать категорию с произвольным workflow, потом создать workflow, потом изменить настройки категории.

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

Можно для любого таска, но workflow будет доступна только этого таска и для подзадач этого таска.

Когда создаешь проект(задачу), сразу нужно указать категорию. Потом уже поменять категорию нельзя, так ведь?
Собственно вопросы относились скорее к методологии, чем к технике.
Создав дерево проектов/подпроектов, потом его чрезвычайно трудно перестроить. А сразу точно понять, как его строить, не всегда получается.
Из небольшого опыта. Дерево проектов "рисовалось" исходя из поставщиков ПО.
В итоге оказалось невозможным для конкретного программного продукта ограничит список входящих в него модулей.
Теперь понимаю, что дерево нужно рисовать более "развесистое" - поставщик + продукт.

Посмотрите flash tutorial, там процесс показан в деталях.

Процесс то показан, но прежде чем его повторять, нужно "в голову" думать

[admin]

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

ИМХО не стоит, лишние потом всегда можно создать.

Когда создаешь проект(задачу), сразу нужно указать категорию. Потом уже поменять категорию нельзя, так ведь?

Да, так.

Собственно вопросы относились скорее к методологии, чем к технике.
Создав дерево проектов/подпроектов, потом его чрезвычайно трудно перестроить. А сразу точно понять, как его строить, не всегда получается.
Из небольшого опыта. Дерево проектов "рисовалось" исходя из поставщиков ПО.
В итоге оказалось невозможным для конкретного программного продукта ограничит список входящих в него модулей.
Теперь понимаю, что дерево нужно рисовать более "развесистое" - поставщик + продукт.

...

Процесс то показан, но прежде чем его повторять, нужно "в голову" думать

Да, все примерно так и есть.

[SchAndrew]

Да, все примерно так и есть.

Начинаем думать в "голову".

Строим дерево задач
Projects
|
+--Компания
|
+-- Внутренние проекты
|
+--- Внешние проекты

Компания имеет категорию Folder, т.к. других на момент выполнения шага 4 раздела Implementation Guide еще нет.
Подзадачи Внутренние проекты и Внешние проекты имеют свои категории. Как сделать так, чтобы одни пользователи видели только подзадачу Внешние проекты задачи Компания, а другие - только Внутренние проекты?

[admin]

Да, все примерно так и есть.

Начинаем думать в "голову".

Строим дерево задач
Projects
|
+--Компания
|
+-- Внутренние проекты
|
+--- Внешние проекты

Компания имеет категорию Folder, т.к. других на момент выполнения шага 4 раздела Implementation Guide еще нет.
Подзадачи Внутренние проекты и Внешние проекты имеют свои категории. Как сделать так, чтобы одни пользователи видели только подзадачу Внешние проекты задачи Компания, а другие - только Внутренние проекты?

Нужно создать Access Control Rules для внутренних и внешних проектов.

[SchAndrew]

Нужно создать Access Control Rules для внутренних и внешних проектов.

Понятно, что задействуем механизм правил доступа. Но если не давать ВСЕМ пользователям доступ к задаче Компания, а дать уровнем ниже, они смогут "провалиться" через задачу Компания?

[admin]

Нужно создать Access Control Rules для внутренних и внешних проектов.

Понятно, что задействуем механизм правил доступа. Но если не давать ВСЕМ пользователям доступ к задаче Компания, а дать уровнем ниже, они смогут "провалиться" через задачу Компания?

Да. Попробуйте

[SchAndrew]

Да. Попробуйте

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

[admin]

Да. Попробуйте

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

Отродясь было