Opinions on adding CF validation to REST interface

RT Developers
1

I need to have the REST interface enforce various CF things like:

  • Mandatory CFs
  • CF validation other than mandatory
  • Reject CF values for Select* fields which are not valid for the field

I have all of this working for AT and am working on adding it to RT (for
tickets anyway). I will submit a patch when done. I wanted to get
opinions on this though:

When creating a thing (asset, ticket etc.). The current behaviour I have
is:

  • If a mandatory CF is not present, give error and don’t create.
  • If a CF isn’t mandatory but a/the passed value doesn’t match the
    validation string, don’t update the CF but still create the object.
  • If a Select* CF has no validation string but a/the passed value
    doesn’t match any of the possible values, don’t update the CF but still
    create the object.

I was wondering if this was reasonable? I am in two minds about
rejecting all creation attempts by REST which fail any of these
criteria. The mandatory case if obvious - that’s what mandatory means
and this is really important for things like SOX audit - you simply must
be unable to create something without the mandatory CFs. But the other
two cases are less obvious. The GUI won’t let you create these last two
so I supose it should be consistent.

PK

Philip Kime
NOPS Systems Architect
310 401 0407

2

I need to have the REST interface enforce various CF things like:

  • Mandatory CFs
  • CF validation other than mandatory
  • Reject CF values for Select* fields which are not valid for the field

I have all of this working for AT and am working on adding it to RT (for
tickets anyway). I will submit a patch when done. I wanted to get
opinions on this though:

When creating a thing (asset, ticket etc.). The current behaviour I have
is:

  • If a mandatory CF is not present, give error and don’t create.
  • If a CF isn’t mandatory but a/the passed value doesn’t match the
    validation string, don’t update the CF but still create the object.
  • If a Select* CF has no validation string but a/the passed value
    doesn’t match any of the possible values, don’t update the CF but still
    create the object.

I was wondering if this was reasonable? I am in two minds about
rejecting all creation attempts by REST which fail any of these
criteria. The mandatory case if obvious - that’s what mandatory means
and this is really important for things like SOX audit - you simply must
be unable to create something without the mandatory CFs. But the other
two cases are less obvious. The GUI won’t let you create these last two
so I supose it should be consistent.

I think you’ve got it right and look forward to the patch

3

I need to have the REST interface enforce various CF things like:

  • Mandatory CFs
  • CF validation other than mandatory
  • Reject CF values for Select* fields which are not valid for the field

I have all of this working for AT and am working on adding it to RT (for
tickets anyway). I will submit a patch when done. I wanted to get
opinions on this though:

When creating a thing (asset, ticket etc.). The current behaviour I have
is:

  • If a mandatory CF is not present, give error and don’t create.
  • If a CF isn’t mandatory but a/the passed value doesn’t match the
    validation string, don’t update the CF but still create the object.
  • If a Select* CF has no validation string but a/the passed value
    doesn’t match any of the possible values, don’t update the CF but still
    create the object.

I was wondering if this was reasonable? I am in two minds about
rejecting all creation attempts by REST which fail any of these
criteria. The mandatory case if obvious - that’s what mandatory means
and this is really important for things like SOX audit - you simply must
be unable to create something without the mandatory CFs. But the other
two cases are less obvious. The GUI won’t let you create these last two
so I supose it should be consistent.

Phillip,

I would look at how the web interface enforces validation and
implement that in RT core. Make sure the way you implement it
allows easy overriding so that sites can customize to taste.
I think implementing the validation code in REST would be a
mistake.

-Todd

4

Phillip,

I would look at how the web interface enforces validation and
implement that in RT core. Make sure the way you implement it
allows easy overriding so that sites can customize to taste.
I think implementing the validation code in REST would be a
mistake.

+1. Agree strongly.

5

I’ll have a look. One of the things I mentioned has to be implemented in
the REST code itself:

  • If a SELECT* field is passed a value which isn’t valid, it must raise
    an error

This is obviously implemented in RT CORE because you can’t select a
non-valid valid for such fields in the GUI. In REST, we have to actually
check because there’s no GUI. But this isn’t really part of the Regexp
validation, it’s just related. I have this working in REST.

PKFrom: Jesse Vincent [mailto:jesse@bestpractical.com]
Sent: Sunday, December 24, 2006 8:35 AM
To: Todd Chapman
Cc: Philip Kime; rt-devel@lists.bestpractical.com
Subject: Re: [Rt-devel] Opinions on adding CF validation to REST
interface

Phillip,

I would look at how the web interface enforces validation and
implement that in RT core. Make sure the way you implement it allows
easy overriding so that sites can customize to taste.
I think implementing the validation code in REST would be a mistake.

+1. Agree strongly.

-Todd

List info:
The rt-devel Archives