It appears very clearly that admins are very confused with our current product group controls, including admins from major Bugzilla installations such as GNOME and Mozilla (yes, bmo!). Even most core Bugzilla developers are in the dust when talking about group security. There are several problems: there are products you can see (depending on MemberControl/OtherControl), products you can report bugs into (Entry), products you can edit bugs being into (Canedit), products which require you to restrict bugs to some group(s) (Mandatory/Mandatory), products which let you restrict bugs to some group(s) (Shown/* or Default/*), products which do not let you restrict bugs to some group(s) when you are not a member (*/NA) or for everybody (NA/NA), etc... This brings so much complexity that admins either configure their Bugzilla incorrectly or do not try to use groups at all. Security is a major aspect of an application, and Bugzilla is by far not intuitive in that area; I even myself have to look at the source code from time to time to correctly understand how things work (from a dev point of view, we also have too many product and user methods related to group restrictions and product visibility, which is then prone to trigger errors when writing new code). It's high time to simplify the way security works in Bugzilla, even if this means removing some use cases which are never or rarely used. Security management should be easy before being powerful (synonym of complex)! The first step should be to merge the MemberControl and OtherControl settings into a single one. My initial proposal was to decrease the number of options from the current 9 ones to only 4: Public = NA/NA Default Public = Shown/Shown Default Private = Default/Default Private = Mandatory/Mandatory justdave made a good point that Public and Private could be confusing as you can have several groups involved for a single product. Maybe Public should be reworded to "No restriction" and Private to "Always restricted". Also, some use cases I asked to some admins show that: - we should let members only restrict a bug to their own groups (currently set by */NA). - we should let products be either publicly visible to everybody, or only visible to members of some groups. Based on this feedback, my proposal would now be to have a single setting (resulting of the merge of MemberControl and OtherControl), but with the following options: Restricted to this group: ======================== - Never - Allowed to group members only (default: not restricted) - Allowed to group members only (default: restricted) - Allowed to everybody (default: not restricted) - Allowed to everybody (default: restricted) - Always So compared to the current options, I removed the 3 following ones: Shown/Mandatory, Default/Mandatory and Shown/Default. Also, it would be interesting to know if the default "restricted" is often used or not, or if we can reasonably assume that default "not restricted" is always wanted, which would let us reduce the list of options to 4 only.
(In reply to comment #0) > - we should let products be either publicly visible to everybody, or only > visible to members of some groups. My proposal from comment 0 doesn't handle this yet. It would behave as it is now. This use case will probably be fixed in a separate bug.
We are going to branch for Bugzilla 4.4 next week and this bug is too invasive or too risky to be accepted for 4.4 at this point. The target milestone is set to 5.0 which is our next major release. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else on time for 5.0.
Created attachment 668786 [details] New UI, v1 Based on the discussion we had per email last year, here is the new UI I propose to manage group restrictions. It takes much more space than the old UI, but I hope it's also clearer. Please give me as much feedback as possible, especially if you are a Bugzilla administrator.
Just in case you are wondering, I rewrote the whole page instead of only the options available for the MemberControl/OtherControl select fields, because it appeared that the confusion to configure security for products was much greater than just renaming these options.
A few thoughts: The width of the drop down should be widened. brc (Red Hat Bugzilla) have a lot of groups named "Red Hat xxxxx", and the current width wouldn't be wide enough to show the group name. bmo has over 100 groups, brc has 199 groups. Showing that in a drop down list is very awkward. The big issue though is brc have many products that have one or more groups as default and one or more groups as available, but not default (Default/NA and Shown/NA in the old language). We also have products that are have both Shown/NA (e.g. 'Red Hat Employees') and Shown/Shown (e.g. 'Security Sensitive issue') and that doesn't seem to be an option with the new screen either. Suggestion: If the group_control_map table is not changing, provide both this screen and the old screen (via and 'Advanced settings' link or something) for more complex configuration. -- simon
(In reply to Simon Green from comment #5) > The width of the drop down should be widened. brc (Red Hat Bugzilla) have a > lot of groups named "Red Hat xxxxx", and the current width wouldn't be wide > enough to show the group name. The width of the drop-down is automatically defined by the largest item in the list; it's not hardcoded. > bmo has over 100 groups, brc has 199 groups. Showing that in a drop down > list is very awkward. What do you suggest? And how is it worse than displaying 1000 products in a drop-down in query.cgi? > The big issue though is brc have many products that have one or more groups > as default and one or more groups as available, but not default (Default/NA > and Shown/NA in the old language). > > We also have products that are have both Shown/NA (e.g. 'Red Hat Employees') > and Shown/Shown (e.g. 'Security Sensitive issue') and that doesn't seem to > be an option with the new screen either. You obviously didn't click the "Custom" radio button. > Suggestion: If the group_control_map table is not changing, provide both > this screen and the old screen (via and 'Advanced settings' link or > something) for more complex configuration. You obviously didn't click the "Custom" radio button (bis).
(In reply to Frédéric Buclin from comment #6) > > bmo has over 100 groups, brc has 199 groups. Showing that in a drop down > > list is very awkward. > > What do you suggest? And how is it worse than displaying 1000 products in a > drop-down in query.cgi? My suggestion was the last paragraph in comment #5. > > > The big issue though is brc have many products that have one or more groups > > as default and one or more groups as available, but not default (Default/NA > > and Shown/NA in the old language). > > > > We also have products that are have both Shown/NA (e.g. 'Red Hat Employees') > > and Shown/Shown (e.g. 'Security Sensitive issue') and that doesn't seem to > > be an option with the new screen either. > > You obviously didn't click the "Custom" radio button. Oops. I didn't realise that the page was not just a static image. I agree that the custom radio button would solve these two issues. > > Suggestion: If the group_control_map table is not changing, provide both > > this screen and the old screen (via and 'Advanced settings' link or > > something) for more complex configuration. > > You obviously didn't click the "Custom" radio button (bis). I still think this is a good option (providing the group_control_map table is not changing) because a) the page has already been written and b) it makes it easier when there are hundreds of groups involved. Having said that, if we don't keep the old page, this won't be a show stopper (IMO) -- simon
Comment on attachment 668786 [details] New UI, v1 this looks excellent, well done. there are a few minor issues that i'd to see addressed, but no show stoppers. the "Who can file bugs in this product?" are not clear enough; perhaps the left margin on child elements of these rows needs to be increased. i think it would greatly improve the page is rows are hidden until the radio button controlling them is checked. basically extend what you did for 'custom' across the page. eg. don't show the restricted controls unless restricted is checked; don't show available/selected groups if everybody or nobody is selected.
I think the new UI is also excellent in concept, and light-years ahead of the current one, but there are a few organizational tweaks which would make it more understandable. 1) The initial title doesn't cover all the page does; I think "Edit Access Controls for Product 'TestProduct'" is a fine title and should be used. 2) I'd like to see sharper subheadings used. So "Filing Bugs" "Editing Bugs" "Administration" 3) The "Confidential" line is lost; it should probably go above "Restricted" to keep the 3 choices together. In fact, there are several radios where this is the case. E.g. "everybody" and "nobody" should come before "only...", which has much more complex associated UI. 4) The difference between Confidential and Restricted is not clear It would also be nice to have some way of putting a bit more separation between the control title and the explanatory text. But, as I said, generally awesome :-) Gerv
Great job!!! its took me long time to configure my currently security settings as still i cant do all I wanted. In this new setting , how I set the product to be read only ? I can set it to restricted so only selected users can file bugs but does it say that other users can view the bugs? This exactly what I cant do with Bugzila 4.2. ..
(In reply to gidelson from comment #10) > In this new setting , how I set the product to be read only ? In the "Control who can edit bugs in this product" section, click "Restricted" and leave the list empty.
Created attachment 734632 [details] [diff] [review] patch, v1
Comment on attachment 734632 [details] [diff] [review] patch, v1 > my $bug_ids = $product->bug_ids(); >+ my $bug_ids = $product->bugs_in_group($group); Surprised that passed warning tests!
(In reply to Reed Loden [:reed] from comment #13) > Surprised that passed warning tests! Tss... this is in POD!
Created attachment 734654 [details] [diff] [review] patch, v1.1 Use YAHOO.util.Dom.addClass and YAHOO.util.Dom.removeClass directly instead of bz_addClass and bz_removeClass.
Hello, Frédéric and all, Thank you for this very good work. I have been admin of a bugzilla installation at Telefonica for years and this part has never been very clear to me, honestly. The new UI looks very good. In our case, we have hundreds of products created by a few tens of employees from different countries. These users have the right to create new products, but they are not experts. Our wish is that the administrators can configure a "default setting" for product group controls for new products. This way, the people creating new products doesn't need to modify these settings and we would avoid mistakes. For example, in the current configuration, our preferred default setting would be "Mandatory/Mandatory, ENTRY" for all new products for its own group, and "NA/NA" for all the other groups. It would be great if some default configuration can be created by the admins in the next version when these changes are made available. But I understand that this is a bit different topic and probably should be in a different bug. Thank you!
Comment on attachment 734654 [details] [diff] [review] patch, v1.1 Review of attachment 734654 [details] [diff] [review]: ----------------------------------------------------------------- just a review of the ui: - there's no reason to use a table to lay this out, use divs/spans+css instead - hide the content under the top-level radio buttons until that button is selected - eg. if 'public' is selected, don't show any of the 'restricted' controls - 'who can edit bugs' -> 'default' : anyone can also set flags, so the blurb needs to include that - the checkboxes such as 'Restrict new bugs to these selected groups by default' should be left aligned (not centered) - select headings such as 'Available Groups' should not be the same size as the main headings - move the select for 'Confidential' to underneath it, instead of putting it on the same line as the header
How would an admin add private subgroups within a product? For example, with a company selling a single product to competing companies, and you don't want them to see each others bug reports, user accounts etc. I currently have a set-up with one product, multiple client groups, and one internal group that is a member of all the client groups. With this set-up each client can see all the bugs their company has supported, but none of the other clients' bugs. How would you accomplish this with the proposed layout?
The proposed layout doesn't change the way Bugzilla works.
Not positive that we absolutely need this for 5.0, but marking it on the roadmap for now.