Need ability to set groupsets on comments




17 years ago
6 years ago


(Reporter: caillon, Assigned: justdave)



This would be a blessing for bugs where only one comment releases security
information (such as bug 117614) or has proprietary information, etc.  The whole
bug would not need to be groupsetted, but rather the one comment.
This would be very useful for use here at Red Hat also.

Comment 2

17 years ago
Impimentation Note:
  Be careful when this is done as to not mess up comment numbers.
This can be done two ways I suppose. 

1) Add a new column to longdescs called groupset and treat the same as the 
groupset column in the bugs table. 

SELECT profiles.login_name, longdescs.bug_when, longdescs.thetext
FROM longdescs, profiles
WHERE ($::usergroupset & longdescs.groupset) != 0
AND profiles.userid = longdescs.who
AND longdescs.bug_id = $id

2) With the new group schema changes I can finishing up on add a new table called
 longdescs_group_map and then assign a unique ID to each comment in 
longdescs. longdescs would need a new column called comment_id.

comment_id   |     group_id
100               |     10

And then in GetLongDescriptionsAs{Text|HTML}()  change the query to be 
the following:

SELECT  profiles.login_name, longdescs.bug_when, longdescs.thetext
FROM     longdescs, profiles, longdescs_group_map
WHERE  longdescs.comment_id = longdescs_group_map.comment_id
	  AND longdescs_group_map.group_id IN (@groupsuserbelongsto) 
              AND profiles.userid = longdescs.who 
              AND longdescs.bug_id = $id 

Of course the UI would need changing in bug_form to have a separate set of 
checkboxes near the add comment text box for selecting which groups can see the 
new comment. There is a chance that the bug_form could become more cluttered 
than it currently is. Plus there would need to be a method for editing comments so 
that an old comment can have it s groupset changed to be made public, etc.
I think this was a feature in the Loki fork of Bugzilla.
Priority: -- → P3
Target Milestone: --- → Future
From looking through the code available from Loki's site, they take a pretty
simplistic approach to this. The basically added an additional column to the
comments table called 'private'. Then when a person checks the private checkbox
located next to the comment box, it puts a 1 value in the private column. They
have a permission group called 'userisprivileged' that allows only members of
that group or the comment submitter to see the comment if the comment is marked
private. I imagine all employees of Loki are added to that group.
The 99% case for this bug is that of a company which wants some comments to be
private, e.g. by matching the login name against a regexp - i.e. the case that
the Loki fork covered. 

The advantage of the simplistic approach is that it is simple to implement,
simple to configure (a single param for the regexp) and simple to understand. It
also doesn't require extra DB accesses. If we are instead going to do the
groupset thing, we need to think very hard about how we can make it, in the
standard case, as simple as this. I'm wary that we'll end up with something
wonderfully configurable, but too complex to be usable, and which slows things down.


Comment 7

17 years ago
This is done in bug 143826.
Please reopen if not sufficient

*** This bug has been marked as a duplicate of 143826 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
removing target milestone from WONTFIX/INVALID/WORKSFORME/DUPLICATE bugs so
they'll show up as untriaged if they get reopened.
Target Milestone: Future → ---
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.