Hello,
Last week we have installed Request Tracker in our office. When customizing it I have encountered a problem I was able to solve but there are some issues I would like to point out.
I created a custom lifecycle in RT_SiteConfig and assigned it to a queue. This worked without problem. There was an open ticket in the queue and when the lifecycle was changed, it stayed in the ‘open’ state. As there is no ‘open’ state in our custom lifecycle, it was impossible to do anything with it. I tried to move it to another queue with default lifecycle, but I got " There is no mapping for statuses " error message, even though I created maps entry. I then spend about two hours debugging Lifecycle.pm and looking for syntax errors in my config, re-reading documentation until I finally realized that maps is not entry in the my_custom_lifecycle ‘subhash’ but rather an entry directly in the Lifecycles hash. I suggest that this sentence from the documentation:
The lifecycle configuration has a maps entry to allow you to specify the mappings you want between different queues.
is at least ambiguous, if not misleading.
I then got another error message, “Mapping between queues’ lifecycles is incomplete”. After more debugging I realized that as the issue is in the ‘open’ status which is not a part of the custom lifecycle, there is obviously no entry for it in the hash that maps custom lifecycle states to those of the default one. After adding ‘open’ => ‘open’ to the map everything worked.
The main issue seems to me that assigning a lifecycle to a queue does not migrate the tickets in the queue to a new lifecycle. I should have got “There is no mapping for statuses” error when I was assigning the new lifecycle. Strangely, I was not able to change the queue lifecycle back to default: no error message was shown, but the lifecycle did not change. This problem persists even after I moved all tickets from the queue.
Best regards,
Martin
Martin Klima, Warhorse Studios
web: http://www.warhorsestudios.cz
The main issue seems to me that assigning a lifecycle to a queue does
not migrate the tickets in the queue to a new lifecycle. I should
have got “There is no mapping for statuses” error when I was
assigning the new lifecycle.
This is a known bug we’ve been discussing how to fix. There’s a lot
of magic that needs to happen when you change a lifecycle midstream.
You have to leave transitions in place until you migrate away from the
old statuses and it’s a pain. Unfortunately, on a large queue, any
sort of magic could run for a long time and time out, etc. It’s also
a bit ‘magic’ behind the scenes, so we want to wrap it up in a nice
enough dialog for the admin. We’re hopeful that something will get
into 4.2 for this. Fixing the error message to say something about
transitions rather than maps should be fixable for 4.0, please file a
bug about that?
Strangely, I was not able to change the
queue lifecycle back to default: no error message was shown, but the
lifecycle did not change. This problem persists even after I moved
all tickets from the queue.
This should not be the case since 4.0.9. What version of RT did you
install? The current release is 4.0.10.
-kevin
From: “Kevin Falcone” falcone@bestpractical.com
This is a known bug we’ve been discussing how to fix. There’s a lot
of magic that needs to happen when you change a lifecycle midstream.
You have to leave transitions in place until you migrate away from the
old statuses and it’s a pain. Unfortunately, on a large queue, any
sort of magic could run for a long time and time out, etc.
That is a problem that crops up in a bunch of different places of different
sizes and scopes, all the way down to “does $AndroidClient cache status
postings if it can’t get them through due to a local connectivity error”
(for Tweetcaster the answer is “yes, visibly”; for Facebook, "maybe,
but you can’t tell), and I believe the indicated design pattern there is
“Job Queue”.
Is there already something in RTs internals for handling queued jobs?
If not, is this a big enough issue – and might you gain useful leverage
in the future – from introducing it?
Cheersr,
– jra
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA #natog +1 727 647 1274
Many thanks for your reply, Kevin.
Fixing the error message to say something about transitions rather than maps should be fixable for 4.0, please file a bug about that?
All right, will do
This should not be the case since 4.0.9. What version of RT did you install? The current release is 4.0.10.
We are on 4.0.8.
Cheers,
Martin
Is there already something in RTs internals for handling queued jobs?
There is not.
If not, is this a big enough issue – and might you gain useful leverage
in the future – from introducing it?
Already being discussed. There are a number of things that would
benefit from it. Clearly it would increase the complexity of the
installation process.
-kevin
From: “Kevin Falcone” falcone@bestpractical.com
Is there already something in RTs internals for handling queued
jobs?
There is not.
If not, is this a big enough issue – and might you gain useful
leverage
in the future – from introducing it?
Already being discussed. There are a number of things that would
benefit from it. Clearly it would increase the complexity of the
installation process.
Ah yes: the “writing the code myself is not the only cost I avoid in
integrating Other People’s Components” realization; the Dirty Little
Secret of open source design.
“Already being discussed” was the right answer, though. 
Cheers,
– jra
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA #natog +1 727 647 1274