Closed Bug 97706 Opened 23 years ago Closed 17 years ago

Refactor edit*.cgi.

Categories

(Bugzilla :: Administration, task, P3)

2.15

Tracking

()

RESOLVED WONTFIX

People

(Reporter: CodeMachine, Unassigned)

References

(Depends on 1 open bug)

Details

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.
Depends on: 65317, 69267, bz-custres
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.
Summary: Unify edit*.cgi. → Refactor edit*.cgi.
Mine.
Assignee: justdave → matty
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.16
Status: NEW → ASSIGNED
Depends on: 77193
QA Contact: matty → jake
Depends on: 62551
This will templatise all the CGIs that are touched, so hanging this off dep bug.
Blocks: bz-template
Depends on: 67375
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.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
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.
No longer blocks: bz-template
No longer depends on: 62551
Depends on: 146104
No longer depends on: 67375
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.
Depends on: 190226
No longer depends on: bz-custres
Taking Jake's bugs...  his Army Reserve unit has been deployed.
QA Contact: jake → justdave
Severity: normal → enhancement
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)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
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.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Target Milestone: Bugzilla 2.22 → ---
Assignee: mattyt-bugzilla → administration
Status: ASSIGNED → NEW
QA Contact: justdave → default-qa
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.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
No longer depends on: 69267
You need to log in before you can comment on or make changes to this bug.