View Issue Details

IDProjectCategoryView StatusLast Update
0020068mantisbtcustomizationpublic2015-12-06 02:45
ReporteratrolAssigned Todregad 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.3.0-beta.1 
Target Version1.3.0-rc.1Fixed in Version1.3.0-rc.1 
Summary0020068: No color applied to status enums with spaces in status values
Description

We do not restrict the status values at the moment, e.g. we allow to have spaces in it
https://www.mantisbt.org/docs/master/en-US/Admin_Guide/html-single/#admin.customize.status

This configuration worked in 1.2.x
$g_status_enum_string = '10:new,20:feedback,30:acknowledged,40:confirmed,50:assigned,60:in progress,80:resolved,90:closed';
$g_status_colors['in progress'] = '#ACE7AE';

You will not get the color in current master as we produce the following HTML output
class="small-caption in progress-color"
and this CSS code in status_config.php
.in progress-color { background-color: #ACE7AE; width: 13%; }

This is not a valid CSS class name, see http://www.w3.org/TR/CSS2/syndata.html#characters
Using the same approach that we had before (just replace space by underscore) will not work.

Using numeric values should work
e.g. something like class="small-caption status-color-60"

TagsNo tags attached.

Relationships

related to 0020079 new Custom status colors not working when displaying issues from another project 

Activities

dregad

dregad

2015-09-02 06:35

developer   ~0051358

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.

dregad

dregad

2015-09-02 06:49

developer   ~0051359

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

atrol

atrol

2015-09-02 07:43

developer   ~0051360

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.

dregad

dregad

2015-09-02 12:44

developer   ~0051361

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.

vboctor

vboctor

2015-09-06 01:07

manager   ~0051377

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.

dregad

dregad

2015-09-06 05:45

developer   ~0051379

Last edited: 2015-09-06 05:53

View 2 revisions

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.

dregad

dregad

2015-09-08 04:34

developer   ~0051402

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

atrol

atrol

2015-09-08 15:35

developer   ~0051403

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

dregad

dregad

2015-09-09 04:58

developer   ~0051421

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.

atrol

atrol

2015-09-09 09:10

developer   ~0051425

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.

dregad

dregad

2015-09-09 11:34

developer   ~0051428

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

atrol

atrol

2015-09-10 06:14

developer   ~0051433

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

Related Changesets

MantisBT: master 94aa0058

2015-09-02 06:47:51

dregad

Details Diff
Generate valid CSS/class name for custom status with spaces

Prior to this, for a custom status 'in progress', Mantis would generate
the following invalid code:

- HTML (class name): class="small-caption in progress-color"
- Dynamic CSS (status_config.php): .in progress-color { ... }

We now rely on a new API function html_get_css_identifier() to generate
a valid CSS class name by replacing invalid characters with '-'.

Fixes 0020068
mod - core/html_api.php Diff File
mod - css/status_config.php Diff File

MantisBT: master 72ab9338

2015-09-06 17:50:24

dregad

Details Diff
Use enum value to determine CSS class name

As per atrol's suggestion in issue 0020068

This simpler approach allows more efficient code and removes need for an
extra API function.
mod - core/html_api.php Diff File
mod - css/status_config.php Diff File

Issue History

Date Modified Username Field Change
2015-09-01 15:31 atrol New Issue
2015-09-02 06:35 dregad Assigned To => dregad
2015-09-02 06:35 dregad Status new => assigned
2015-09-02 06:35 dregad Note Added: 0051358
2015-09-02 06:49 dregad Note Added: 0051359
2015-09-02 07:43 atrol Note Added: 0051360
2015-09-02 12:44 dregad Note Added: 0051361
2015-09-06 01:07 vboctor Note Added: 0051377
2015-09-06 05:45 dregad Note Added: 0051379
2015-09-06 05:53 dregad Relationship added related to 0020079
2015-09-06 05:53 dregad Note Edited: 0051379 View Revisions
2015-09-06 17:46 vboctoradmin Target Version 1.3.0-beta.3 => 1.3.0-rc.1
2015-09-08 04:34 dregad Note Added: 0051402
2015-09-08 15:35 atrol Note Added: 0051403
2015-09-09 04:58 dregad Note Added: 0051421
2015-09-09 09:10 atrol Note Added: 0051425
2015-09-09 11:34 dregad Note Added: 0051428
2015-09-10 06:14 atrol Note Added: 0051433
2015-10-24 18:48 dregad Changeset attached => MantisBT master 94aa0058
2015-10-24 18:48 dregad Changeset attached => MantisBT master 72ab9338
2015-10-24 18:48 dregad Status assigned => resolved
2015-10-24 18:48 dregad Resolution open => fixed
2015-10-24 18:48 dregad Fixed in Version => 1.3.0-rc.1
2015-12-06 02:45 vboctor Status resolved => closed