That should be fairly simple to fix, just need to ensure that the status enum's label does not contain any chars not valid for CSS.

That being said, there is at least another issue with dynamic CSS for status colors, as I discovered a couple years ago (see https://github.com/mantisbt/mantisbt/commit/fc13f29d2f09b3894e38405f821d95f3851576fe); I'm not really sure how to fix that properly.

PR https://github.com/mantisbt/mantisbt/pull/637

What's the reason that you didn't implement my simple proposal (generate class names like status-color-10, status-color-20, ...)
This should be better in terms of performance.

You might also consider to append the project id (e.g. status-color-10-1)
Shouldn't this fix what you mentioned at https://github.com/mantisbt/mantisbt/commit/fc13f29d2f09b3894e38405f821d95f3851576fe ?

Furthermore I am not sure if your regexp covers all rules for valid CSS classs names, but that's just a guess, I didn't try.

No particular reason except for me doing this in 10 minutes after lunch break and before rushing into the next meeting, without much in terms of thinking or analysis ;)

You're right, performance would be better with use of a number, I'll make an alternative fix.

Appending the project is only one aspect of the problem - color codes can also be user-specific... So the key is to dynamically build the right set of CSS classes in status_config.php.

In terms of the regexp, I guess it could allow an invalid identifier by allowing the 1st char to be a digit; anyway this point is moot if we go for your number-based approach.

I generally don't see having spaces in status as recommended, I generally prefer having no spaces in $g config option and use spaces in the corresponding $s localization. However, in our documentation for status customization at [1] we replace spaces with underscores to match related custom strings.

[1] https://mantisbt.org/docs/master/en-US/Admin_Guide/html-single/#admin.customize.status

Now it seems we have two issues being discussed here:

1. The coloring of such states is broken in master, and used to work in 1.2.x.
2. Coloring may be incorrect if there is a per project or per user configuration for colors.

I expect number 2 is unrelated to this specific and is one of what I suspect will be a bug farm when having different statuses per project and colors per users or maybe even statuses per project! We may at one point wan't to block some of our configs from being per project or per user even if they are overridable in the database.

I generally don't see having spaces in status as recommended

I agree that it's not recommended, but I don't think this is written or explained anywhere. In any case, the fact is that the system allows it, so we need to make sure using enums with spaces does not cause errors.

With regards to point 2, you are correct that this is a separate issue, and I should probably have opened a separate bug report to track it (EDIT - now it's done, see 0020079). I mentioned it here as I stumbled upon my earlier comment in the code while investigating.

I would definitely advise against (or even disable use of) user-specific color codes, IMO that would really be pointless.

On the other hand, project-specific colors / status codes are a useful feature that we should continue to allow.

PR has been updated to follow atrol's proposed approach, plus a minor improvement.

I would definitely advise against (or even disable use of) user-specific color codes, IMO that would really be pointless.

Not that pointless, there are quite a log of people with decreased ability to see color
https://en.wikipedia.org/wiki/Color_blindness

there are quite a log of people with decreased ability to see color

Including myself actually ;-)

What I mean is that currently the only way to customize colors is via adm_config_report.php. Consequently, it is highly unlikely that an admin would go through the trouble to manage colors at user level.

Reviewed and tried updated PR
Looks quite good, this is what I found until now:

There is a problem to generate .status-<value>-percentage if there is no issue with status <value>.

e.g. this is the generated CSS if there is no issue in whole project with "closed" status.

.status-10-color { background-color: #fcbdbd; }

.status-10-percentage { width: 13%; }

.status-20-color { background-color: #e3b7eb; }

.status-20-percentage { width: 13%; }

.status-30-color { background-color: #ffcd85; }

.status-30-percentage { width: 13%; }

.status-40-color { background-color: #fff494; }

.status-40-percentage { width: 13%; }

.status-50-color { background-color: #c2dfff; }

.status-50-percentage { width: 13%; }

.status-60-color { background-color: #ACE7AE; }

.status-60-percentage { width: 13%; }

.status-80-color { background-color: #d2f5b0; }

.status-80-percentage { width: 25%; }

.status-90-color { background-color: #c9ccc4; }

<div class="error-inline">SYSTEM NOTICE: 'Undefined offset: 90' in 'C:\xampp568\htdocs\mantisbt\dregad\css\status_config.php' line 85</div>.status-90-percentage { width: %; }

.status-legend-width { width: 13%; }

Some more optimization could be to suppress generating .status-<value>-percentage if $g_status_percentage_legend == OFF;

BTW, having <div class="error-inline">SYSTEM NOTICE: ... in CSS output is certainly not wanted.
Not sure if it's worth the effort to change this.

Thanks for testing.

Re: the SYSTEM NOTICEs, I inadvertently removed the array_key_exists() check which was present before. I'll put it back in and update the PR.

Some more optimization could be to suppress generating
.status-<value>-percentage if $g_status_percentage_legend == OFF;

I thought about that, and a few other scenarios as well. Then I started wondering what impact optimizing the CSS to be minimal would have on caching of the CSS (e.g. what happens if I change systems settings or login as a different user)... I left it there as I didn't have more time for research or testing. You can have a look at the work-in-progress: https://github.com/dregad/mantisbt/tree/css-status-color-2

I'll put it back in and update the PR.
Thanks, works now.