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?
From the desk of Nicole A. Powell…
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.
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 jbrandt@bestpractical.com 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…
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:
Customizing/Lifecycles - RT 4.2.17 Documentation - Best Practical)
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 jbrandt@bestpractical.com 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…
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 jbrandt@bestpractical.com 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: Customizing/Lifecycles - RT 4.2.17 Documentation - Best Practical)
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 jbrandt@bestpractical.com 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…