Empty Backlog after Update to 6.1.3.1 Greenhopper (Tried all KB Steps)

[Thomas Jefferies]

After updating Greenhopper to the latest version (6.1.3.1 from 6.0.2), our Agile boards are showing zero issues in the backlog. I have completed all of the troubleshooting steps documented on the Atlassian KBs for this issue to test this, including the following:

* https://answers.atlassian.com/questions/43735/issues-not-showing-up-in-plan-view-of-rapid-board

* https://confluence.atlassian.com/display/GHKB/Empty+Backlog+Even+Though+Issue+Exist

* https://confluence.atlassian.com/display/ONDEMANDKB/Backlog+is+Empty+in+The+Scrum+Board

The custom field Sprint is enabled and not hidden, the context is global and not focused to specific projects, the search context is correct, the board's filter is not filtering the issues, and all statuses that are mapped to issues we expect to see in the backlog are properly associated in Greenhopper's configuration for the columns. I do not have an epic selected in the epic selector, so it should not be filtering the board at all.

Additionally, we had not been using the classic board, so our Epics are not eligible for the migration to the new board (though I checked that to make sure).

Beyond all that, everything worked swimmingly prior to the update this morning. We were previously on the 6.0.2 release. No changes were made to our configuration aside from the update of the GreenHopper plugin from 6.0.2 to 6.1.3.1.

Unfortunately due to this, we cannot create new sprints at present, and since Monday is normally the Sprint planning session, not only was it a bad time for me to have updated the plugin (in my defense, I never expected that a plugin update would impact key functionality to this level), and unfortunately there is no supported downgrade mechanism, so we're pretty much dead in the water at this point as far as Greenhopper is concerned until we can determine why the issues that show up properly in the issue navigator are not showing up in the backlog.

Users can still work because the issues are still viewable in JIRA, but it is quite a bit impact to productivity to have to manually filter to find the issues rather than pick from the SCRUM board.

It's worth mention that the currently running Sprint itself is showing properly and all issues associated with the sprint are showing -- it's just the backlog in Plan view that is completely empty now.

[Thomas Jefferies · Accepted solution]

I was able to figure out what the key difference was between 6.0.2 and 6.1.3.1, and how it related to our use of the product – the documentation was mostly correct in that our previous definition of Epic no longer aligned with GreenHopper's definition (which is the more proper) of Epic. What I had to do was add "Story" as an issue type for the project and insert it into the screen scheme / etc., take all of the "Epic" tickets that we had assigned subtasks to, move them to "Story" issue types, and then create Epics to group each of the Story issues into. This then populated the backlog and allowed the new functionality of associating backlogged and sprint items with Epics through the planning pane.

This was quite an undertaking for the number of epics we had open, but I was at least able to keep all of the data in the project without having to do too much work. The key problem was that I read the documentation for 6.1, and while it mentions the epic pane, it does not really detail the differences between Epics as they stood in 6.0.2 vs. epics as they stand in 6.1. It was partly my fault for not doing the due diligence required to read all of the release notes prior to upgrading, so I'll fall on the knife for that.

[Yilin]

I think this is kind of bug that we should look into it deeply, can you please create a support ticket ?

[Thomas Jefferies]

I also thought that this may be a problem because of the change in how Epics are handled from 6.0.6 onward, so I've tried creating a new board and creating a new epic on it in the same project to see if I can get anything to appear and seem to be having the same issue -- even creating a brand new epic doesn't seem to get the issues into the backlog properly. I tried adding "Story" as an allowable ticket type for the project and created one, attempted to do the same thing -- I just can't seem to get a single thing to show in the backlog, no matter what ticket type, no matter how it was created, no matter whether it is on this board or a brand new board, no matter what project it is in.

I'm hoping that the documentation I'm finding stating that there is no migration path from pre-6.0.6 to 6.0.6+ for epics is incorrect, we have over 150 of them that would have to be manually updated.

If that's the case, I think I'd rather just downgrade back to prior to 6.0.6...

[Timothy]

Tried a reindex yet?

[Thomas Jefferies]

Good suggestion, after muddling with it for 20 minutes this morning I thought that may be the issue, so I did kick off the re-index. It did not have any impact.

I'm not sure if this is important or not, but historically, we left the Sprint custom field out of the actual screens that people used to enter Epics and Technical Sub-tasks (not hidden, but not associated with the screen configuration, so the data was still there, just not shown or editable on the ticket edit screens directly). For the purposes of troubleshooting, I did go and add the field to each of the screens, and the field shows properly and includes content such as "37, 38, 40, 41". Doing this had no impact as well on whether or not the issues appear in the backlog.

[Thomas Jefferies]

Additionally, it may be worth mention that the Epics in question that do not show in the backlog DO show on the left side of the screen in the new Epics panel of Plan view, but the information associated is incorrect -- all show 0 total / completed issues, even though each issue has anywhere from 3 to 15 subtasks, some of which are completed. Selecting the epic on the left side does not provide any usable result, it still shows 0 issues in the backlog.

Also, I neglected to mention the outcome of the SQL queries as requested above in one of the KB articles -- we only have a single Sprint field, we have not made additional custom fields for this purpose. As such, there was only the single custom field ID and it was associated as the default, and it was being used by both the issues that properly appear in the sprint, and also by the issues that should be in the backlog.