Closed
Bug 266159
Opened 20 years ago
Closed 19 years ago
It's possible to create multiple flags by reloading, even if flag is not multiplicable
Categories
(Bugzilla :: Attachments & Requests, defect)
Bugzilla
Attachments & Requests
Tracking
()
RESOLVED
FIXED
Bugzilla 2.20
People
(Reporter: kiko, Assigned: LpSolit)
References
Details
Attachments
(1 file, 1 obsolete file)
2.83 KB,
patch
|
myk
:
review+
|
Details | Diff | Splinter Review |
It's possible to create multiple flags by reloading, even if flag is not multiplicable. Just create a new flag, and on the confirmation page (Changes to Attachment XXX submitted) reload as many times as you like. We should raise an error saying that there is already a flag of that type associated with that attachment.
Updated•20 years ago
|
Blocks: rt-clean-up
Assignee | ||
Comment 1•19 years ago
|
||
I think the problem comes from Flag::FormToNewFlags() which does not check if non-multiplicable flag types already have a flag set for the given bug/attachment.
Assignee: myk → LpSolit
OS: Linux → All
Hardware: PC → All
Assignee | ||
Updated•19 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•19 years ago
|
||
Attachment #182347 -
Flags: review?(myk)
Assignee | ||
Updated•19 years ago
|
Target Milestone: --- → Bugzilla 2.20
Comment 3•19 years ago
|
||
Comment on attachment 182347 [details] [diff] [review] patch, v1 >+ my $flag_types = Bugzilla::FlagType::match( >+ { 'target_type' => $target->{'type'}, >+ 'product_id' => $target->{'product_id'}, >+ 'component_id' => $target->{'component_id'}, >+ 'is_active' => 1 }); Don't we already determine that the flag types submitted in the form are valid for the given product and component? >+ # Get the number of active flags of this type already set for this target. >+ $flag_type->{'flag_count'} = count( >+ { 'type_id' => $type_id, >+ 'target_type' => $target->{'type'}, >+ 'bug_id' => $target->{'bug'}->{'id'}, >+ 'attach_id' => $target->{'attachment'}->{'id'}, >+ 'is_active' => 1 }); It would be better to use a local variable here instead of type->flag_count, since the member property is known to mean "total flags for this type", and we shouldn't confuse that by overloading the meaning with another one (once FlagType becomes a true object, we probably won't create a new one every time we want access to the same type, so overloading the meaning could also introduce bugs in the future). Otherwise this looks good.
Attachment #182347 -
Flags: review?(myk) → review-
Assignee | ||
Comment 4•19 years ago
|
||
$flag_type->{'flag_count'} is now $has_flags.
Attachment #182347 -
Attachment is obsolete: true
Attachment #185049 -
Flags: review?(myk)
Updated•19 years ago
|
Attachment #185049 -
Flags: review?(myk) → review+
Assignee | ||
Updated•19 years ago
|
Flags: approval?
Assignee | ||
Comment 6•19 years ago
|
||
Checking in Bugzilla/Flag.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Flag.pm,v <-- Flag.pm new revision: 1.39; previous revision: 1.38 done
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•