118738 - Need ability to set groupsets on comments

Status: RESOLVED DUPLICATE of bug 143826

(Bugzilla :: Bugzilla-General, enhancement, P3)

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

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.

Comment 1

[David Lawrence [:dkl]]

This would be very useful for use here at Red Hat also.

Comment 2

[Jacob Steenhagen]

Impimentation Note:
  Be careful when this is done as to not mess up comment numbers.

Comment 3

[David Lawrence [:dkl]]

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.

longdescs_group_map:
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.

Comment 4

[Matthew Tuck [:CodeMachine]]

I think this was a feature in the Loki fork of Bugzilla.

Comment 5

[David Lawrence [:dkl]]

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.

Comment 6

[Gervase Markham [:gerv]]

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.

Gerv

Comment 7

[Joel Peshkin]

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


*** This bug has been marked as a duplicate of 143826 ***

Comment 8

[Dave Miller [:justdave]]

removing target milestone from WONTFIX/INVALID/WORKSFORME/DUPLICATE bugs so
they'll show up as untriaged if they get reopened.