RFE: Add an order facility

[izzy]

It would be nice to have the screenshots in the matrix view ordered by a given criteria:

• by Name
• by the time it was added
• by its ID (as it is now)
• by a new field "order" which can optionally be filled
• by a combination of those (e.g. "order,name" would order by "order" first. Two items with the same "order" would then be ordered by name)

Since the "order" field would be optional, one probably only fills something here to push some screenshot(s) up in the list. So we have to make sure in this case that items with a filled "order" field always come before those with an empty field - e.g. by substituting "zzzz" (or something at the very end of the list) for empty fields, or just "SELECT..WHERE NOT NULL" first and then followed by "..WHERE NULL".

An alternative to the "order" field would be a "priority" field having a default value of "0" - and a higher priority would shift the screenshot up. While this is an easier attempt, it is not as flexible (a free-text "order" field could achieve much more differentiated "priorities"), plus the confusion whether higher or lower numbers would be sorted first (for "order" one either assumes "numerical" or "alphabetical", but is quite sure it will be sorted from "lower" to "upper"). Sure the priorities could be given names ("10 - High, 5 - Normal, 0- Low"), but it still would be less flexible (but better than nothing ;)

[Radek Bartoň]

The idea of alphabetical order values seems odd to me. If it would be stored as a string SQL query order would be alphabetical too and if it would be stored as number there is not defined which number assign to string field values.

Another compromise would be to maintain ascending manner of order (by logical inversion of queries or negative value of internal representation) and restricting input to numbers or spin box widet with JavaScript.

[izzy]

If you prefer to store numbers, another approach could be to convert everything to its ASCII decimal representatvies (e.g. "A" would become 065 etc):

 1234 => 049050051052
 abcd => 097098099100

and either restrict input to US7ASCII, or convert "special chars" to their corresponding base chars (e.g. char with accent => char without accent).

But I guess your idea with resticting input to numbers would be fine as well. If this field will be called "[order-]position", it is quite clear it has to be a number, and the lower the number the more the picture will be moved up. I guess this would be the best and clearest variant, almost making misunderstandings impossible. The added plus is: Easier implementation, less code, and less things which can go wrong (char conversion etc.) :-).

[Radek Bartoň]

This ASCII to number conversion would be the only way how to keep correct order of numbers (except separate approach to numbered strings and text strings). But this can easily impact on maximal allowed integer value. Using srings dicrectly would lead to 100 be before 99 for example.

I think that traditional way of implementation is still more suitable for this.

[izzy]

I agree. So you vote for "position" - or for "priority"? For more clearness (and flexibility) I would vote for "position", since it should be less subject to misunderstanding plus gives more chance to differentiate (not 0-9/10 only, but 0-max_int).

But before we get it wrong: This field should be an (optional) addition (in the sense the user has to fill it optionally), so some other criteria (like ID, name, or date of addition) should be selectable as well ("ORDER BY position ASC, name ASC") for example. Whether only to take one (e.g. radio boxes) or more criteria into consideration (e.g. by an input field similar to "mainnav", where the user can add comma separated values like "position,name,id" or even "position,name DESC,id ASC"), I leave to you ;)

[Radek Bartoň]

Replying to izzy:

I agree. So you vote for "position" - or for "priority"? For more clearness (and flexibility) I would vote for "position", since it should be less subject to misunderstanding plus gives more chance to differentiate (not 0-9/10 only, but 0-max_int).

Name is one thing and possible values is other. I ment all the time "priority" to be 0-max_int. Name "order" or "position" may imply that values should be different for each screenshot althouh name "priority" in context of screenshots may not be clear enough too.

But before we get it wrong: This field should be an (optional) addition (in the sense the user has to fill it optionally), so some other criteria (like ID, name, or date of addition) should be selectable as well ("ORDER BY position ASC, name ASC") for example.

Of course.

Whether only to take one (e.g. radio boxes) or more criteria into consideration (e.g. by an input field similar to "mainnav", where the user can add comma separated values like "position,name,id" or even "position,name DESC,id ASC"), I leave to you ;)

I thought that order would be configurable only by admin in trac.ini first. If this would be allowed to users there should be SCREENSHOTS_ORDER permission too?

[izzy]

Replying to Blackhex:

Agreed to all. You may make the name of that field configurable as well #-)

I thought that order would be configurable only by admin in trac.ini first. If this would be allowed to users there should be SCREENSHOTS_ORDER permission too?

Oh - not a bad idea. I thought about the admin part only. But to give the user this possibility (overriding the "default" set by admin) also is a nice idea. I don't think this requires an additional permission, but rather would bind it to SCREENSHOTS_FILTER instead (it is a kind of filtering, isn't it? You could call it a "sort filter").

[Radek Bartoň]

Agreed to all. You may make the name of that field configurable as well #-)

That is not necessary in context of GUI (altering templates) and unwise in context of DB. :-)

Oh - not a bad idea. I thought about the admin part only. But to give the user this possibility (overriding the "default" set by admin) also is a nice idea. I don't think this requires an additional permission, but rather would bind it to SCREENSHOTS_FILTER instead (it is a kind of filtering, isn't it? You could call it a "sort filter").

OK, that would be better, but this will have very low priority of implementation.

[izzy]

Yepp - leave something for a later release. Post it on the Todo to make people hungry for it :) As you wrote: Make it configurable for admin in trac.ini first, and put the user part on the Todo for later. Sounds great so far - can't wait to see it ;)

[Radek Bartoň]

To be honest, I would rather put this whole ticket only to 0.11 branch. Since it need database schema uptate, I'm not keen to do it twice.

[izzy]

Replying to Blackhex:

To be honest, I would rather put this whole ticket only to 0.11 branch. Since it need database schema uptate, I'm not keen to do it twice.

I was afraid that at some point you would say this. I would feel very pity with this, since at this moment I don't have time for an upgrade to 0.11 with all the possible caveats involved (Genshi vs. ClearSilver, database, plugins possible failing or even no more available). 0.11 is (as far as I understand) still in Beta state (even trac.edgewall.org still uses 10.4), and there may be many others preferring a stable 0.10.4 on their servers - I don't think I'm the only one (and: Yes, I just upgraded 0.10.3 to 0.10.4 this week on my server).

Sure, nobody should cry for 0.9 anymore - but as long as 0.10 is the official "stable" version, it would be preferable to release at least to this as well.

[Radek Bartoň]

r4344 gives introductory implementation of ordering for 0.11 branch. Please try it and comment if it's useable enough for you. By default, single ordering by ID is setted up. To add other ordering modify default_orders and default_order_direction configuration variables. For example:

default_orders = priority,time
default_order_directions = desc,asc

Obvisously, number of items must match.

[izzy]

Sounds promising - but as with #3771, I can not test it before you ported it to the 0.10 branch... Will do as soon that is done, but unfortunately cannot do so before...

[Radek Bartoň]

This will stay only in 0.11 branch.