Posted by intu.cz on September 21, 2007 at 1:01pm
4 followers
| Project: | Project issue tracking |
| Version: | 5.x-2.x-dev |
| Component: | User interface |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed |
Issue Summary
The sorting of versions in the user interface shows 6, 4 and then 5. It should display the versions in order.
Comments
#1
a) Can you explain where in the interface you're talking about?
b) Is this your own site or on drupal.org?
c) Can you provide a screenshot of what you're seeing?
#2
1) See the attached image.
2) On drupal.org, specificallly on http://drupal.org/project/issues/drupal?page=1&sort=desc&order=Version
#3
Changing status back to active and clarifying title.
I checked the URL and see the same problem. The order of versions, when sorted as descending, is:
6.0-beta1
4.7.7
5.2
7.x-dev
I suspect that these are being sorted on the order in which the taxonomy term itself was created, not by the term itself. But that's just a guess.
#4
Ahh, ok, sure. The problem is that an issue's version is stored in the DB as the nid of the release node that the issue is related to. It's sort of a weird level of indirection that has been a source of various degrees of confusion and trouble. So, when you sort by version, you're really sorting by release node nid. :(
I agree that's a bug, and I don't know of any older issues about this particular aspect of the problem, so we can leave this open. Not sure if/when it's going to be fixed, however, since it'd require a pretty major re-write of sections of project_issue and a heafty schema update and data migration...
#5
#6
i really think the simple fix here is to remove the tablesorting option -- it's hardly like we need it in a table this small...
#7
i dunno, i think we should keep the ability to sort/group issues by version. for example, i'd rather we made it easier for the issue queue to be used directly for figuring out what issues are important for the next release, instead of having to make g.d.o wiki pages all the time. sorting issues by version seems like an important aspect of this. i just don't know how to get it working given the current underlying implementation. :(
perhaps, *gasp*, we should denormalize a little more and store both the release nid and the release node's "version" attribute in the {project_issues} table? we need to do this mapping for display, anyway, and if we just stored it in the table, we could directly query that column (and sort on it) using the tablesort API as-is. yes, it's not ideal, but then again, this release nid indirection is a little weird at times. this could save us a lot of JOINs, too, I think, and would probably make views integration easier, as well. it'd definitely save a node_load() on the release node in project_issue_view(), for example.
of course, it means that if the "version" field ever changes on a release node, we'd have to update the change in both places. that basically never happens, except in the evil special case for existing "HEAD" release nodes. I guess it could happen more frequently for sites not using cvs.module. Still, doesn't seem like it's that bad, especially since there's already a single function in project_release.module that handles all DB updates: project_release_db_save().
#8
well, then this issue will have to wait longer...