Bug 827131 - Feat: catalog should provide a mechanism to highlight specific comments for attention
Summary: Feat: catalog should provide a mechanism to highlight specific comments for a...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Hardware Certification Program
Classification: Retired
Component: Hardware Catalog
Version: 1.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Wei Shen
QA Contact:
URL: http://hardware.redhat.com/
Whiteboard:
Depends On:
Blocks: 837717
TreeView+ depends on / blocked
 
Reported: 2012-05-31 17:22 UTC by Rob Landry
Modified: 2014-06-23 01:33 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-11-20 03:01:58 UTC
Embargoed:


Attachments (Terms of Use)

Description Rob Landry 2012-05-31 17:22:02 UTC
Description of problem:

Reviewers, vendors and tams need a mechanism to highlight a particular comment for later reference.  This should be allowed to be set by one of the above with some control over who can clear it.

This feature can then be used to highlight a specific question on a spec, or a kbase that is needed, or some new hardware that was discovered in a result not listed in the spec, etc.

The potential uses should be free form.


Additional info:

Comment 1 Rob Landry 2012-05-31 17:24:56 UTC
These highlights should be reviewed by the ptam and reviewer before posting but should not be required to be cleared by the ptam/reviewer before posting.

Probably an am I sure checkbox next to each comment when trying to post public would be the best way as the quantity of these still required for a post should be low.

