[rt-users] SLA Extension - searching for tickets with SLA not set

Chris McClement chrisis at bosberaad.com
Wed Feb 1 16:04:04 EST 2017


Thanks!

SLA IS NULL  <- that worked.

Following from this: I want to do a bulk update to set an SLA for these
calls. However the bulk update page doesn't include any SLA fields. Any
ideas how I would go about setting the SLA on these calls (other than
manual, I have about 150 tickets that need this changed)?

On Thu, 2 Feb 2017 at 06:28 Jeffrey Pilant <jeffrey.pilant.ext at bayer.com>
wrote:

> Chris McClement writes:
> >I can't figure out how to search for a field (specifically, "SLA") that is
> >unset:
> >
> >Tickets that are emailed to our helpdesk are inserted into a "Helpdesk"
> >queue and from there an operator reviews the content and then assigns the
> >ticket to the relevant queue.
> >
> >The "Helpdesk" queue does not have an SLA assigned to it, but the
> >downstream queues do.  What's been happening, though, is that tickets
> >transferred from "Helpdesk" to "Queue1" (not it's real name) aren't
> picking
> >up the SLA default setting. Instead, the SLA field is unset.
> >
> >If I search for tickets with SLA = 'STANDARD' I get results showing
> tickets
> >that have that SLA value.
> >
> >If I search for tickets with SLA != 'STANDARD' I only get tickets that
> have
> >the SLA field set (URGENT or CRITICAL, for example). But I don't get the
> >hundreds of tickets that don't have the SLA field set at all.
> >
> >Does anyone know the syntax to use to search for a field that is unset?
>
> On 9 Dec 2016, Matt Zagrabelny wrote:
> >... you can search for
> >tickets with empty CF values using the Advanced editing option of a
> >Search:
> >
> >'CF.{bar}' is null
> In reply to a question about searching CF.{bar}
>
> Maybe you can do something similar.
>
> /jeff
>
> ________________________________________________________________________
> The information contained in this e-mail is for the exclusive use of the
> intended recipient(s) and may be confidential, proprietary, and/or
> legally privileged.  Inadvertent disclosure of this message does not
> constitute a waiver of any privilege.  If you receive this message in
> error, please do not directly or indirectly use, print, copy, forward,
> or disclose any part of this message.  Please also delete this e-mail
> and all copies and notify the sender.  Thank you.
> ________________________________________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20170201/db2e71f6/attachment.html>


More information about the rt-users mailing list