Hi all,
I have the following use case:
We have a field called Ticket priority with the values A, B and C. When a ticket is created, the standard value is C.
We have a structure with 3 folders - A, B and C.
I want to add all the tickets to the folder C automatically (kind of a backlog). The users can then move the ticket to the folder A or B - based on their priorisation.
So they move the ticket manually and then they change the value in the field to A or B afterwards.
Long story short - A and B folders are managed manually, C is filled automatically. The order /kind of rank) of the issues in the folders should also be done manually.
It is not possible to insert issues to folder C, I receive the famous message "You are about to create a generator. It will be impossible to add it to the structure because of the automation installed: Cannot add generators to dynamic content. You can drag-and-drop the item to a different location.".
The original request was: "when I move the issue to the folder A, the value in the field Ticket priority changes automatically to A" - but this is another story :-) First I need to get all the tickets to the C folders.
Any advices or hints?
Thank you all!
Regards
Radim
Hi David,
thanks for your swift response.
This was my first idea but I think if I group the the issues by the field Ticket priority I will not be able to add additional rules later. Folders allow that because of separate automation rules on the folder level.
Anyway - I will discuss this with the requester whether any additional behaviour within A,B and C priority is to be expected. If not, I will suggest grouping.
Thanks again
Regards
Radim
Hi David,
the customer finds this idea good, but we are facing some funny thing:
The setup:
Any hint what we are doing wrong?
Thanks
Regards
Radim
Hello @Radim Drinka BS ,
Glad to hear the customer likes the idea!
From your screenshot, I can see the hand icon next to RAMS-388. This indicates that the issue was moved here through Manual Adjustments.
Manually adjusted issues ignore generators and can be placed anywhere in the structure arbitrarily, which is why you see it under the wrong group.
You can Undo Manual Adjustments by moving the issue back to its original position, or by disabling them for the entire structure.
I would recommend disabling them for the structure. Since you are now grouping by a field, you can move issues between groups to change the value for the field. If the customer is also looking to move issues up and down the hierarchy within the group, I would recommend using a Sort by Rank generator.
Please let me know if this helps!
Best Regards,
David
Hi David,
thanks for the response.
The thing is - the tickets have an A, B or a C category. Hence the groups (originally folders). The entire structure is a kind of a priorisation tool - the customer needs to order the tickets according to their internal ranking.
So - the have the most important tickets within category A downt to the lowest importance within category A. The same for B and C.
Do I understand it correctly, that this is not feasible? If not, I would need a solution as described originally in this post :-)
Thanks
Regards
Radim
Hello @Radim Drinka BS ,
You are very welcome.
The goal is 100% feasible using Structure. What I am suggesting is that the use of Folders and Manual Adjustments is not the best approach for this specific goal.
To accomplish your goal, you will want to use a Group Generator (which you have done) and a Sort Generator (specifically sort by rank).
With the approach I am suggesting, you can move issues between your A,B,C priority groups and also have the ability to move issues up and down within those groups, think of it as A1, A2, A3, B1, B2, etc. Sort by Rank uses the Jira rank, which means that it will be reflected in Jira Boards and other structures that are using a Sort by Rank Generator.
Folders and Manual Adjustments are very powerful tools and have their benefits, but not for your use case.
I would advise turning manual adjustments off for this structure. These cause the issues that have been manually adjusted to ignore the structure rules defined by the generators.
Hope this helps clarify!
Best,
David
Hi David,
now I understand the approach - silly me :-)
I made the changes as suggested and the ticket "B has moved from the C group to the B group. I was also able to reorder the tickets.
I will update the customer so that he can make the user acceptance test. I will inform you afterwards.
Many thanks
Cheers
Radim
Hi David,
we have created a ticket ("C" is a standard value after creation) and the structure inserted the ticket as "duplicate":
The setup is as proposed.
What can be the reason?
Thanks
Cheers
Radim
Hello @Radim Drinka BS ,
From the screenshot, I can see that Manual Adjustments are still enabled for your structure. Please follow the steps for Undoing Manual Adjustments to correct the duplication.
Best Regards,
David
Hi David,
we have tested it with the customer and - this is the solution we need :-)
Thanks for your great support!
Cheers
Radim
So glad to hear it, Radim! You are very welcome!!
Best,
David
Hi David,
we still have one issue. There is a role in Jira and users in this role have the edit and schedule issue permission - so they shoud be able to change the rank. However - they can´t reorder the items in the structure. What can be the cause for this?
Thanks
Radim
Hello @Radim Drinka ,
Does the user have Edit access in the Structure Permissions?
You will be able to check this by selecting the Configure Option from the Manage Structures page.
Also, it would be worth checking that the Sort Generator has the "Allow Changes via Structure" option enabled.
Please let me know if this helps.
Best Regards,
David
Hi David,
here are two screenshots that should address your points:
Thanks
Cheers
Radim
Hello @Radim Drinka ,
Thank you for the screen captures! The first one may offer the cause.
The way Structure Permissions work is that the lowest permission on the list takes precedence.
It may be that the user who is unable to reorder by rank is part of more than one group. Since the View permissions are at the bottom of the list, this user would only be able to View the structure.
We generally recommend putting the lowest level permissions at the top of the Permission list and the highest level permissions at the bottom. This ensures that users who are part of more than one group have the higher level set of permissions.
Please try reordering the permission levels and let me know if it helps!
Best,
David
Hi David,
after rearranging the permissions the ranking seems to work.
Thanks!!!
Cheers
Radim
You are very welcome, @Radim Drinka ! Glad to hear it was the solution!!
Hi David,
the users in the role have confirmed in the mean time that everything is working now.
Lessons learned: read all the details in the documentation :-)
Cheers
Radim