New Priority Schema?

[gustavovera@…]

What if, instead of using a fixed, 5 option enumerated priority schema, you just use a numeric, non labeled schema, from 1 to n? This could allow to re-prioritize a ticket easier (with the proper UI, of course).

You just need to inter-change priority values when moving a ticket one position up or down, and when you move it "jumping" n tickets, those should only be incremented or decremented by 1 on their priority field and after that, use the "free" space for the re-prioritized ticket.

You can provide an arrow up / arrow down on the lists for every query, for "one step move", and a more advanced option on ticket edition, like a "give immediate upper/lower priority respect to ticket n[user provided]", for bigger jumps.

I think that the DB impact with this change could be minimal, but you have to re-think some features like the color from red to green on your listings.

[cboos]

Have you checked the WebAdmin UI for priorities? They are already numerical under the hood.

This way of doing things is also what will be standard in 0.11.

Please base your comments/suggestions on that (and they are welcome, of course!)

One thing that needs fixing is the possibility to adjust (automatically?) the color scale to the complete range of available priorities. There's also a known defect concerning deleted priority values that can't be replace, so no need to report that again in case you stumble upon ;-)

[gustavovera@…]

Well, No, I didn´t (shame on me!) Actually, I'm quite new for trac, but I love what I already get with it.

I'm instead, used to the trac-admin command. I was supossing (almost guessing) that Webadmin provides more or less the same functionallity that tracadmin provides, but I have to checkit.

Anyway, I know that I can add more priorities to the enum table, and that the related numeric value is used for the ordering process. But what I´m suggesting is, to forget almost everything about that enum. Just use the field "priority" as an ordering criteria. I´m suggesting an atomic, by-ticket-priority. So you can know exactly what ticket is more important that another. With this new aproach, you don´t have groups of, by example, highest tickets no prioritized between them. What if you have 10 highest tickets, but one of them is "more highest" than the rest? Currently, you can "solve" that issue using milestones, or severity... but I don´t think in that like the best aproach.

What I want, is to add a new ticket and that, by default, that ticket gets registered with the TOP of the list priority, or at the bottom... And maybe now the "by default" 5 predefined priorities could be another thing, and actually define ranges (that should be expressed for example in percentage). So you can choose tickets choosing priorities between: Top of the list, below first 20%, below first 40%, below first 60%, and bottom of the list. And the user, as I proposed initially, should be able to use even a more precise scheme. The "insert it after / before ticket n".

I don´t know if this is what the user gets with the webadmin that you comment previously. If is at least similar to this, please forgive me, and I´m gonna checkit!

[cboos]

Well, no, the WebAdmin doesn't offer anything more spectacular than TracAdmin at this point ;-) I was suggesting you had a look as it makes the current way of doing things immediately understandable. That was not needed for you as you are already familiar with the way the trac-admin command line works.

What I'd suggest in order to implement your idea is that you could use a rank custom field. This, combined with 1) either a dedicated report, 2) or custom queries with secondary sort key (see #4644), would enable you to get a more fine-grained ordering between issues.

[gustavovera@…]

Yes, I had that in mind too, maybe I'll implement something like that in my project. Add the extra field as a custom field and customize the SQL on the reports are the easy part, but to fully provide this new feature that I have in mind, I need to provide a more customized user interface. One that should provide an "almost automatic" value for that rank field, among other previously commented features like the "priority by range" stuff, and with the possibility to re-adjust tickets in the rank from a report result (rank edition directly from the list with the previously commented move-up/down).

Some questions: Do you think that this feature is a good candidate to be implemented in the near future for next releases? Is a god candidate for implementation at all? Or Should I try to implement it for my self? (maybe as a trac hack?)

[cboos]

Replying to gustavovera@gmail.com:

One that should provide an "almost automatic" value for that rank field, among other previously commented features like the "priority by range" stuff,

Well, if you consider the rank to be a secondary adjustment value within the current priority as opposed to a kind of global rank, this all comes for free. Pick a default value of 50, and allow values from 10 to 99, so that it's possible to sort alphabetically on this value in a sensible way.

So, you'll get: ... Low (10-99), Normal (10-99), High (10-99) ...

... and with the possibility to re-adjust tickets in the rank from a report result (rank edition directly from the list with the previously commented move-up/down). Some questions: Do you think that this feature is a good candidate to be implemented in the near future for next releases?

I think the bulk editor (see #525) which is currently being developed will be a good basis for implementing this (with the addition of a "special" ticket field... well, this would even be a good candidate for a sample plugin ;-) ).

So, stayed tuned ;-) (see log:sandbox/pycon/ninja, log:sandbox/field-refactoring-tmp)