Redmine

So let's say the priority low (which should be coloured blue by the theme's CSS) is reordered to position 5, than the CSS-styles "think" it is the highest configured priority and colours it deep red.

If you move a priority to 5, it is actually a high priority and should be colored in red, whatever its name is.

I think that using the priority position to color the issue list makes really more sense than using ids:
If you have 5 priorities, their position will be 1 to 5 even if you deleted the default one and recreated new ones. We can't assume that priorities have ids from 1 to 5.

Jean-Philippe Lang wrote:

So let's say the priority low (which should be coloured blue by the theme's CSS) is reordered to position 5, than the CSS-styles "think" it is the highest configured priority and colours it deep red.

If you move a priority to 5, it is actually a high priority and should be colored in red, whatever its name is.

So Redmine accepts only 5 priorities which are ordered like by default? Hypothetically, if I were using 10 priorities, priority 5 is expected to be something like medium. How can we make the required info available to the CSS to make this colouring of issue possible without these side-effects?

Jean-Philippe Lang wrote:

I think that using the priority position to color the issue list makes really more sense than using ids:
...
We can't assume that priorities have ids from 1 to 5.

Agreed! That's also why I added this warning (This workaround doesn't solve the issue when the amount of enumerations is changed since than the id's aren't fixated any longer.) to the patch.

Jean-Philippe Lang wrote:

If you have 5 priorities, their position will be 1 to 5 even if you deleted the default one and recreated new ones.

True, but if a user decides to modifiy the order of the priorities (so instead of 1 low & 5 high he now re-ordered them to match 1 high & 5 low) or modifies the amount of them, the colouring added by the current CSS-styles isn't sufficient to colour the issues correctly after the changes...

The behaviour of Redmine within the scope of this issue hasn't been changed. Any other updates regarding this issue?
It can make it pretty difficult to code themes including issue-prio colouring without having a need to tweak the CSS to adapt the theme manually according to the specific instances' configuration (read: prio-order)...

We have had this issue over at Planio today, so I'm attaching our patch. It will actually color code the three top most priorities in different shades of red and the lowest priority in blue just like before. However, should you have more than 5 priorities, it will behave nicely and just leave the color for priorities 2 through x, where x = number of prios - 3, alone. It will also make more sense (according to our opinion) for cases where you have 2 priorities, i.e. it will use gray and red and not blue and gray.

I don't think that patch will do... I think the only options are:

• reference by priority position (what is currently done, breaks re-ordering & addition)
• reference by priority id (will survive reordering & addition, but not portable)
• reference by "nicified" priority name (will not survive a re-name)

Hi Jean-Philippe,

I just updated our instance and all colors are messed up.
I reverted the priority-{position} change, and think it's maybe not a good idea: How can we create a theme now? It's barely impossible to guess IDs from redmine instances.
Any chance this could be reverted?

Thanks
Philippe

Philippe Lafoucrière wrote:

It's barely impossible to guess IDs from redmine instances.

Yes it is, the id is part of the url used to update or delete the priority element in the administration screen.

Any chance this could be reverted?

The use of ids is more consistent than the use of the position since the id can't be updated, so the answer is no.

Etienne Massip wrote:

The use of ids is more consistent than the use of the position since the id can't be updated, so the answer is no.

Shouldn't the alternate theme be updated then ?

Ken Zalewski wrote:

Robert Hailey's idea above is the best solution: Use textual priorities for CSS coloring, such as "priority-low", "priority-normal", "priority-high", and so on.

In our current Redmine2 installation, the five priorities have database IDs from 3 through 7. Most themes are looking for priorities from 1 to 5. This botches almost every available theme.

I would agree also if the name was not locale-specific.

The current css class based on ids will be preserved (for future use) but r10720 adds a textual class that do not rely on ids or the number of priorities. See #12216 for more details.

how about adding additional "css" field to issue priority?
Then you can reorder whatever you like, add any amount of issues and you only have to adjust css name for given issue.
eg:

• high2
• high1
• default
• low1
• low2

• high1
• high2
• default
• low2
• low1

In my opinion it's totally weird now...