Remove the 'useentrygroupdefault' parameter

RESOLVED FIXED in Bugzilla 3.6

Status

()

P2
enhancement
RESOLVED FIXED
10 years ago
5 years ago

People

(Reporter: LpSolit, Assigned: LpSolit)

Tracking

3.3.3
Bugzilla 3.6
Dependency tree / graph
Bug Flags:
approval +

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

10 years ago
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.

Updated

10 years ago
Priority: -- → P2
Blocks: 469186
Blocks: 355870
(Assignee)

Comment 1

10 years ago
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?
Assignee: administration → LpSolit
Status: NEW → ASSIGNED
Attachment #365055 - Flags: review?(mkanat)
Attachment #365055 - Flags: review?(bugreport)

Comment 2

10 years ago
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-
(Assignee)

Comment 3

10 years ago
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.
Attachment #365055 - Attachment is obsolete: true
Attachment #365240 - Flags: review?(mkanat)
Attachment #365055 - Flags: review?(bugreport)

Updated

10 years ago
Attachment #365240 - Flags: review?(mkanat) → review+

Comment 4

10 years ago
Comment on attachment 365240 [details] [diff] [review]
patch, v2

Nice, thanks for also doing the canedit thing!

Comment 5

10 years ago
We should give membercontrol and othercontrol defaults, too, in another bug.
Flags: approval?

Updated

10 years ago
Flags: approval? → approval+
(Assignee)

Comment 6

10 years ago
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

Updated

10 years ago
Keywords: relnote

Comment 7

9 years ago
Added to the release notes in bug 547466.
Keywords: relnote
Blocks: 561379
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?
(Assignee)

Comment 9

5 years ago
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.