Custom Fields query vs. CLI edit syntaxinconsistencies

You could deal with both on input but you’d need to pass a flag back and
forth to keep track of which format you wanted on output and I don’t
think that would be be very pretty. As long as the “rt help” stuff
mentions the format, I would think it would be ok. The “rt
search|list|ls” help does say that the format is the SQL-like syntax
(TicketSQL) that RT uses - as long as the “show” and “edit” help said
“CFs have prefix CF-” or something?

The change to CF.{} for REST CFs wouldn’t be hard to code but I’m just
not sure that propagating a tricky syntax even further would be such a
good idea? It’s possible (and easier) to modify the REST search function
to allow “CF-” as well as CF.{}. What about that?

PK-----Original Message-----
From: Joshua Colson [mailto:jcolson@voidgate.org]
Sent: 22 June 2006 12:56
To: Philip Kime; Jesse Vincent
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Custom Fields query vs. CLI edit
syntaxinconsistencies

What if the CLI supported both versions of the syntax? Would that make
the REST code more difficult to maintain?

Here’s a simple patch to $rtroot/share/html/REST/1.0/search/ticket to
enable searches to use either format

*** /usr/local/rt/share/html/REST/1.0/search/ticket 2006-05-25
21:11:58.000000000 -0700
— /tmp/ticket 2006-06-22 14:57:12.634046264 -0700
*** 82,87 ****
— 82,91 ----
}

my ($n, $s);

  • Allow queries involving CFs to use the REST-style syntax

  • $query =~ s/\bCF-([^\s]+)/CF.{$1}/g;
    eval {
    ($n, $s) = $tickets->FromSQL($query);
    };