Comment 2 Pengfei Xue 2012-06-19 06:57:30 UTC
(In reply to comment #0)
> Description of problem:
> 
> Reviewers, vendors and tams need a mechanism to highlight a particular
> comment for later reference.  This should be allowed to be set by one of the
> above with some control over who can clear it.

what are we going to hightlight, hightlight the keywords in comments, or specific comment?

I'm thinking adding a link after 'reply', click this will popup a dialog for requesting to hightligh/mark this comment, and there will be an input for hightlight reason, and some buttons such as 'request', 'accept', etc

1, if this request is issued by redhat people, this mark will be public immediately
2, otherwise, the mark is privte, and there will be a mark near this comment, we readhat people click that mark, popup a dialog with that reason, and buttons such as 'accept', 'reject'


this method needs a new table for recording these hightlights.

Comment 3 Rob Landry 2012-07-10 15:52:30 UTC
(In reply to comment #2)
> (In reply to comment #0)
> > Description of problem:
> > 
> > Reviewers, vendors and tams need a mechanism to highlight a particular
> > comment for later reference.  This should be allowed to be set by one of the
> > above with some control over who can clear it.
> 
> what are we going to hightlight, hightlight the keywords in comments, or
> specific comment?

The comment, similar to how private works; with a simple checkbox.  The catalog comment code should include like the above with private a checkbox for highlighting the entire comment, most likely in yellow or "brighter" coloring.  This should work like the BZ private for the UI where both the new comment can be highlighted and an existing comment can be highlighted after the fact.  The highlighting color should also reflect if it is a public or private comment.

I would also suggest the catalog comment UI also be updated to support marking and unmarking private for existing comments as well as the recoloring of the add new comment box like how BZ does it.

This will ensure a  level of consistency and not cause confusion by having the catalog use a per comment checkbox for highlight and Bugzilla using it for privacy.

> 
> I'm thinking adding a link after 'reply', click this will popup a dialog for
> requesting to hightligh/mark this comment, and there will be an input for
> hightlight reason, and some buttons such as 'request', 'accept', etc

Too complicated.

> 1, if this request is issued by redhat people, this mark will be public
> immediately
> 2, otherwise, the mark is privte, and there will be a mark near this
> comment, we readhat people click that mark, popup a dialog with that reason,
> and buttons such as 'accept', 'reject'

Again too complicated.

> this method needs a new table for recording these hightlights.

Ack, a table is needed to record which comment should be highlighted unless there is a similar mechanism we should consider that is already part of BZ comments already.

Comment 5 Rob Landry 2012-07-12 12:58:37 UTC
Created attachment 597803 [details]
mockup highlight enable/disable screenshot

Comment 6 Pengfei Xue 2012-07-16 05:33:48 UTC
(In reply to comment #3)

> after the fact.  The highlighting color should also reflect if it is a
> public or private comment.

I think we can use the checkbox as a reminder, if the comment is a private one, then the private checkbox will be checked. Otherwise, there will be more colors in cert comments, and user needs to remeber which color is for what purpose.

Comment 11 Wei Shen 2012-08-07 07:37:33 UTC
Created attachment 602663 [details]
the patch

Comment 12 Wei Shen 2012-08-07 07:38:20 UTC
Created attachment 602664 [details]
highlight module

Comment 13 Rob Landry 2012-08-07 14:56:08 UTC
Created attachment 602783 [details]
highlight mockup

Comment 14 Rob Landry 2012-08-07 15:03:55 UTC
I looked @ the test site, and it does not seem to handle the case of private and highlighted with a visual cue.  Also the coloring is quite harsh.  I looked @ some color options and I think the problem can more easily be solved by setting the highlighted comment to the right.  I've attached a mockup of this in comment 13.  In the mockup public/private is quite clearly defined as well as highlighted and not, and the case of private+highlighted should remain obvious without creating a rainbow of the comment display.

In the mockup I used a bug comment section as an example, we should go ahead and pickup the Bugzilla comment style as I think the current table method is going to be painful to achieve the left/right motion this where the conversions to divs in a fixed width table is much easier to implement this highlight method.  Updating the comment style should be fairly easy.  The highlighting can use JS+CSS to move the box left and right as appropriate but will then need to also set a hidden bit to ensure the highlighting is recorded.  I have used [*] as the link with a title of "Toggle Highlighting".

The bz comment display is overall just a style change but also includes the addition of the [+]/[-] show hide javascript.  I'm indifferent if we include this or not.

We might consider just including the bugzilla.redhat.com style sheet to avoid having to code the comment style.

Comment 15 Rob Landry 2012-08-07 15:05:11 UTC
FWIW, I used "position: relative; left: 50px;" for the highlight styling in the mockup.

Comment 16 Wei Shen 2012-08-08 10:06:05 UTC
web2 has updated with the patch, please review

Comment 17 Rob Landry 2012-08-08 19:49:08 UTC
Much improved visually.  

Could we do left 25px instead of 50 and save on the left/right room if we also do a border thickness of 2px?  It's less harsh but still obvious in my quick test of this style.

Our fonts seem off vs. the Bugzilla UI.   I think they are smaller in comparison?

I'm not certain about the highlight checkbox location; it's pretty crowded with the private checkbox

Comment 18 Wei Shen 2012-08-09 08:06:19 UTC
changed as requested, I am ok with the highlight checkbox location.

Comment 20 Wei Shen 2012-08-10 03:45:57 UTC
Created attachment 603405 [details]
the new patch for highlighting comments

Comment 21 Rob Landry 2012-10-19 20:50:58 UTC
Minor style & phrasing updates for new comment box.

<div id="comment_header_area">
  <span id="comment_header_reminder" style="font-weight: 700;">Additional Comment</span>
  <span id="comment_highlight" style="float: right; margin-left: 5px;">
    <input type="checkbox" id="commenthighlight" value="1" name="commenthighlight">
    <label for="commenthighlight">Highlight</label>
  </span>
  <span id="comment_privacy" style="float: right;">
    <input type="checkbox" value="1" id="commentprivacy" name="commentprivacy">
    <label for="commentprivacy">Private</label>
  </span>
</div>

Comment 22 Wei Shen 2012-10-21 06:52:30 UTC
(In reply to comment #21)
> Minor style & phrasing updates for new comment box.
> 
> <div id="comment_header_area">
>   <span id="comment_header_reminder" style="font-weight: 700;">Additional
> Comment</span>
>   <span id="comment_highlight" style="float: right; margin-left: 5px;">
>     <input type="checkbox" id="commenthighlight" value="1"
> name="commenthighlight">
>     <label for="commenthighlight">Highlight</label>
>   </span>
>   <span id="comment_privacy" style="float: right;">
>     <input type="checkbox" value="1" id="commentprivacy"
> name="commentprivacy">
>     <label for="commentprivacy">Private</label>
>   </span>
> </div>

fixed

Comment 23 Wei Shen 2012-11-01 06:41:52 UTC
verified on web2


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