How can I sort a filter by sprint name, not ID?

[Esther Strom]

A user just asked me why she can't sort her filters by sprint name. I don't really work with sprints much as an admin, so I tried, and it turns out that when you sort by sprint, it's sorting by the sprint ID, not the name.

So this team has a number of sprints, all named the same way: Spartan Sprint 1, Spartan Sprint 2, etc. They were not actually created in the order they're numbered, though, and that's apparently a problem. 

When I mouse over the Sprint field of a ticket in Spartan Sprint 8, the URL shows the sprint ID as 1089; doing the same thing on a ticket in Spartan Sprint 3 shows 1092. So if we try to sort a filter by sprint, issues in Sprint 8 are displaying before issues in Sprint 3. 

How can a filter be sorted by sprint name, so the issues in the filter display in the actual sprint order, not the order the sprints were created in?

[Earl McCutcheon]

Hello @Esther Strom ,

Sorting by the request type name directly is not possible and we have the following feature request for server and cloud respectively to add this functionality in, I recomend adding a vote to help influence the priority as covered in the "Implementation of New Features Policy" :

• https://jira.atlassian.com/browse/JRACLOUD-61894
• https://jira.atlassian.com/browse/JRASERVER-61894

However, I would recomend against using the Sprint to order the issue as there are a couple complexities in the field type that make it difficult to get consistent sorting outcomes.

First Sprints do not necessary have unique names, so any Sprints can be configured with the same name of an existing one, so you could have several sprints all called "sprint 1" created at different times.  The only way to avoid this conflict is to use clearly defined naming conventions and create the sprints in order that matches the naming, and in following this process the ID would match the naming order because of the order of sprint creation order aligning to the name.

The second point is that an issue can exist in multiple sprints, so many sprint values could exist for a single issue, in the sorting option the first sprint an issue was in will be the placement for the sort over the most recent sprint.  To get around this it would require removing issues from preexisting sprints before adding them to new sprints, with the drawback of altering reporting and affecting velocity for accurate future spring planning.

Taking an alternate approach of using the Sprint field to reduce the issues returned like "sprint in (add list of sprints to narrow the results)" or a "Sprint in openSprints()" then doing a ORDER BY on a value like the due date or rank, and then if using duedates aligning the duedates with the most recent sprint would allow alternate and more accurate sorting operation.

Regards,
Earl