sorting sequence of tasks (CE 5.5.4)

[kazuoF]

The task_priority_dom looks like this:

element name / display name
------------------------------------
High / "Hoch" (= equivalent name in German)
Medium / "Mittel" (= equivalent name in German)
Low / "Niedrig" (= equivalent name in German)

In the Dashlet, the items appear in the following order:

Medium -> Low -> High (or vice verce, depending on whether you choose ascending / descending sorting).

Why does Sugar sort the tasks this way and how can I change that?

P.S. Changing the sequence in the dropdown editor by moving one item on top of the other had no effect

[sts]

The sorting uses the key names of the strings. In this case the keys are "High", "Medium" and "Low". Since "H" < "L" < "M" the sorting order will be "High" < "Low" < "Medium".

Since the sorting uses the keys it is independent of the translation. For dropdown lists this can be used for a trick. In the example one could use this keys: "1_Low", "2_Medium", "3_High" which will lead to the expected sorting result "Low" < "Medium" < "High" (because "1" < "2" < "3").

If you'd change the task_priority_dom keys this way I would expect that this should work for tasks created and priority changes after that change.
BUT ...
1) the existing tasks are stored with the old keys in the data base ...
2) Additionaly there are similar lists in task module and other modules too (e.g. project_task_priority_options, issue_priority_dom, ...).
3) And the last (and maybe most important) point: there are some references to these keys in the code!

[kazuoF]

Thank you very much for the detailed and informative reply!

What are the consequences of 2) and 3)? Can I change the key without damaging the whole CRM installation?

Also, there seems to be no way to rename the keys. Is the only option to delete the dropdown entries and create them again with a different name?

[sts]

The main problem is the usage of the priority keys in the code. That means there is some kind of special handling or setting default values (I didn't research all the places where the keys are used).
If you change the keys - if in the standard lists or via using a new list that makes not much difference - you'll lost this special handling if you don't change the code too.

The consequence of 2) is that you'll have to look for all those lists with the priority setting to get a similar behaviour in the different modules, at least those modules you use. (But this is not a must, off course.)

What would I do?
I'd create a clone installation of the productive Sugar instance (code + database). I'd change the list keys and the code which uses these keys in that clone installation. If this works for new tasks, etc. I'd change the old priority values in the database fields next. If the test of the whole system will be fine then I'd do the changes in the productive installation.

[kazuoF]

Thank you, I will consider doing exactly that.