Custom Fields query vs. CLI edit syntax inconsistencies

RT Users
1

Does anyone know why the syntax of a query on a custom field from the
command line looks like:

rt ls “Queue=‘General’ AND CF.{SomeDefinedCustomField} is not ‘NULL’”

… but the edit would be something like:

rt edit ticket/1 add CF-SomeDefinedCustomField=‘Value’

Why don’t they both use the same syntax for referencing custom fields?

Thanks.

Joshua Colson jcolson@voidgate.org

2

Does anyone know why the syntax of a query on a custom field from the
command line looks like:

rt ls “Queue=‘General’ AND CF.{SomeDefinedCustomField} is not ‘NULL’”

… but the edit would be something like:

rt edit ticket/1 add CF-SomeDefinedCustomField=‘Value’

Why don’t they both use the same syntax for referencing custom fields?

Mostly because the functionality came from different places at different
times. The query builder version is the preferred format and I’d love a
patch to the CLI to support that version.

Best,
Jesse

3

Why don’t they both use the same syntax for referencing custom fields?

I’m not sure that’s necessarily a bad thing - the REST syntax for CF
editing is nice and simple for scripting - the curly brackets would make
things more complicated to parse and generally use. When I was deciding
on a format for displaying CFs for the AT REST code, I automatically
chose “CF_” (changed to “CF-” now to match RT 3.6.0) because it’s easy
to parse in the REST code and easy to edit in the CLI. All that shell
escaping for curly brackets when you’re scripting would make the REST
interface less convenient to use …

PK

4

I’m not sure that’s necessarily a bad thing - the REST syntax for CF
editing is nice and simple for scripting - the curly brackets would make
things more complicated to parse and generally use. When I was deciding
on a format for displaying CFs for the AT REST code, I automatically
chose “CF_” (changed to “CF-” now to match RT 3.6.0) because it’s easy
to parse in the REST code and easy to edit in the CLI. All that shell
escaping for curly brackets when you’re scripting would make the REST
interface less convenient to use …

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

I agree that the lack of curly brackets makes scripting cleaner but I
spend a few hours hitting my head against the wall to discover that
difference (in the beginning).

Maybe this should be moved to the -devel list.

Joshua Colson jcolson@voidgate.org