17 years ago
5 years ago


(Reporter: Jacob Steenhagen, Assigned: Jacob Steenhagen)


Bugzilla 2.16



(2 attachments)



17 years ago
In the course of fixing bug 71552 it came up that when a Param is removed from 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 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
 There was a question on IRC how requiring would react w/out having 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 and outputs the 
Target Milestone: --- → Bugzilla 2.14

Comment 4

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

Comment 5

17 years ago
Created attachment 37557 [details] [diff] [review]
Possible fix

Comment 6

17 years ago
I was thinking about this the other day and came up with the idea that instead
of adding the support for to delete params, it might be better to
just make WriteParams() delete any param that isn't defined in 
Then in order to remove a param, all you need to do is delete the definition out
of (which you have to do anyway so it doesn't show up on
Assignee: tara → jake
Keywords: patch, review

Comment 7

17 years ago
Created attachment 37560 [details] [diff] [review]
Remove 'nummilestones' param

Comment 8

17 years ago
The second patch is to remove 'nummilestones' from  '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 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

Comment 11

17 years ago
Also in the " 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.


17 years ago


17 years ago
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)?

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.
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
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.