Recursive merges

RT Developers
1

RT 3.0.4

  1. We have tickets: a, b, c
  2. merge a into b
  3. merge b into c

search of a b c leads to c - it’s OK.
but History of c only contain own and b’s information a’s transactions
does not diplays.

        Best regards. Ruslan.
2

Hello. Jesse.
Here my investigations on problem:
call $self->AddLink in sub MergeInto of Ticket_Overlay.pm reloads $self
:frowning: if this call not “Silent”.

Changes at Ticket_Overlay.pm
sub MergeInto {
…snip…
$RT::Logger->debug(
“Ticket id:”.$self->Id()." Merge Into ticket id:".$NewTicket->Id());
#make a new link: this ticket is merged into that other ticket.
$self->AddLink( Type => ‘MergedInto’, Target => $NewTicket->Id());

$RT::Logger->debug(
    "Ticket id:".$self->Id()." Merge Into ticket id:".$NewTicket->Id());

…snip…
}

Without Silent flag resulting debug info is:
Ticket id:15279 Merge Into ticket id:15288
(/opt/rt3/lib/RT/Ticket_Overlay.pm:2906)
[Wed Aug 20 17:07:54 2003] [info]:
rt-3.0.4-15288-141906.18.1953700448829@foo.com #15288/141906 - Scrip
19 Notify all about task changes (/opt/rt3/lib/RT/Action/SendEmail.pm:92)
[Wed Aug 20 17:07:54 2003] [info]:
rt-3.0.4-15288-141906.18.1953700448829@foo.com sent To: Cc: Bcc:
bar@foo.com (/opt/rt3/lib/RT/Action/SendEmail.pm:302)
[Wed Aug 20 17:07:54 2003] [debug]: Ticket id:15288 Merge Into ticket
id:15288 (/opt/rt3/lib/RT/Ticket_Overlay.pm:2910)

This is VERY bad behavior to change object that come from outside sub.
:frowning: Our Scrips are common based on standart Actions and Condtions.

I’ve spend much time on this f*** bug, but now I need to go to home. May
be tomorrow I’ll look at it again.

        Best regards. Ruslan.
3

Hello again.
Interesting discussion with myself :slight_smile:

AddLink without “Silent” flag call _SetTransaction that call
$self->Load($self->Id), but when we’ve called AddLink we allready
changed $self->EffectiveId. Because of it all next tasks is broken they
operate with same instance($NewTicket->Id == $self->Id)
This bug also have been breaking watchers copying on mergees because of
same reason.

This bug have effect on all people who system return not empty set for
this SQL request
select t2.id, t2.EffectiveId, t1.EffectiveId from Tickets t1 right join
Tickets t2 on t1.id = t2.EffectiveId where t1.id != t1.EffectiveId;

This select show ticket A (1 col = “id of A”) that was merged in ticket
B (2 col = “id of B”) and have EffectiveId == “id of B”, but EffectiveId
of B another and its value in 3rd col(id of C in which B was merged).
And in the result when we requst A or B or C we see only transactions of
C and B.

        Good luck and be force with you. Ruslan.

Ruslan U. Zakirov wrote:

rt3.reqursive_merges_patch_and_watchers.patch (750 Bytes)