Regular Expressions for Custom Field Validation in RT3.6.0

RT Users
1

I know what you mean, and I did something like that in my code that I
backported from 3.5.x to 3.4.x. I added another regex field that said
whether something was mandatory or not, where 1 is mandatory, and 0 is
not:

(?#Year)(?#0)[1]\d{3}$ year, not mandatory
(?#Mandatory)(?#1). anything, mandatory
(?#postal code)(?#1)[2]{2}$ postal code, mandatory

The second one is useful for a field where you want anything, don’t care
how long or what it looks like, so long is it isn’t left blank.
Obviously, I hacked on the RT code a little that reads this stuff to
accomodate for the second regex group.

Eric Schultz
United Online

[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Todd
ChapmanSent: Friday, June 23, 2006 2:56 PM
To: Nick Metrowsky
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Regular Expressions for Custom Field Validation
in RT3.6.0

Hi Everyone,

Once I was told where Custom Field Validation is maintained in RT
3.6.0,
I thought I make this small contribution to RT 3.6.0. The following
code
snippet contains several useful regexp validations. Two of these are
provided with RT 3.6.0 (Mandatory, Digits), the new additions are as
follows:

  1. DateYYYYMMDD - Date in YYYY-MM-DD or YYYY/MM/DD format
  2. DateMMDDYYYY - Date in MM-DD-YYYY or MM/DD/YYYY format
  3. DateDDMMYYYY - Date in DD-MM-YYYY or DD/MM/YYYY format
  4. Float - Floating Point Numbers
  5. Email - Email address format
  6. IPAddress - IP Address format
  7. USZipCode5 - US 5 digit Zip Code
  8. UZZipCode9 - US 9 digit Zip Code
  9. USZipCode5or9 - US Zip Code (either 5 digit or 9 digit)
  10. USTelephone - US Telephone Numbers
  11. RowRackHeight - Something used by us locally for locating
    equipment in out data center; Row #, Rack #, and Unit Height # in
    Rack.

Nick,

I submitted a patch to Jesse that implements a callback
so that new validations can be easily added. Hopefully the
patch will make it into 3.6.1.

Also, for every validation it would be useful to have
another validation that makes it possible to insert
no data.

For example:

(?#Date)^\d\d\d\d-\d\d-\d\d$
(?#Optional Date)^(\d\d\d\d-\d\d-\d\d)?$

The first requires a date. The second allows a blank
CF, but a date is entered it has to match the format.

-Todd

  1. 12 ↩︎

  2. A-Z ↩︎

2

I know what you mean, and I did something like that in my code that I
backported from 3.5.x to 3.4.x. I added another regex field that said
whether something was mandatory or not, where 1 is mandatory, and 0 is
not:

(?#Year)(?#0)[1]\d{3}$ year, not mandatory
(?#Mandatory)(?#1). anything, mandatory
(?#postal code)(?#1)[2]{2}$ postal code, mandatory

The second one is useful for a field where you want anything, don’t care
how long or what it looks like, so long is it isn’t left blank.
Obviously, I hacked on the RT code a little that reads this stuff to
accomodate for the second regex group.

Eric Schultz
United Online

Eric,

Why add the second regex group when you can wrap the whole
thing in ()? ?

-Todd

  1. 12 ↩︎

  2. A-Z ↩︎

3

I think that may break the regex parsing in MatchPattern() in
CustomField_Overlay.pm. Unless you are talking about doing something
like:

(?#Year)[1]\d{3}$

becomes

(?#Year)([2]\d{3}$)?

Give it a try and let me know how that works for you :slight_smile:

Eric Schultz
United OnlineFrom: Todd Chapman [mailto:todd@chaka.net]
Sent: Monday, June 26, 2006 8:48 AM
To: Schultz, Eric
Cc: Nick Metrowsky; rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Regular Expressions for Custom Field Validation
in RT3.6.0

I know what you mean, and I did something like that in my code that I
backported from 3.5.x to 3.4.x. I added another regex field that said
whether something was mandatory or not, where 1 is mandatory, and 0 is
not:

(?#Year)(?#0)[3]\d{3}$ year, not mandatory
(?#Mandatory)(?#1). anything, mandatory
(?#postal code)(?#1)[4]{2}$ postal code, mandatory

The second one is useful for a field where you want anything, don’t
care
how long or what it looks like, so long is it isn’t left blank.
Obviously, I hacked on the RT code a little that reads this stuff to
accomodate for the second regex group.

Eric Schultz
United Online

Eric,

Why add the second regex group when you can wrap the whole
thing in ()? ?

-Todd

  1. 12 ↩︎

  2. 12 ↩︎

  3. 12 ↩︎

  4. A-Z ↩︎

4

I think that may break the regex parsing in MatchPattern() in
CustomField_Overlay.pm. Unless you are talking about doing something
like:

(?#Year)[1]\d{3}$

becomes

(?#Year)([2]\d{3}$)?

Give it a try and let me know how that works for you :slight_smile:

The second form is exactly what I was talking about and
seems to work fine with stock RT 3.6 code.

-Todd

  1. 12 ↩︎

  2. 12 ↩︎