In the course of fixing bug 71552 it came up that when a Param is removed from defparam.pl it never gets removed from data/params. While this shouldn't cause an problems, it is extra and unneeded stuff floating around. There should be a routine in checksetup.pl that can remove those. Right now the params the need removing are: * newemailtech * newemailtechdefault * changedmail * prettyasciimail Attachment 33631 [details] has the routines that would need to be added to checksetup.pl. There was a question on IRC how requiring defparams.pl would react w/out having globals.pl for the SendSQL routine (even though SendSQL is inside a sub that isn't called by WriteParams).
other params that are stranded: * nummilestones * curmilestone those are handled on a per-product basis now.
By stranded by we mean removed from editparams.cgi but still elsewhere? Cause Dave's params were still on editparams.cgi last time I looked.
by stranded, we mean they're still in editparams.cgi, but nothing anywhere in Bugzilla uses them. Or more accurately, they're still in data/params, since editparams.cgi just reads in data/params and defparams.pl and outputs the results.
The sanitycheck.cgi script could destrand params :) Not critical for 2.14 since it has been this way for a long time, might want to relnote it though. Anyone mind if we make this 2.16?
Target Milestone: Bugzilla 2.14 → Bugzilla 2.16
I was thinking about this the other day and came up with the idea that instead of adding the support for checksetup.pl to delete params, it might be better to just make WriteParams() delete any param that isn't defined in defparams.pl. Then in order to remove a param, all you need to do is delete the definition out of defparams.pl (which you have to do anyway so it doesn't show up on editparams.cgi)
Assignee: tara → jake
Keywords: patch, review
The second patch is to remove 'nummilestones' from defparams.pl. 'curmilestone' is still used inside of reports.cgi (I'd say it's a good bet that it's not used sucessfully, but removing it from defparams.pl while it's still in reports.cgi can have some bad side effects (like 'die "Can't find param named $value";').
I thought reports uses the product "defaultmilestone" field.
Priority: -- → P4
See also bug #65383. Not sure if we should close that one out. We should definitely fix reports for 2.16.
Severity: normal → trivial
Also in the "defparams.pl but nowhere else" are all the despot params (usedespot and the like). So if we aren't going to hack in despot support (which I don't think we are) we should remove those params.
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: Bugzilla 2.12 → 2.12
I'm not sure I agree with this. These could be useful if people want to roll back.
Matthew has a fair point. Are they actually doing any _harm_ (presuming we don't want to reuse a param name)? Gerv
We are currently trying to wrap up Bugzilla 2.16. We are now close enough to release time that anything that wasn't already ranked at P1 isn't going to make the cut. Thus this is being retargetted at 2.18. If you strongly disagree with this retargetting, please comment, however, be aware that we only have about 2 weeks left to review and test anything at this point, and we intend to devote this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
Done as part of bug 104521.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Depends on: 104521
Resolution: --- → FIXED
Bug 126571 is about a bug in the implementation of this fix.
fixing incorrect milestones on fixed bugs.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.16
You need to log in before you can comment on or make changes to this bug.