[rt-users] " Merge failed. Couldn't set Status" - after upgrade to 3.4.5

[Mike Friedman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

<gripe>
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).
</gripe>

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 at 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-----