There's currently quite a number of edit*.cgi files. We should put in some effort to unify them. I first came across this in the work for customised resolutions (bug #94534). I based editresolutions.cgi off editkeywords.cgi. As I was making the changes necessary it became obvious that there weren't that many real differences, and I would be doing the code base a great disservice if I didn't refactor the code to support both. So refactored code will be landing as a part of the bug and we will want to move editkeywords.cgi to use it. This will also give us most of the support for "inactive keywords" for free, since I have written this for resolutions. Resolutions and keywords have a similar schema. There are the fields "id", "name" & "description" (and soon "isactive"). This makes the code easier, so we may wish to modify the schema in other places to aid this effort. So anyway, this code neither supports product specific fields, nor sortkeys, although I intend to support the latter for moving priorities and stuff into the database during 2.16. On the other hand, editmilestones, and I believe Myk's new attachment status editing code, doesn't support inactive, but supports sortkeys and product specificity. Myk says he created an all new cgi, and my question is just how much difference there is between the two (and indeed versions). Are we getting dizzy yet? So how far can we, or should we unify? That really depends on what features we expect. Personally, I think everything should support isactive. Most things should support sortkey. Possibly all things should be product specific, but what if the admin doesn't want them to be? So basically, we need to look at where we want to be. If we did something like bug #69262 for all types of thing, we could eventually have just one cgi. Or if not, we could have one product specific and one global mechanism, optionally supporting sortkeys and inactive. So basically, the following are within the scope of this: keywords, resolutions, milestones, versions, components, attachment statuses, priorities, operating systems, platforms, severities. Groups and users maybe eventually within the scope of this, but likely not.

I was being a bit loose above. I'm not necessarily suggesting we have one .cgi, but we should have one .pl or .pm that gets call by the cgis who pass the parameters about how they're different than usual.

Different cgis support different lengths for the name field, which isn't a major problem, but we should make sure that globals.pl and checksetup.pl uses constants rather than numeric literals for these so they can be shared.

Mine.

This will templatise all the CGIs that are touched, so hanging this off dep bug.

matty: are you saying that we shouldn't templatise edit*.cgi because you will unify them and templatise at the same time? Gerv

That is correct: admineditor.pl on the CUST_RES_BRANCH uses templates.

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.

breaking dependency on bug 86168, because a) this is all admin utilities, and is mostly not customer-visible stuff, so I don't feel so bad about it not making it into 2.16 b) bug 86168 is a release blocker for 2.16, and Matty's already stated this isn't going to make it on time.

MattyT: what's the status here? This is a must-have for 2.18 (well, the templatisation part is), and I'm worried that it'll take a long time to do. Gerv

This will start with bug #69267 sometime soon.

There is some discussion in bug#190226 about generalisations in all the edit*.cgi scripts

Breaking dependency on cust_res. If someone steps to the plate with chunks of code for that, it'll be looked at by lots of eyes. While some of the admin edit* cgis will no doubt need to be tweaked and extended once cust_res is in place, it does not block this; the mutual blockage/targetting of 2.18 is enough. I can't decide whether this bug blocks or is blocked by the templatization efforts of admin scripts; to be done right, they're tied at the hip, but I'm loathe to put faux dependencies out there that would be irrelevant when and if the next person picks this up. Adding dep of 190226 as that is where a good bit of the discussion as to generalizing the admin interface is, and will continue to be, apparently.

Taking Jake's bugs... his Army Reserve unit has been deployed.

Enhancements which don't currently have patches on them which are targetted at 2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. Consideration will be taken for moving items back to 2.18 on a case-by-case basis (but is unlikely for enhancements)

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.

As far as I can say, we don't plan or even want to have a single CGI script for all administrative pages. One reason could be that they all require different privs to access them. Also, they all have their specific attributes and checks, and those being similar enough can already be edited from editvalues.cgi. What we are doing instead is to centralize code into Bugzilla/Object.pm and other Perl modules, see bug 355838, which is a much better approach IMO.