Support Forum

[SchAndrew]

В настройке процессов иметь возможность выдавать разрешения не только на сообщения, но и на состояния. Очень важно для реализации принципа - что НЕ положено видеть, то и НЕ видно.

Щавелев А.

[admin]

В настройке процессов иметь возможность выдавать разрешения не только на сообщения, но и на состояния. Очень важно для реализации принципа - что НЕ положено видеть, то и НЕ видно.

Щавелев А.

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

[SchAndrew]

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

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

[vadimk]

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

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

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

Право "Can Be Handler" не означает "может быть показан в списке обработчиков" на экране "Сообщение" (точка зрения системы), а должен означать, что человек может быть обработчиком в состоянии, куда сообщение переводит задачу (точка зрения процесса, для которого система используется). В этом втором сдучае право заданное для состояния имеет больший смысл и более натурально для пользователя и администратора, чем право, заданное для перехода. А поскольку оно более натурально, оно не добавляет, а сокращает сложность настройки.

[admin]

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

Право "Can Be Handler" не означает "может быть показан в списке обработчиков" на экране "Сообщение" (точка зрения системы), а должен означать, что человек может быть обработчиком в состоянии, куда сообщение переводит задачу (точка зрения процесса, для которого система используется). В этом втором сдучае право заданное для состояния имеет больший смысл и более натурально для пользователя и администратора, чем право, заданное для перехода. А поскольку оно более натурально, оно не добавляет, а сокращает сложность настройки.

Один момент - а что с правами на кастом-поля ? Мне кажется, что право редактировать номер билда при resolve - это более натурально, чем редактирование номера билда для любого message type, который переводит в состояние resolved.
Или, например, message type = reopen. Задание причин переоткрывания актуально именно для процесса переоткрывания, а не для любого message type, которые переводит задачу в состояние "in process".

Опять же, can view/can create/can delete для message type никуда не исчезнут, так ? Т.е. права на состояния будут не вместо прав на типы сообщений, а в дополнение к ним, что вряд ли упростит ситуацию.

[vadimk]

Солдасен с аргументом. Но ...

Речь идет об одном только праве - "Can be Handler".

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

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

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

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

[admin]

Мне в первую очередь не хочется делать еще одну страницу, где настраиваются какие-то permissions.

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

===
Никак не могу настроить программу

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

Yes, I was able to install TrackStudio and I watched half of the existing flash tutorials. I took nearly a whole day to explore the software together with the handbook.
...
In a way you fullfilled most of our "requirements" but when I tried to configure the software to adapt to our structure it sometimes felt like a nightmare. It took me very long and still I am not sure whether I found the correct way to give users access rights to enter issues for a project (in fact I did not find the right way because I could not enter an issue when I logged as that user).

I really like the design and thought of TrackStudio and I am more than willing and happy to give you a full overview of what we really need.
===

Если пользователь спрашивает - обычно решение проблемы находится очень быстро, но спрашивают немногие
Вроде и в документации все шаги описаны, и в inline help, и в tutorial процесс показан, но, видимо, есть в нем что-то чуждое простой человеческой логике

В следующей версии собираемся в настройках группы сделать закладки для просмотра/редактирования прав для _этой_ группы и всех категорий/message type/custom fields/etc. Надеюсь, это поможет.

Другая хорошая идея - выводить настройки permissions не матрицами, а правилами в духе:
[developer, tester] - [bug, project] - [can view, can edit]
[administrator] - [project] - [can delete]

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

[vadimk]

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

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

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

В следующей версии собираемся в настройках группы сделать закладки для просмотра/редактирования прав для _этой_ группы и всех категорий/message type/custom fields/etc. Надеюсь, это поможет.

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

[admin]

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

Да, видимо это появится в 4.0

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

Да, я понимаю. У нас сейчас есть несколько областей, где права хорошо бы расширить (еще пара примеров - видимость задачи в зависимости от ее состояния и права на фильтры). Технически это делается просто, останавливает необходимость делать доп. экраны с permissions. Если эту проблему получится решить - можно будет "наворачивать" security и дальше.

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

Я понимаю о чем Вы, будем думать. Пока с этим ничего не понятно.

Кстати, еще некоторые мысли по поводу следующей версии:

1) Собираемся редактирование всяких скриптов и e-mail templates убрать из web UI и сделать их просто файлами на диске. Для внешнего редактирования к ним будет доступ через WebDAV. Это должно несколько упростить редактирование и избавить от необходимости вручную менять всякие стандартные скрипты/шаблоны при апгрейде системы.

2) Собираемся сделать анонимный доступ к TrackStudio на основе templates. Т.е. это будет простенькая функциональность типа просмотра списка багов, добавления багов/сообщений без регистрации и с возможностью кастомизации экранов.

3) Собираемся радикально упростить e-mail templates.

[vadimk]

1. Скрипты на диске - неплохая идея. Возникает вопрос - когда они подцепляются (когда изменения становятся видны?)

2. Анонимный доступ - речь идет о UIшаблонах?

3. Пару слов в заключение дискуссии о правах. Часть проблеммы в том, что правами решаются две разные задачи:
* security - что кому разрешено
* UI behavior and workflow - когда какое поле может быть видно и какими значениями популировано
Отсюда много конфюзов, споров, сложностей в восприятии и пожеланий.
Напрммер в случае с полями в сообщении звучат оба вопроса:
- при релизе задачи (соответствующее сообщение) должно быть показано поле для ввода номера билда
- но это поле может редактировать только программист (тестер не может, так как он делает регрессион соотвествующего билда)
- это же поле при редактировании задачи может менять только менаджер