-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
was originally.
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
Mike Friedman System and Network Security
mikef@ack.Berkeley.EDU 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
http://ack.Berkeley.EDU/~mikef http://security.berkeley.edu
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
iQA/AwUBRH8Lza0bf1iNr4mCEQKGKwCgveuY50TlGQN4xcMIfNz2FZc36pMAoLWS
FJLeW/A/Fxi2xLfJqNHyuTXs
=Izfa
-----END PGP SIGNATURE-----