User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR 1.0.3705) Build Identifier: from the comments at the head of the source, this has become apparent. # ATTENTION!!!! THIS FILE ONLY CONTAINS THE DEFAULTS. # You cannot change your live settings by editing this file. # Only adding new parameters is done here. Once the parameter exists, you # must use %baseurl%/editparams.cgi from the web to edit the settings. # This file is included via |do|, mainly because of circular dependancy issues # (such as globals.pl -> Bugzilla::Config -> this -> Bugzilla::Config) # which preclude compile time loading. # Those issues may go away at some point, and the contents of this file # moved somewhere else. Please try to avoid more dependancies from here # to other code # (Note that these aren't just added directly to Bugzilla::Config, because # the backend prefs code is separate to this...) xml form would be a more logical format for storage. see bug 188570 and the chatter on the developer list in regards to integration of bugzilla. Reproducible: Always Steps to Reproduce:
kinda like this... <ParamList> <param name='maintainer' type='t'> <desc>The email address of the person who maintains this installation of Bugzilla.</desc> <default>THE MAINTAINER HAS NOT YET BEEN SET</default> </param> <param name='urlbase' type='t' checker='check_urlbase'> <desc>The URL that is the common initial leading part of all Bugzilla URLs.</desc> <default>http://you-havent-visited-editparams.cgi-yet/</default> </param> <param name='languages' type='t'> <desc>A comma-separated list of RFC 1766 language tags. These identify the languages in which you wish Bugzilla output to be displayed. Note that you must install the appropriate language pack before adding a language to this Param. The language used is the one in this list with the highest q-value in the user's Accept-Language header.</desc> <default>en</default> </param> <param name='newchangedmail' type='l'> <desc>The email that gets sent to people when a bug changes. Within this text, %to% gets replaced with the e-mail address of the person recieving the mail. %bugid% gets replaced by the bug number. %diffs% gets replaced with what\'s changed. %neworchanged% is "New:" if this mail is reporting a new bug or empty if changes were made to an existing one. %summary% gets replaced by the summary of this bug. %reasonsheader% is replaced by an abbreviated list of reasons why the user is getting the email, suitable for use in an email header (such as X-Bugzilla-Reason). %reasonsbody% is replaced by text that explains why the user is getting the email in more user friendly text than %reasonsheader%. %<i>anythingelse</i>% gets replaced by the definition of that parameter (as defined on this page).</desc> <default>From: bugzilla-daemon To: %to% Subject: [Bug %bugid%] %neworchanged%%summary% X-Bugzilla-Reason: %reasonsheader% %urlbase%show_bug.cgi?id=%bugid% %diffs% --%space% Configure bugmail: %urlbase%userprefs.cgi?tab=email %reasonsbody%</default> </param> </ParamList>
Just more items to think about.... how would the check routines be declared? Several of the params have validity checks specific to those params which are defined as part of the params hash.
The other question to ask is what benefit do we get from defining it as XML? Parsing XML from Perl is a pain in the butt. (Just look at all the convoluted code in importxml.pl :) A hash table is every bit as organized, and it loads a hell of a lot faster in Perl.
You could handle validity by declaring a type, and doing the checking in Perl. I also don't see much advantage to doing this, other than the buzzword-compliance.
wontfix, in deference to bug 46296's pluggable perl modules+templates implementation