Per our discussion on reviewers@ and on IRC, the useentrygroupdefault parameter should go away. It's confusing, nobody really knows why it's here (except joel) and what it's supposed to do.
Created attachment 365055 [details] [diff] [review] patch, v1 joel, want to give a look at my patch too as you are the one who implemented this parameter?
Comment on attachment 365055 [details] [diff] [review] patch, v1 This looks generally fine to me--pretty straightforward. However, "entry" needs a DB default of 0 in the schema--currently it has no default, so leaving it out of INSERTs will throw an error in Pg. After this is done, in Product.pm, just remove "entry" from the INSERT and let the DB choose the default.
Attachment #365055 - Flags: review?(mkanat) → review-
Created attachment 365240 [details] [diff] [review] patch, v2 My previous patch was correct, as discussed on IRC. But here is the DB schema change anyway. While I was on it, I set a default value for canedit too.
Comment on attachment 365240 [details] [diff] [review] patch, v2 Nice, thanks for also doing the canedit thing!
We should give membercontrol and othercontrol defaults, too, in another bug.
Checking in editgroups.cgi; /cvsroot/mozilla/webtools/bugzilla/editgroups.cgi,v <-- editgroups.cgi new revision: 1.91; previous revision: 1.90 done Checking in sanitycheck.cgi; /cvsroot/mozilla/webtools/bugzilla/sanitycheck.cgi,v <-- sanitycheck.cgi new revision: 1.144; previous revision: 1.143 done Checking in Bugzilla/Config.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config.pm,v <-- Config.pm new revision: 1.77; previous revision: 1.76 done Checking in Bugzilla/Product.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Product.pm,v <-- Product.pm new revision: 1.35; previous revision: 1.34 done Checking in Bugzilla/User.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/User.pm,v <-- User.pm new revision: 1.179; previous revision: 1.178 done Checking in Bugzilla/Config/GroupSecurity.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/GroupSecurity.pm,v <-- GroupSecurity.pm new revision: 1.9; previous revision: 1.8 done Checking in Bugzilla/DB/Schema.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/DB/Schema.pm,v <-- Schema.pm new revision: 1.113; previous revision: 1.112 done Checking in Bugzilla/Install/DB.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/DB.pm,v <-- DB.pm new revision: 1.62; previous revision: 1.61 done Checking in docs/en/xml/administration.xml; /cvsroot/mozilla/webtools/bugzilla/docs/en/xml/administration.xml,v <-- administration.xml new revision: 1.94; previous revision: 1.93 done Checking in template/en/default/admin/params/groupsecurity.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/groupsecurity.html.tmpl,v <-- groupsecurity.html.tmpl new revision: 1.7; previous revision: 1.6 done
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Added to the release notes in bug 547466.
Prezados, Após a remoção deste parametro não consigo mais restringir a visualização dos produtos pelo grupo de usuários. Existe uma nova forma de fazer esta restrição?
When creating a new product, you are free to edit group settings to match your needs. So it's still possible to restrict the visibility of bugs. Next time, ask your question in english, please.
Created attachment 739560 [details] Simulation bug 478972 Frédéric, We met the possibility to edit the group in question and to inform other groups which are members of this group. But this way of restricting the display of products / projects is not working. Here attached a document with step-by-step to understand the problem better.
Frédéric, Correction, the image of the first step consider the parameter'''' makeproductgroups as 'On'.
Frédéric, New observation, the parameter 'usevisibilitygroups' as is 'ON' too.
You need to log in before you can comment on or make changes to this bug.