On 1/5/16 10:31 AM, Nicole Powell wrote:
Bu you still can't creat a block without an incident though right? In my
environment we may create blocks based on intelligence or data and not
necessarily as a reactive measure so I'm looking at how to represent that in RT.
Correct. RTIR is set up with the incident ticket as the main hub of all
activity for a given incident. The other linked queues are for the
conversations with the various people who are related to the incident,
but in different ways. There are a few reasons for this:
* It manages the one-to-many of many incident reports for the same
incident and many possible investigation contacts and even many possible
blocks you may want to track.
* In doing the above, it keeps conversations cleanly separated. No
worries about having to customize the recipients of each reply when
talking to one or another incident reporter or colleague helping with an
investigation, etc.
* The history threads are cleaner. Even if you keep the recipients
clear, if you track all incident conversation on one ticket, the history
gets pretty jumbled.
Recognizing that there is some overhead to managing all of those
tickets, RTIR provides conveniences like updating or closing all
associated incident tickets at once, etc. In your case, an incident can
even be "received report of potential evil IP addresses, implementing
preventative measures" with the incident holding the details of who gave
you the intel, etc. Then the linked block just tracks the block.
That said, we realize not everyone will work with the default RTIR
workflows, which is why we're continuing to add more flexibility. But
the above is some of the rationale for the default configuration.
If you have blocks that are just blocks and not really associated with
an incident, RT can absolutely support that running alongside RTIR. And
you can set up dashboards for yourself that pull in tickets from both
the RTIR blocks queue and your custom stand-along queue.
From the desk of Nicole A. Powell....
On Jan 4, 2016, at 2:01 PM, Jim Brandt <[email protected]> wrote:
As a workaround, you could create a custom field to store links to one or more other
tickets. When you create the custom field, you can put a path in the "Link values
to" box and that will turn the displayed custom field into a clickable link. (You
can see this in the IP custom field in RTIR as well). Something like this would work for
an RT ticket:
__WebPath__/Ticket/Display.html?id=__CustomField__
RT then replaces __WebPath__ with the path to the current RT/RTIR and it will
put the custom field value, in this case a ticket id, in the place of
__CustomField__. You can set the custom field to accept one or multiple ticket
ids.
On 12/30/15 10:23 AM, Nicole Powell wrote:
Until we're able to customize the RTIR workflow I am looking for a workaround
on how to associate blocks to tickets other than incidents. Any ideas or
suggestions?
From the desk of Nicole A. Powell....
