| Summary: | sort jira versions shown in the task editor in reversed order | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Eugene Kuleshov <ekuleshov> |
| Component: | Mylyn | Assignee: | Jacek Jaroczynski <jacek.jaroczynski> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | jacek.jaroczynski, thomas.ehrnhoefer |
| Version: | unspecified | ||
| Target Milestone: | 3.3 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Eugene Kuleshov
It looks like the JIRA web interface applies a reverse sorting for versions as well, listing unreleased versions first. Created attachment 145754 [details]
show versions in reverse order like JIRA does
Simple patch to reverse version list. It is sorted in descending order using 'sequence' field defined in JIRA project configuration.
JIRA uses a little bit more sophisticated way to present versions. It divides them into 'released' and 'unreleased' groups and then sorts by 'sequence'. However adding 'released' and 'unreleased' groups to the multiselect combo and make them not selectable is quite tricky so this patch just adds simple reverse sorting.
Repository needs to be refreshed to store correctly sorted versions in the cache. Looks good Jacek, in the TaskEditor as well as the query dialog. I did stumble upon a small issue: I set up my workspace without the patch, had two tasks, one I opened and then closed the workspace. Applied the patch and reopened. As expected, the opened task had old sorted attribute. I opened a query dialog, hit update. The dialog had the new sorting. I canaceled the query dialog and opened the other task (which I had not opened before), and it still had the old sorting. I opened the query dialog again, still had the new sorting, hit update nevertheless. Then going back to one of the (still opened) tasks, hit syrnchronize, and it got the new sorting. I suspect that this behaviour is due to 277254: use a single JiraClient instance per repository https://bugs.eclipse.org/bugs/show_bug.cgi?id=277254 , but I am not totally certain. Maybe you could play around with a scenario similar to what I described above and check if the behaviour is ok or in any way inconsistent to what should happen. I am not sure if we should rely in the configuration being updated to make the new sorting, especially since the update itself is not necessary. On the other hand, it is a good sport there, since it only has to be done once, not for every call when the data is received for each presentation. And a preference if the sorting was done already seems overkill for this feature, so I am tending towards the current solution being sufficient. Also, please provide a test case for the correct sorting. Thanks for the patch Jacek! It would be nice if the sorting was handled in the UI but Mylyn does not currently have a good abstraction to hook a sorter into all places where versions are presented so the proposed solution seems to be the best way to go. I have applied the patch. It would be great if you could include contexts when submitting patches in the future it makes reviewing the changes easier. Created attachment 145858 [details]
mylyn/context/zip
I chose this place for sorting to ensure this is done only once and available in all places as this order will be used in most cases. I had similar issue to the one Thomas described. The solution would be to move sorting to the UI but it is more complicated to inject such code there and it would call sorting every time the version list is displayed. I will add test case for the sorting. I will include context next time. Created attachment 145920 [details]
Show versions in reverse order like JIRA does with TEST
Created attachment 145921 [details]
show versions in reverse order like JIRA does with TESTS CONTEXT
|