Bug 827131
Summary: | Feat: catalog should provide a mechanism to highlight specific comments for attention | ||
---|---|---|---|
Product: | [Retired] Red Hat Hardware Certification Program | Reporter: | Rob Landry <rlandry> |
Component: | Hardware Catalog | Assignee: | Wei Shen <wshen> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 1.6 | CC: | ctatman, hwcert-catalog, junwang, pxue, tfu, wshen |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
URL: | http://hardware.redhat.com/ | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-11-20 03:01:58 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 837717 |
Description
Rob Landry
2012-05-31 17:22:02 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. (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. (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. Created attachment 597803 [details]
mockup highlight enable/disable screenshot
(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. Created attachment 602663 [details]
the patch
Created attachment 602664 [details]
highlight module
Created attachment 602783 [details]
highlight mockup
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. FWIW, I used "position: relative; left: 50px;" for the highlight styling in the mockup. web2 has updated with the patch, please review 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 changed as requested, I am ok with the highlight checkbox location. Created attachment 603405 [details]
the new patch for highlighting comments
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> (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 verified on web2 |