Gemini Community Support Site

This Gemini community support site can be used to find solutions to product issues. You can log in using Open Id, Google Profile and even Facebook. Feel free to ask a question or browse FAQs and documentation. Product tour videos are also available along with how-to videos demonstrating key Gemini capabilities.




Gemini Workflow question

web-app

I know that there is a way to limit who may edit/modify an issue and set the Outgoing Transition, but I can't see how to limit who can be assigned the issue on the Outgoing Transition.

For example, in our workflow, an issue may be created as a bug. In that case it is moved to a state called “Issue Verification” with is performed by our Testing Group. From Issue Verification, the issue may go down any one of 3 paths: Confirmed for fix More info required (from original reporter) Declined/Non-issue For each of the above states a different set of people are possible resources The problem is that the list of people that can be assigned to each state is the same (essentially everyone who can be assigned for any state is available, even when they are inappropriate for that state).

It seems to me that if a valid Outgoing Transition (Status) is selected, then the list of available resources ("Assigned To") should change to reflect only those who are members of the Groups that have been identified in the associated Issue Workflow Status.

Am I missing something?
Sean
· 1 		Sean
Thursday, February 25, 2010, 4:53:15 PM
Replies (4)
helpful
0
not helpful

Makes sense Sean.

This issue is around complexity...

Workflows can be shared across multiple projects. Yet every project may have different resources.

Hence management overhead surfaces, whereby, you have to potentially vary "target resources" for every outgoing transition, per project.

Thoughts?
Harvey Kandola
· 212 		Harvey Kandola
Thursday, February 25, 2010, 5:02:59 PM
helpful
0
not helpful

If the site uses Project Groups, then, the membership of the group would (could) "automagically" vary based on which users are assigned to that project group. For example, if I have 3 dev projects (D1, D2, D3) and 6 developers, then they could be to each project as appropriate. Then, if I have an issue in D1, the developer list that would be presented would be based on the members of the DevTeam assigned to the D1 DevTeam Project Group. It also means, that as I add / remove individuals from a Project Group, the list of available resources should update to reflect those changes.
Sean
· 1 		Sean
Thursday, February 25, 2010, 5:15:52 PM
helpful
0
not helpful

Feel free to add this to our list: http://gemini.countersoft.com/default.aspx?GEM
Mark Wing
· 9108 		Mark Wing
Friday, February 26, 2010, 9:19:36 AM
helpful
0
not helpful

It's actually fairly important to us - we're trying to roll this out to 80 people across our Support/Testing/Development teams, and getting the right person at the right state is critical to making sure that an issue flows smoothly.

Done. http://gemini.countersoft.com/Default.aspx?p=2&i=3675

Cheers
Sean
· 1 		Sean
Friday, February 26, 2010, 3:08:10 PM