A quick scan of archives (subjects, anyway) didn’t show this topic
as having been discussed earlier, so here comes an “enhancement request”:
Please make it possible to un-merge requests. Our queue operators
sometimes merge into the wrong item, and it would be really nice if
(with admin privileges) we could un-do the damage.
In the old “Req” system it was possible to do so (with care) by using a
text editor on the merged text file. It looks like with RT-1.0 it could
be done by judicious SQL hacking, but one runs a large risk of leaving
the database in an inconsistent state.
Could it be as simple as “rolling back” the changes to the effective
serial-number field, making it once again match the serial-num field?
Naturally one would want to leave an “unmerge” transaction in both
of the resulting requests. And of course all bets are off when a
multiple (nested) merge has taken place, unless one takes the trouble
to parse the chain of transactions.
I’m going to start looking at the 2.0 merge implementation soonish.
I’ll keep this in mind.
jesseOn Fri, Apr 07, 2000 at 12:10:32PM -0700, Marion Hakanson wrote:
Folks,
A quick scan of archives (subjects, anyway) didn’t show this topic
as having been discussed earlier, so here comes an “enhancement request”:
Please make it possible to un-merge requests. Our queue operators
sometimes merge into the wrong item, and it would be really nice if
(with admin privileges) we could un-do the damage.
In the old “Req” system it was possible to do so (with care) by using a
text editor on the merged text file. It looks like with RT-1.0 it could
be done by judicious SQL hacking, but one runs a large risk of leaving
the database in an inconsistent state.
Could it be as simple as “rolling back” the changes to the effective
serial-number field, making it once again match the serial-num field?
Naturally one would want to leave an “unmerge” transaction in both
of the resulting requests. And of course all bets are off when a
multiple (nested) merge has taken place, unless one takes the trouble
to parse the chain of transactions.
jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
A REAL sysadmin challenge is “resurrect five dead mailserver while so ripped
to the gills on mdma that you can’t focus on any given line of text for more
than 10 seconds continuously.”
-Nathan Mehl
Right now, you can unmerge by hand, if you understand what tickets were merged
and can reset the effective_id on the ticket objects and transactions
which got mangled.On Fri, Apr 07, 2000 at 12:10:32PM -0700, Marion Hakanson wrote:
Folks,
A quick scan of archives (subjects, anyway) didn’t show this topic
as having been discussed earlier, so here comes an “enhancement request”:
Please make it possible to un-merge requests. Our queue operators
sometimes merge into the wrong item, and it would be really nice if
(with admin privileges) we could un-do the damage.
In the old “Req” system it was possible to do so (with care) by using a
text editor on the merged text file. It looks like with RT-1.0 it could
be done by judicious SQL hacking, but one runs a large risk of leaving
the database in an inconsistent state.
Could it be as simple as “rolling back” the changes to the effective
serial-number field, making it once again match the serial-num field?
Naturally one would want to leave an “unmerge” transaction in both
of the resulting requests. And of course all bets are off when a
multiple (nested) merge has taken place, unless one takes the trouble
to parse the chain of transactions.