Closed Bug 344968 Opened 18 years ago Closed 17 years ago

Workflow Centralization: importxml.pl

Categories

(Bugzilla :: Bugzilla-General, enhancement)

2.23
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 3.2

People

(Reporter: karl, Assigned: LpSolit)

References

Details

Attachments

(1 file, 1 obsolete file)

importxml.pl is a pretty special script, and it seems to stand alone, so that's where I'll keep it. For this script, I'll need to make sure the following question is properly handled: "For an incoming bug, is the status of the bug
is the status of the bug...?
(In reply to comment #1) > is the status of the bug...? > (grumble grumble) The question should read "Is the status of the bug being imported a status that is used by the workflow of the bug's product?" For example, if a bug being imported has a status that isn't being used by the workflow, then there won't be any way to change the state of the bug; there also would be no way to infer how that bug got into that state in the first place.
Blocks: 345100
Group: webtools-security
Target Milestone: Bugzilla 3.0 → Bugzilla 2.24
Looks like Firefox did some strange selecting of the group radio boxes on the mass-change page when I clicked refresh in my browser before that last mass-change. This is not really a security bug. :-)
Group: webtools-security
This bug is retargetted to Bugzilla 3.2 for one of the following reasons: - it has no assignee (except the default one) - we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1) - it's not a blocker If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0. If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug. If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
Assignee: karl → LpSolit
Attached patch patch, v1 (obsolete) (deleted) — Splinter Review
I removed the code about changing the status back to NEW if the original assignee doesn't exist in the target installation. I think it doesn't make sense and allows us to remove one hardcoded bug status. This is the last step for the workflow implementation.
Attachment #266225 - Flags: review?(mkanat)
Attachment #266225 - Flags: review?(ghendricks)
Comment on attachment 266225 [details] [diff] [review] patch, v1 >- if($changed_owner){ >- if($everconfirmed){ >- $status = "NEW"; >- } >- else{ >- $status = "UNCONFIRMED"; >- } >- if ($status ne $bug_fields{'bug_status'}){ >- $err .= "Bug reassigned, setting status to \"$status\".\n"; >- $err .= " Previous status was \""; >- $err .= $bug_fields{'bug_status'} . "\".\n"; >- } >- } The point of $changed_owner is, if the original owner does not have an account in this bugzilla, we need to reassign it to someone who can decide what to do with it. We change the status so that it will show up in their "My Bugs" search. Perhaps we should have a status for "REVIEW" or something like that? Until we have some other way of notifying users that they have a new set of bugs, I think we need to keep this.
Attachment #266225 - Flags: review?(ghendricks) → review-
Attached patch patch, v2 (deleted) — Splinter Review
Attachment #266225 - Attachment is obsolete: true
Attachment #266482 - Flags: review?(ghendricks)
Attachment #266225 - Flags: review?(mkanat)
Attachment #266482 - Flags: review?(ghendricks) → review+
Flags: approval?
Checking in importxml.pl; /cvsroot/mozilla/webtools/bugzilla/importxml.pl,v <-- importxml.pl new revision: 1.76; previous revision: 1.75 done
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: approval? → approval+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: