Thank you so much! It took a little bit more configuring but it worked! From the desk of Nicole A. Powell....
> On Dec 17, 2015, at 3:53 PM, Jim Brandt <[email protected]> wrote: > > Maps are used convert status when a ticket is moved from one queue to > another, so they need to be a one-to-one relationship. But I think there > might be a different approach to fool RTIR a bit. You could add a new > 'inactive' status to blocks that tells you that the block is still in place, > but is different from 'removed'. So something like: > > initial => ['pending activation'], > active => [ 'active', 'pending removal' ], > inactive => ['removed', 'active after incident'], > > Then set up some transitions to allow you to use it: > > transitions => { > '' => [ 'pending activation', 'active' ], > 'pending activation' => [ 'active', 'removed' ], > active => [ 'pending removal', 'removed', 'active > after incident' ], > 'pending removal' => [ 'removed', 'active', 'active after > incident' ], > removed => [ 'active' ], > }, > > (More info on lifecycles here: > https://bestpractical.com/docs/rt/4.2/customizing/lifecycles.html) > > With that in place, you can navigate to the block ticket and set the status > to 'active after incident' when you know the Incident is resolved. Now when > you resolve the Incident, the block will show up as resolved because RTIR > sees that it is in an inactive status. However, you can create a search for > all blocks in status 'active after incident' and keep track of them. > > You may run into other issues because this is working against RTIR's flow a > bit. If it works, you might also be able to set up a scrip to automate this. > >> On 12/17/15 11:19 AM, Nicole Powell wrote: >> In RTIR_SiteConfig.pm I copied the original RTIR_Config.pm and edited to the >> following: >> >> Set( >> blocks => { >> initial => [ 'pending activation'], >> active => [ 'active', 'pending removal' ], >> .... >> } >> _maps_ => { >> .... >> incidents -> blocks => { >> 'open' => 'active', >> 'resolved' => [ 'active', 'removed' ], >> 'abandoned' => ['active', 'removed' ], >> ...... >> } >> >> When I view System Configuration in the UI it looks as such: >> _maps_ => { >> .... >> incidents -> blocks => { >> 'open' => 'active', >> 'resolved' => 'array(0x25ecca8)', >> 'abandoned' => 'array(0x25ecc48)', >> ...... >> } >> >> So again when I try to close an incident it closes all the blocks but I want >> to be able to uncheck the blocks to keep them active but close the incident. >> >> From the desk of Nicole A. Powell.... >> >>>> On Dec 17, 2015, at 9:02 AM, Jim Brandt <[email protected]> wrote: >>>> >>>> On 12/17/15 8:50 AM, Nicole Powell wrote: >>>> I made some changes to the mappings for blocks to incidents (allowing >>>> blocks to remain active when incidents are closed) but the change is not >>>> working correctly. Has anyone had this issue before? >>> Editing the lifecycle could be a good solution to customizing for the >>> workflow you want. Can you post what you changed (maybe the part of the >>> lifecycle config)? When you say the change isn't working, can you provide >>> more detail, like what you're seeing and how it's different from what you'd >>> like? >>> >>> If you're not seeing any change at all, you can confirm the new lifecycle >>> is being loaded by going to the System Configuration page: Admin -> Tools >>> -> System Configuration. >>>> From the desk of Nicole A. Powell.... >
