briareos@lokigames.com wrote: > > Can anyone tell me if there is support currently, or planned for the > future, on private comments for Bugzilla? > > If not, would it be along the lines of: > > - having an additional field in the bugs table called "private" > - an additional "where private = ...' clause in select statements > - having some differnet colors for private comments in HTML generation > by CGI scripts > - an additional field in the groupset indicating the right to view > private comments > > Thoughts, etc., appreciated, > I agree that this would be a great feature for site which are less "open" than Mozilla. :-) If I were implementing it, I would separate follow-on comments from the bug description and keep them in a separate table. I would have a private flag with each comment. When entering the comment, a checkbox would indicate whether the comment was private. When displaying the bug, private comments would not be displayed unless the proper groupset was enabled. Implementing this way allows comments, both private and public, would be handled the same way. Thus enhancements to one type would be simultaneously made to the other.

I'm adding my LONG diatribe about private comments and priveleges: briareos@lokigames.com wrote: > > Mark B. Hamby <mhamby@logicon.com> wrote: > > modification priveleges before starting. Bugzilla's > > 'groups' table is a flawed initial attempt at > > priveleges. Redhat had a better approach, IMHO. > > Which is? I haven't looked at exactly how the "groupset" field in the > "profiles" table is handled, but bit switches are sort of yucky (but > easy). > > Hand in hand with this is a discussion on how to keep private comments > private--hardening the Bugzilla process. This is touched on a bit at > the end of the README but not fully enough for my tastes. Is the only > database entry point through the connect call in globals.pl? Is it any > safer to give the bugs account a password and use it there? It seems > that anyone can just load up the globals.pl file sitting there. Is > there a way to turn that sort of functionality off using permissions > or Apache? > Concerning your comments above, I am certainly don't have the time (or the smarts) to make Bugzilla absolutely secure. I often work in a government classfied, so I am familiar with most of the issues. Too much trouble, IMHO. As many security features as possible should be incorporated, but I am primarily concerned about keeping the average Joe out of bugs and comments that he doesn't need to see. If he is a real hacker, he can probably get through a system like Bugzilla anyway unless you were very specific (read "inflexible") in your installation. The current Bugzilla implementation (as I understand it) uses the 'groups' table to store bit-identified priveleges. There are two kinds. The first is a set of priveleges which is used throughout the code to allow modification access to certain system administration features. These are loaded into the 'groups' table in the makegroupstable.sh script, but are not groups at all. The second type of group priveleges are actual groups that can be added to the 'groups' table and the 'isbuggroup' field set to indicate that the group is, in fact, a group. These groups are used with the 'groupset' field in the 'bugs' table to allow viewing access to bugs which have the 'groupset' column set. Only people in the 'profiles' table whose group bits match the 'groupset' field in a bug can view that bug. The problem is that any fool can set the bug as viewable only by a certain group. And any fool can alter just about any field in a bug. That's bad. I do not really see the need for having the 'groupset' in the bugs table like Bugzilla has now. There should only be a 'private' field. The idea of several groups which can see the bug or not is strange. IMHO, there should be a view_private_bugs privelege. You either have it or you don't. A bug is marked private or it isn't. None of this "well, these groups can see it and these groups can't." The bug can be marked private by the author when he generates it or by a person with priveleges to set this field. The private field for bugs would apply to the entire bug. For comments, I suggest having creating a 'comments' table. New comments are added to that table with the bug id, instead of being appended to the bug's description as they are now. The 'comments' table would also have a 'private' field. When someone enters a comment, he clicks on the "Private" toggle to mark it as private. Thus non-private bugs could have private coments. Only users with view_private_comments privelege could see that comment. (Or perhaps there is just one privelege 'view_private' which applies to bugs and comments.) When I get a free evening, I will try to implement this private comment enhancement. (My wife wants to see my at night...go figure. :-) Attachments should have a private feature as well. Have you looked at Redhat's version of Bugzilla? There was a short discussion about it a few days ago. They have a better access system than the Mozilla version, IMHO. Unfortunately, they made a lot of other changes that prevent the access mods from being easily merged in. Redhat's version (as I understand it) uses a group table to set privelages based on a particular group. Every user belongs to a group. There is also a default group. This implementation allows the management of priveleges to work more like unix user groups. Instead of each user having a set of privelege bits, the user belongs to a group which has privelege bits. A little cleaner, IMHO. (Notice how I try to keep from pissing anyone off. :-) I guess you could implement a scheme which had user privelege bits and a group. In the RH version, every bug field is has a privelege bit (in a different table that I do not remember the name of). These bits determine if a user/group can modify a field in the bug. The RH concept could be expanded to a read/write priveleges. So that a bug or each of its fields, could be readable and/or writable, depending on your privelege bits. The read privelege would really only be useful to a few bug fields like the entire bug, attachments, and comments. So implementing a generic system may be nice in the long haul, but may be much more time consuming. On the other hand, wouldn't it be nice to hide the bug priorities from certain people. :-) One last issue which is likely to be slightly controversial. I believe that private bugs, comments, and attachements should show up in bug listings even if the contents is not shown. Thus a list of bugs would show that bug #234 is private and have not link to it. The user could not get to it, but would still knowit exists. There is nothing more disconcerting than having a bug that you know exists not show up on a report. The same should be true for comments. Even if the comment is not shown, there should still be some indication that a private comment was entered on a particular date. Hey, let's go wild and have a 'view_private_indications' privelege. :-) Any better/opposing/alternative views or implementations are welcome. Please tell me if you are working on this, because I may be working on it as well. I'll let you know if I do. I would like to get all requirements, ideas, and implementation help that I can get. Gees, have I really written this much? I could have done the damn thing in this time. And it's Friday, no less. I'm going home. My kids are coming this weekend for the Summer, so I don't think I'm going to give Bugzilla another thought until Tuesday. :-) But feel free to code this up for me if you get ambitious. :-)

tara@tequilarista.org is the new owner of Bugzilla and Bonsai. (For details, see my posting in netscape.public.mozilla.webtools, news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)

Bringing this to 3.0 for consideration there.

The Bugzilla 3 component is going away. We're going to depend on the Milestones for this. At the time this component was created, we didn't have milestones for Bugzilla.

New product: bugzilla.

dup of bug 143826 ?

Yep. Gerv *** This bug has been marked as a duplicate of 143826 ***

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

Verified Dupe Sorry for the spam