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).
We verified that our accounts have "ModifyTicket" rights and also
checked tried this as root.
Looking at our rt.log file we saw this message:
[Wed May 31 17:45:01 2006] [error]: RT::Ticket=HASH(0xa70c0ec)
couldn't set status to resolved. RT's Database may be inconsistent.
(/usr/local/rt3/lib/RT/Ticket_Overlay.pm:2730)
When I tested on our old box (RT 3.2.2), merging resolved tickets
wasn't a problem.
Any one else experiencing this or have suggestions on what I can do
about it?
I migrated from:
FreeBSD 4.11, RT 3.2.2, MySQL 4.1.7, Apache 1.3.33, Perl 5.8.4,
mod_perl-1.29, DBI-1.42_1
--TO-->
RHEL 4.3, RT 3.4.5, MySQL 4.1.2-3, Apache 2.0.52, Perl 5.8.5,
mod_fastcgi-2.4.2, DBI-1.40-8
Thanks,
Mike
Mike,
To be honest, I can't see that as a problem. I thought the whole
point of merging tickets was to get one owner to work on similar (or
same) problems on one ticket instead of several, therefore, you merge
the tickets . before they get resolved. However, everyone does their
thing differently. I like the setup. That way it acts like a filter to
keep from merging tickets that are already resolved. you know, the cat
is already out of the bag, no sense closing it.
Kenn
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
We're hiring! Come hack Perl for Best Practical:
http://bestpractical.com/about/jobs.html
