Patches for moving mandatory/validation etc. into RT core API

Chaps - we have completed a pile of work on RT 3.6.3 which lets us do
the following:

  • Provide a seperate checkbox for making a CF mandatory
  • Moved CF mandatory checking and CF validation into the RT API core
  • Put in a core check for valid values of Select* CFs (needed for
    REST/Email checks)
  • Removed “validation” option for Select* fields in GUI - makes no sense
  • the drop-down is the validation
  • Removed “mandatory” validation regexp as this is now a seperate thing
  • Tightened up the REST ticket error reporting and enhanced the CF
    processing

This was done for the following reasons:

  1. To make the notion of “mandatory” highly visible for audit purposes.
  2. To seperate out “mandatory” from “validated” as these are
    conceptually separate and can’t really be dealt with in the same place
    when you start to extend these concepts to REST and Email.
  3. To make sure these checks work via REST/CommandByMail/GUI so that RT
    is audit-proof

The semantics of the combinations of mandatory/validated fields are:

  • Mandatory/non-validated: Create/Modify transaction fails if no value.
  • Mandatory/validated: Create/Modify transaction fails if no value.
    Fails if value does not match pattern.
  • Non-Mandatory/validated: Allows “(no value)” but if value is not null,
    must match pattern or create/modify fails.

I wanted to know how much these are wanted because it’s going to be a
fair task to generate nice patches against 3.6.3 because we have so many
local mods mixed in with them. I don’t want to generate the patches if
it’s not that useful. I think the patches are against about ten files.
This was all done for AT too.

PK

Philip Kime
NOPS Systems Architect
310 401 0407

Chaps - we have completed a pile of work on RT 3.6.3 which lets us do
the following:

  • Provide a seperate checkbox for making a CF mandatory
  • Moved CF mandatory checking and CF validation into the RT API core
  • Put in a core check for valid values of Select* CFs (needed for
    REST/Email checks)
  • Removed “validation” option for Select* fields in GUI - makes no sense
  • the drop-down is the validation
  • Removed “mandatory” validation regexp as this is now a seperate thing
  • Tightened up the REST ticket error reporting and enhanced the CF
    processing

This was done for the following reasons:

  1. To make the notion of “mandatory” highly visible for audit purposes.
  2. To seperate out “mandatory” from “validated” as these are
    conceptually separate and can’t really be dealt with in the same place
    when you start to extend these concepts to REST and Email.
  3. To make sure these checks work via REST/CommandByMail/GUI so that RT
    is audit-proof

The semantics of the combinations of mandatory/validated fields are:

  • Mandatory/non-validated: Create/Modify transaction fails if no value.
  • Mandatory/validated: Create/Modify transaction fails if no value.
    Fails if value does not match pattern.
  • Non-Mandatory/validated: Allows “(no value)” but if value is not null,
    must match pattern or create/modify fails.

I wanted to know how much these are wanted because it’s going to be a
fair task to generate nice patches against 3.6.3 because we have so many
local mods mixed in with them. I don’t want to generate the patches if
it’s not that useful. I think the patches are against about ten files.
This was all done for AT too.

I think I’d like to see all this folded into RT, though I worry about
the change in the middle of the 3.6 series. I think I’d rather see
pulling this into 3.7, as long as Ruslan feels comfortable with the code
in the patches.