Closed
Bug 364216
Opened 18 years ago
Closed 18 years ago
Flag::retarget() is broken
Categories
(Bugzilla :: Attachments & Requests, defect)
Tracking
()
RESOLVED
FIXED
Bugzilla 3.0
People
(Reporter: LpSolit, Assigned: LpSolit)
References
Details
(Keywords: dataloss, selenium)
Attachments
(2 files)
3.83 KB,
patch
|
myk
:
review+
|
Details | Diff | Splinter Review |
8.96 KB,
patch
|
myk
:
review+
|
Details | Diff | Splinter Review |
Flag::retarget() contains these lines: _validate($flag, $flag->type, $flag->status, $flag->setter, $requestee, $is_private); which doesn't match what _validate() expects: sub _validate { my ($flag, $flag_type, $status, $requestees, $private_attachment, $bug_id, $attach_id) = @_; The last two arguments are optional, so this is fine. The problem is $flag->setter which should not be here. Or said otherwise, maybe it should be here, but _validate() always assumes the flag setter is Bugzilla->user.
Assignee | ||
Comment 1•18 years ago
|
||
This must be fixed before we release 2.23.4, or 3.0 RC1 at the latest.
Status: NEW → ASSIGNED
Flags: blocking3.0?
Comment 2•18 years ago
|
||
Yes, this is major enough to be a blocker, since it can cause dataloss.
Flags: blocking3.0? → blocking3.0+
Keywords: dataloss
Assignee | ||
Comment 3•18 years ago
|
||
While fixing this bug, I realized that Flag::target() itself was broken. The call to _validate() is only one part of the problem.
Summary: Flag::_validate() called with wrong arguments when retargetting flags → Flag::retarget() is broken
Assignee | ||
Comment 4•18 years ago
|
||
Attachment #249242 -
Flags: review?(myk)
Comment 5•18 years ago
|
||
Comment on attachment 249242 [details] [diff] [review] patch, v1 This seems reasonable and correct. r=myk
Attachment #249242 -
Flags: review?(myk) → review+
Assignee | ||
Updated•18 years ago
|
Flags: approval?
Updated•18 years ago
|
Flags: approval? → approval+
Assignee | ||
Comment 6•18 years ago
|
||
Checking in Bugzilla/Flag.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Flag.pm,v <-- Flag.pm new revision: 1.79; previous revision: 1.78 done
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 7•18 years ago
|
||
Wow, I forgot to retarget attachment flags. And I realized that there are bugs in the code anyway. Reopening!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 8•18 years ago
|
||
I hope this fixes all issues.
Attachment #250359 -
Flags: review?(myk)
Comment 9•18 years ago
|
||
Comment on attachment 250359 [details] [diff] [review] patch (part 2), v1 >+ my $flags = Bugzilla::Flag->new_from_list($flag_ids); >+ foreach my $flag (@$flags) { >+ my $is_retargetted = retarget($flag, $bug); >+ clear($flag, $bug, $flag->attachment) unless $is_retargetted; I wonder if there's a way to not have to define a temporary variable here, i.e. something like: foreach my $flag (@{Bugzilla::Flag->new_from_list($flag_ids)}) { my $is_retargetted = retarget($flag, $bug); clear($flag, $bug, $flag->attachment) unless $is_retargetted; Otherwise this looks good. r=myk
Attachment #250359 -
Flags: review?(myk) → review+
Assignee | ||
Comment 10•18 years ago
|
||
Checking in editflagtypes.cgi; /cvsroot/mozilla/webtools/bugzilla/editflagtypes.cgi,v <-- editflagtypes.cgi new revision: 1.49; previous revision: 1.48 done Checking in Bugzilla/Flag.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Flag.pm,v <-- Flag.pm new revision: 1.80; previous revision: 1.79 done
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•