3.6.HEAD REST fix

Hi List,

the attached patch fixes REST’s custom field handling in RT 3.6.HEAD
(the patch is against revision 5647).

RT/CustomField_Overlay.pm is changed because
REST/1.0/Forms/ticket/default lowercases all keys and $cf->LoadByName
cannot find “broken in”, for instance (defined as “Broken in”).

If this significantly changes semantics of other parts of rt, the fix
may have to be moved to REST/1.0/Forms/ticket/default – keep the
original, not lowercased, version of $key for CF’s consumption.

I tested using SQLite.

  • Dmitri.

Reference:
http://lists.bestpractical.com/pipermail/rt-devel/2006-July/008665.html

rt-3.6-rest.patch.txt (1.31 KB)

Hi Ruslan,

thanks for the commit (5652). However, the second part of the patch
(casesensitive => 0) should still be applied. I now tested with SQLite
and Postgres, and without this patch custom fields with upper-case
letters in them cannot get updated using REST interface.

  • Dmitri.

Hi List,

the attached patch fixes REST’s custom field handling in RT 3.6.HEAD
(the patch is against revision 5647).

RT/CustomField_Overlay.pm is changed because
REST/1.0/Forms/ticket/default lowercases all keys and $cf->LoadByName
cannot find “broken in”, for instance (defined as “Broken in”).

If this significantly changes semantics of other parts of rt, the fix
may have to be moved to REST/1.0/Forms/ticket/default – keep the
original, not lowercased, version of $key for CF’s consumption.

I tested using SQLite.

  • Dmitri.

Reference:

http://lists.bestpractical.com/pipermail/rt-devel/2006-July/008665.html

Index: RT/CustomField_Overlay.pm
===================================================================
RCS file: /home/dmitri/cvs/rt3/lib/RT/CustomField_Overlay.pm,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
— RT/CustomField_Overlay.pm 22 Jul 2006 23:24:32 -0000 1.1.1.1
+++ RT/CustomField_Overlay.pm 23 Jul 2006 23:36:38 -0000 1.2
@@ -289,7 +289,7 @@

 my $CFs = RT::CustomFields->new($self->CurrentUser);
  • $CFs->Limit( FIELD => ‘Name’, VALUE => $args{‘Name’} );
  • $CFs->Limit( FIELD => ‘Name’, VALUE => $args{‘Name’},
    CASESENSITIVE => 0 );

    Don’t limit to queue if queue is 0. Trying to do so breaks

    RT::Group type CFs.

    if (defined $args{‘Queue’}) {
    Index: RT/Interface/REST.pm
    ===================================================================
    RCS file: /home/dmitri/cvs/rt3/lib/RT/Interface/REST.pm,v
    retrieving revision 1.1.1.1
    retrieving revision 1.2
    diff -u -r1.1.1.1 -r1.2
    — RT/Interface/REST.pm 22 Jul 2006 23:24:32 -0000 1.1.1.1
    +++ RT/Interface/REST.pm 23 Jul 2006 23:37:39 -0000 1.2
    @@ -60,7 +60,7 @@
    @EXPORT = qw(expand_list form_parse form_compose vpush vsplit);
    }

-my $field = ‘[a-zA-Z][a-zA-Z0-9_-]';
+my $field = '(?:[a-zA-Z][a-zA-Z0-9_-]
|[Cc][Ff]-[a-zA-Z0-9_ -]+)’;

WARN: this code is duplicated in bin/rt.in,

change both functions at once


List info:
The rt-devel Archives

Best Practical is hiring! Come hack Perl for us:
Careers — Best Practical Solutions

The problem still exists in 3.6.1 (tested with PostgreSQL). However,
now I am a bit confused – I was able to create custom fields “Broken
in”, “broken in”, and “broken in” again – is that the desired
behavior?

  • Dmitri.

Hi Ruslan,

thanks for the commit (5652). However, the second part of the patch
(casesensitive => 0) should still be applied. I now tested with
SQLite
and Postgres, and without this patch custom fields with upper-case
letters in them cannot get updated using REST interface.

  • Dmitri.

Hi List,

the attached patch fixes REST’s custom field handling in RT
3.6.HEAD
(the patch is against revision 5647).

RT/CustomField_Overlay.pm is changed because
REST/1.0/Forms/ticket/default lowercases all keys and
$cf->LoadByName
cannot find “broken in”, for instance (defined as “Broken in”).

If this significantly changes semantics of other parts of rt, the
fix
may have to be moved to REST/1.0/Forms/ticket/default – keep the
original, not lowercased, version of $key for CF’s consumption.

I tested using SQLite.

  • Dmitri.

Reference:

http://lists.bestpractical.com/pipermail/rt-devel/2006-July/008665.html

The problem still exists in 3.6.1 (tested with PostgreSQL). However,
now I am a bit confused – I was able to create custom fields “Broken
in”, “broken in”, and “broken in” again – is that the desired
behavior?

Custom field names are not guaranteed unique.