Edgewall Software
Modify

Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#9929 closed enhancement (duplicate)

Pluggable Version and Milestone Sorter

Reported by: Carsten Klein <carsten.klein@…> Owned by:
Priority: normal Milestone:
Component: ticket system Version:
Severity: normal Keywords: fieldrefactoring
Cc: Branch:
Release Notes:
API Changes:
  • New extension points IVersionSorter and IMilestoneSorter
  • patch to both Version model and Milestone model to make use of the new sorters
  • introduction of two new components which implement default sorting behaviour for both versions and milestones
Internal Changes:

Description (last modified by Christian Boos)

The current version and milestone sorting is rather generic.

However, it fails on correctly sorting versions such as 1.0.0proto_stable and 1.0.0proto_alpha, 1.0.0alpha_stable, 1.0.0beta_proto.

These, at least in my world, should be sorted as follows

1.0.0proto_alpha 1.0.0proto_stable 1.0.0alpha_stable 1.0.0beta_stable

The same is true for milestones implementing a similar naming scheme.

What I propose is to allow the user to plug-in both sorters for milestones and versions and make this available as extension points, with the default behaviour being either hard coded into the existing components or externalized as default implementations of these interface.

I already did some work on this and the existing system seems to work, but will fail on input that does not match the sorter's production scheme, i.e. it will raise an exception thus preventing lists from being displayed. So additional work must be invested.

In addition, these sorters should also be able to reverse sort the input based on an additional parameter.

Attachments (0)

Change History (6)

comment:1 by Carsten Klein <carsten.klein@…>, 14 years ago

API Changes: modified (diff)

comment:2 by Carsten Klein <carsten.klein@…>, 14 years ago

API Changes: modified (diff)

comment:3 by Remy Blank, 14 years ago

That's an additional complexity that I would prefer to avoid. The current sorting, while imperfect, works well enough for most cases.

One vote for "wontfix".

comment:4 by Christian Boos, 14 years ago

Description: modified (diff)
Keywords: fieldrefactoring added
Milestone: next-major-0.1X

I see a connection with FieldRefactoring, though. We can't be sure to find a sorting order that would fit for any kind of custom field, so if we make it possible to define a sort order for custom fields, we may as well do the same for "standard" fields.

in reply to:  4 comment:5 by Christian Boos, 14 years ago

Milestone: next-major-0.1X
Resolution: duplicate
Status: newclosed

Replying to cboos:

We can't be sure to find a sorting order that would fit for any kind of custom field, …

There was even a ticket for that: #3080. Closing as duplicate.

comment:6 by anonymous, 13 years ago

The default sorting of versions doesn't fit to our needs as well - in our company we like to order it alphabetically.

I also found a defect of sorting milestones - it sorts first lower cases and then uppercase. For example trac does: a, b, c, A, B, C instead of a, A, b, B, c, C

I already solved these two issues in a Component, see http://trac-hacks.org/browser/ticketnavplugin/0.12/ticketnav/ticketnav.py#L415

More infos see at http://trac-hacks.org/wiki/TicketNavPlugin#ComponentSortMilestoneVersion

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none) to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.