Bug 967629 - [UI] flags changes might deserve a color on their own (or not use "private" color regardless which comment they join)
[UI] flags changes might deserve a color on their own (or not use "private" c...
Status: CLOSED WONTFIX
Product: Bugzilla
Classification: Community
Component: Creating/Changing Bugs (Show other bugs)
4.4
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: Simon Green
tools-bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-27 12:59 EDT by Jan Pokorný
Modified: 2014-10-12 18:50 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-30 18:27:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Demo of what I am talking about (58.28 KB, image/png)
2013-05-27 13:04 EDT, Jan Pokorný
no flags Details

  None (edit)
Description Jan Pokorný 2013-05-27 12:59:59 EDT
This minor tweak would be better for color consistency.

If the comment is private, accompanying flag changes inherit the "private"
background color.  Standalone flag changes are on white.  But this
background color has (IMHO) no relevance to flag change visibility.

Proposed changes are either to come up with the third color (i.e., not white,
not "private" red/pink) as a background for the flag changes regardless
which comment it joins, or to simply put these changes on white background
unconditionally.
Comment 1 Jan Pokorný 2013-05-27 13:04:51 EDT
Created attachment 753656 [details]
Demo of what I am talking about
Comment 3 Jan Pokorný 2013-05-28 13:38:47 EDT
Another possibility is to reflect (in color or even in groupping with
comments with the same properties) the visibility of change if any such
concept exists (should it reflect the state at when actually change
happened or current Bugzilla change visibility configuration?)
Comment 4 Simon Green 2013-05-30 18:23:04 EDT
I've been considering this bug for the past few days and have decided that we shouldn't implement it. I think it is more important from an informational viewpoint to group the history with the comment rather than separate them out.

This also follows Mozilla's implementation of the code too.

  -- simon
Comment 5 HSS Product Manager 2013-05-30 18:27:07 EDT
Product Management has reviewed and declined this request. You may appeal this
decision by reopening this request.
Comment 6 Jan Pokorný 2013-06-04 12:18:15 EDT
> I think it is more important from an informational viewpoint to group the
> history with the comment rather than separate them out.

What is the difference if I am adding a comment and changing some flag
at the same time/submit VS. adding a comment and then change the flag
(and nothing else has occurred in the meantime)?

Because bugzilla currently makes the difference (and is separating out
the latter) and I'm afraid I don't see the reasoning line here.
Comment 7 Simon Green 2013-06-04 18:41:42 EDT
(In reply to Jan Pokorný from comment #6)
> > I think it is more important from an informational viewpoint to group the
> > history with the comment rather than separate them out.
> 
> What is the difference if I am adding a comment and changing some flag
> at the same time/submit VS. adding a comment and then change the flag
> (and nothing else has occurred in the meantime)?

The first one happened at the same time. The second one happened at different times. I think it is more beneficial to show same time changes together. This is in line with the 'Show History' link which also shows same time changes together regardless of the visibility of the change.

  -- simon
Comment 8 Jan Pokorný 2013-06-10 14:53:22 EDT
Okay, the commens-flags interleaving might deserve some tweaking, but
I have to admit it works well on the whole (e.g., in case of
[bug 250718 comment 3]).

Note You need to log in before you can comment on or make changes to this bug.