[rt-users] Problem with __maps__
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 -- Help improve RT by taking our user survey: https://www.surveymonkey.com/s/N23JW9T
Re: [rt-users] Problem with __maps__
On Thu, Feb 07, 2013 at 09:31:53AM +, Martin Klíma wrote: 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 pgp2FiRhFsJPi.pgp Description: PGP signature -- Help improve RT by taking our user survey: https://www.surveymonkey.com/s/N23JW9T
Re: [rt-users] Problem with __maps__
- Original Message - From: Kevin Falcone falc...@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 j...@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 -- Help improve RT by taking our user survey: https://www.surveymonkey.com/s/N23JW9T
Re: [rt-users] Problem with __maps__
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 -- Help improve RT by taking our user survey: https://www.surveymonkey.com/s/N23JW9T
Re: [rt-users] Problem with __maps__
On Thu, Feb 07, 2013 at 11:06:51AM -0500, Jay Ashworth wrote: 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 pgp1jRZaGtMvq.pgp Description: PGP signature -- Help improve RT by taking our user survey: https://www.surveymonkey.com/s/N23JW9T
Re: [rt-users] Problem with __maps__
- Original Message - From: Kevin Falcone falc...@bestpractical.com On Thu, Feb 07, 2013 at 11:06:51AM -0500, Jay Ashworth wrote: 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 j...@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 -- Help improve RT by taking our user survey: https://www.surveymonkey.com/s/N23JW9T
