We are using Jira 6.1.4, Jira Agile 6.3.7 and Structure 2.6.0.
We structure our Feature work in Epics, and use a Label to identify Epics for a Release (aka. 'Release X')
Epic = larger container of 'work' which may include Bugs, Tasks or Stories
Story = smaller container of 'work' which may include Tasks or Sub-tasks
As we are planning for a Release, we label each Epic with the Release Label and as we are planning and making content and priority decisions, issues move in and out of the Epics during the course of planning, which can range from a few days to a couple weeks.
For our Release Structure, we have two synchronizers:
Filter synchronizer using JQL to query for Epics with the Label (aka. 'Release X')
Agile (GH) synchronizer using Synchronize Epics, and auto add sub-tasks
Both of these synchronizers are Enabled.
Given we have this planning period where things are moving around, every day we end up with a number of issues move to the top of the Structure that need to be manually deleted from the Structure. This is confusing and burdensome during this time period.
Is there any way to do this better? If an issue is moved out of an Epic that meets the filter criteria, and the issue itself doesn't meet the filter criteria, why does it stay at the top of the Structure?
I tried to change the Filter synchronizer to Remove but that ended up removing the Epic Link for every issue in every Epic (and several hours of manual updating to restore the Epic contents). I think this is something to do with the synchronizers not 'working well' together when automatically updating.
Hello Sive, before answering I'd like to figure out some details. If I understand correctly, you have a work breakdown structure, which you have described in the question, and release structure.
Could you please provide more details about release structure, how is it shaped and how are you using it? The problems, I understand, originally happen in the release structure (and when you have Epics synchronizer on it, it indeed may remove epic links as a response to a change in the release structure).
I hope I will be able to suggest a solution once I get the full picture.
For now, we are mainly trying to use our Release Structure for a hierarchical view of all the planned content, and for tracking progress against that content. At this time we are not trying to use the Structure for updating the issues (Rank, etc.), we are primarily using it for better viewing of the 'big picture' than we can otherwise get in JIRA. There are individual Scrum Masters leading Scrum Teams who are responsible for the features in the EPICs, and at times, those teams may move things IN or OUT of the EPICs, and when they move them OUT of the EPIC, that issue gets moved to the Top of the Structure, instead of just being moved OUT of the Structure.
I'm attaching a screenshot of the structure, as well as our Synchronizer settings. One thing I have not experimented is running the Synchronizers with a different userid that has no Issue Edit settings, would that help?
Ok, I got it now. It is the way Epic synchronization works now, by moving stories upwards past the epics, if the epic link is deleted.
I apologize for the incident when you lost epic links - I guess it happened when you added "remove" flag to the Filter synchronizer that adds Epics, right? Well, it removed everything that didn't match the filter, and stories obviously didn't match. This event was captured by the Agile / Epics synchronizer, which promptly removed the Epic Links in response to removal of the story.
I can suggest the following idea. Create another 3rd synchronizer - it will be a Filter synchronizer, responsible for removing stories that should no longer be there. It would work only in "Remove" mode, and the JQL should be carefully written to specify issues that are allowed to remain in the structure. Here's the draft suggestion:
Before enabling such synchronizer, check your JQL - if it gets the correct result. You can see the difference between the structure contents and JQL result using structure() function: issue in structure('structure name') AND NOT (your JQL) - those issues will be removed.
Hope this helps!
Hi Igor -
That helps a LOT with eliminating the incidents of incorrectly removing all issues from Epics, but I still cannot get it to work automatically, despite enabling that 3rd synchronizer. I see real-time updates from the other two synchronizers, but this one doesn't seem to be real-time, despite it being 'Enabled'. Is there a limit on # of enabled synchronizers?
The only way I can get it to remove them is to manually Resync. Any idea why this would be?
Hi Igor - I did some additional testing and the enabled 3rd synchronizer actually DOES remove issues from the top, but only when the Issue does not have Sub-tasks, eg. it is automatically removing Bugs, Ideas or Stories with no sub-tasks. So, there must just be some other tweak related to removing Issues w/ Sub-tasks, let me know if you think of anything.
( continuing )
This is rather complicated, what it basically says is that either the issue should be an Epic, or the issue should have a parent or itself satisfy a condition ("issue or descendant of..."), that it's a direct child of an epic ("child of [type = 'Epic']") and it has a non-empty Epic Link. More on S-JQL here: https://wiki.almworks.com/x/dIPE
Please test the JQL before applying!
Note that the JQL refers to the structure by ID (123 in the example) - you can look up structure ID when you open that structure from the Manage Structure page (look at the URL). One can use structure name there, but it's important to use the ID so this filter works even if someone renames the structure.
Hope this works for you!
Ah, ok, this explains it. When "enabled", a synchronizer does incremental check and it will only check the Story - since it has sub-issues, it's not deleted (it assumes that Sub-issues match the filter).
I think we'll need to resort to running Resync in this case. Resync is a manual operation, but we have a small add-on that runs resyncs on schedule, say, once in 5 minutes. This is not ideal, as you might have periods when there's extra issues in the release structure, but that's what I can think of for now. The add-on can be downloaded from here - https://wiki.almworks.com/x/y4J7(scheduled-sync-0.3), after installation JIRA administrator will have a menu Structure | Scheduled Sync. There's a short explanatory video here: http://www.youtube.com/watch?v=gQtj_Qtb3Dc
So with Scheduled Resync, you can actually Disable the removing synchronizer (so it doesn't react to events), and schedule "cleaning up" of the structure.
The JQL should be modified to reflect the fact that sub-issues of the story may not have the Epic Link set. For that, we'll need to use S-JQL and structure() function. I think this JQL should work (remember - it says which issues are allowed to remain):
type = 'Epic' OR issue in structure(123, "issue or descendant of (['Epic Link' is not EMPTY] AND child of [type = 'Epic'])")
Well, so much for that - I tried it on my real structure, and ended up that all the individual Issues w/out Sub-tasks (Ideas, Tasks, Bugs, Stories) had their Epic Links removed again, and only those Stories w/ Sub-tasks were untouched. And, the one issue that had been removed and moved to the Top was still at the top.
And now, 2.5 hours later, I've restored my 300+ Issues into their respective Epics. This is a real bummer.
I'd like to investigate creating a special User that can Create Structures and Install / Config Synchronizers, but not Edit Issues, any suggestions on how to do that?
Otherwise this Plugin is not looking like it's going to work for us, as much as we want it to :-(
Sive, I'm so sorry that this happened again. But I have to ask, did you test what the synchronizer is going to do in the way I suggested earlier? (With a JQL and using structure() function.) Was the result different from what happened later? If it was, we'll need to investigate this closer!
As I don't have direct access to your JIRA, I cannot tell you the precise parameters, you need to verify them. With Filter synchronizer, it's quite easy to test it before applying.
Also, check out this page: https://wiki.almworks.com/x/nQBg- there's "Undo Files" section at the end. If you lose information about Epics, that file can be used as the way to restore it. (Unfortunately, it's not automated yet.)
About the user that has no editing rights on issues: that seems to me a good idea. You can surely do that - check out your Permission Scheme in JIRA for the project, and make sure that this special user has no Edit Issue and Link Issue permissions. It should have Browse Project permission to read the issues. You will also need to create a special group for this user, so that you can give it permissions to modify the structure (structure permissions are assigned to groups).
Feel free to open support case at https://jira.almworks.comif you need further advice or if you need to post non-public information.
Hi Igor - yes, I did the test of the JQL, and it showed a bunch of sub-tasks, and when i removed those (thinking they were irrelevant) it came up with nothing, so I thought the Ideas and Bugs would be fine. I'll spend some time digesting your other suggestions here more and file a support ticket if further questions/comments. Thanks.
It started as any story starts, on a normal, rainy day. Admin meets App, and her name was Klok2, and like any first relationship we were both trying to make it work but neither one knew what...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs