View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0023550||mantisbt||customization||public||2017-10-26 07:08||2019-04-21 02:53|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||2.21.0||Fixed in Version||2.21.0|
|Summary||0023550: Modification to status colors css|
The generated css for status colors has definitions for "color" and "background-color".
bug_update_page uses this class to apply background coulour. Fortunately, the only content in the cell is an input that is not affected by those color styles.
The proposal is to have both:
And use them appropiately, and have it available to be used for customizations.
|Tags||No tags attached.|
|has duplicate||0024534||closed||atrol||Bad generated CSS for status icon|
|has duplicate||0025632||closed||dregad||Status color boxes should not have background css set|
|related to||0025650||closed||dregad||Show status with a color square instead of background color on Bug Update Page|
|related to||0025651||closed||dregad||Update color when new Status is selected in Bug Update Page|
Do we need the background color?
Probably yes. However, with any method, there is some inconsistency when the field is editable and you select a different status, the color does not change.
In my case, i'd want to use those in customizations, eg: plugins, custom functions... Having those available is a great help.
Having both color + background set equally together creates two issues.
From my point of view on the UX, the color should be limited to the status square and nothing more.
I agree with @atrol. we should use the same fg color square in the bug_update_page. Consistent with other views.
After @jingshaochen opened 0025632, I proposed PR https://github.com/mantisbt/mantisbt/pull/1484. Then I realized that it was indeed a duplicate of this issue, so I'm moving the discussion back here as the issue is older and has other people involved.
I am fine with changing bug_update_page.php to use the colored square instead of background color. That should be covered by a separate issue though.
This is basically what I implemented in the PR. And I agree with @cproensa that having 2 distinct classes can be useful in plugin or customization scenarios, even if the background-color class is not used in MantisBT core anymore.
Does it make sense to have 2 distinct classes that provide the same color without having 2 distinct configuration options, e.g.
In my opinion it does make sense, because it is essentially the same color (i.e. resolved is green); the only difference is about the way said color is used to provide visual feedback to the end user. Defining a different set of colors for fore/background would be needlessly complicating things.
Created 0025650 to track this.
And 0025651 for that.
MantisBT: master fc6bf8e6
2019-03-22 08:18:34Details Diff
|Distinct classes for status color fore/background
Currently the CSS classes defined in status_config.php set both the
foreground and background colors. This sometimes causes display glitches
on the status color boxes.
This commit fixes the problem as follows:
- add new html_get_status_css_fg() / html_get_status_css_bg() functions
- define new, distinct status color classes (status-XX-fg and
status-XX-bg) to replace the single status-XX-color used previously
- update MantisBT pages to use the new classes / API functions
Code cleanup: some variables were renamed to match coding guidelines and
better reflect their purpose.
|mod - account_sponsor_page.php||Diff File|
|mod - bug_update_page.php||Diff File|
|mod - bug_view_inc.php||Diff File|
|mod - core/bug_group_action_api.php||Diff File|
|mod - core/columns_api.php||Diff File|
|mod - core/custom_function_api.php||Diff File|
|mod - core/html_api.php||Diff File|
|mod - core/relationship_api.php||Diff File|
|mod - css/status_config.php||Diff File|
|mod - my_view_inc.php||Diff File|