Sort is done alphabetically instead of in UDA value order from config

[nfraprado]

When showing a report that is sorted by an UDA, VIT sorts the UDA values alphabetically, while Taskwarrior sorts using the order the UDA values are defined in the config.

To reproduce, use the following taskrc config:

data.location=~/test/data
uda.test.type = string
uda.test.label = Test
uda.test.values = a,b,c,z,y,x

report.test.columns = id,test,description
report.test.labels = ID,Test,Description
report.test.description = Test
report.test.sort = test-

Add tasks with each of the Test UDA values.

Display the Test report on VIT and Taskwarrior.

The sorting of the tasks will be, from top to bottom, based on the Test UDA values:

Taskwarrior: a,b,c,z,y,x
VIT : z,y,x,c,b,a

[thehunmonkgroup]

This seems more like a bug in TaskWarrior.

test- should sort descending, and the TaskWarrior result is ascending. Also, I've seen no documentation in TaskWarrior that UDA values should be sorted according to the order they are specified. Doesn't alphabetical make more sense anyways?

Finally, all of the sorting in VIT is structured around alphabetical sorting, so even if none of the above is true, it might be a real pain to treat UDA fields separately.

[fdela]

IMHO, it rather makes sense to use the lexicographic order when sorting a UDA

• of type string
• which has a specified set of values
  (if we don't care about order, we wouldn't have a rc.report.foo.sort specify field[+-] anyway, so point would be moot).

It can be e.g. used with default priority field.
As I use it, I have configured uda.priority.values=H,M,,L so that tasks with Low priority are shown later than those with none specified when sorted descending.

I analyzed how it works in TaskWarrior: the entries are specified in descending order, e.g.

Say we have (for a string UDA) uda.field.values = High, Medium, Low
Then we have tasks sorted as follows, according to the value of field:

rc.report.foo.sort=field- => <empty>, High, Medium, Low
rc.report.foo.sort=field+ => Low, Medium, High, <empty>
(<empty> field value is arbitrarily considered the biggest value if not specified explicitely [as with my priority example hereabove, note the empty value is between the two consecutive commas]).

For numeric, duration and date types, uda.field.values is unused, and natural order is used, so no change needed
For string type, one would need to use a custom comparator that sorts alphabetically if no uda.field.values is used, or lexicographically otherwise (with allowed values specified in descending order, and special case of <empty> value, as shown above)

[thehunmonkgroup]

This seems like an awful lot of work for not a ton of benefit.

I'd be open to reviewing a PR that implements the functionality described above for string UDAs, but will probably not spend the time to fix this myself.

[sclee15]

I second this motion for the sort feature.

[thehunmonkgroup]

Just to be clear, this issue doesn't need votes, it needs somebody to write the code.