[rt-users] " Merge failed. Couldn't set Status" - after upgrade to 3.4.5
mikef at ack.Berkeley.EDU
Thu Jun 1 11:46:17 EDT 2006
-----BEGIN PGP SIGNED MESSAGE-----
On Wed, 31 May 2006 at 11:16 (-0700), Mike Patterson wrote:
> We noticed a bug with RT 3.4.5 after our upgrade, which could be an
> indicator of an "inconsistent database".
> When we attempted to merge one ticket into another we go this message
> "Merge failed. Couldn't set Status"
> It turns out that both of the tickets were already set to "resolved".
> After we switched the status to "open" we were able to merge the tickets
> (then we switched the merged ticket back to resolved).
I have noticed this on 3.4.2 as well. I've written a perl script (using
the RT API) that allows merging two tickets from the command line (I don't
like using the supplied 'rt' CLI command). When I got the above error
message, I looked into the RT code and found that a ticket to be merged
into another is first changed to 'resolved' status (I don't know why).
If the status is already 'resolved', this results in an error message.
I don't know why setting a status to the same value that's currently set
should be considered an error; this has been a problem for me in other
script-writing contexts, where I always have to check for this case before
invoking the SetStatus method, lest I get a spurious error code. But I
think this is really part of a broader problem of how error codes are set
in RT API methods (i.e., any error just returns 0, so a script can't tell
what kind of error it was).
So, my merge script now has to check first if the status is 'resolved';
if so, set it to 'open' and then merge it. If the merge fails for some
reason, I set the status back to 'resolved', but only if that's what it
I can see how this problem can be quite annoying when using the Web UI,
since it means an additional manual step of 'unresolving' the ticket
first, as you've discovered.
> We verified that our accounts have "ModifyTicket" rights and also
> checked tried this as root.
I don't believe this has anything to do with rights. For some reason, RT
just decides to set status to 'resolved' as part of the merge process.
> When I tested on our old box (RT 3.2.2), merging resolved tickets wasn't
> a problem.
I guess this started with some version after 3.2.2!
Mike Friedman System and Network Security
mikef at ack.Berkeley.EDU 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
-----END PGP SIGNATURE-----
More information about the RT-Users