Date validation applied inconsistently if using Single Table Inheritince #88

IanWhitney opened this Issue Nov 2, 2012 · 4 comments


None yet
4 participants

Rails 3.2.8
Ruby 1.9.3-p286
Validates_timeliness 3.0.14
timeliness 0.3.7

Validates Timeliness config

  config.use_plugin_parser = true
  config.parser.add_formats(:date, 'm/d/yyyy')
  config.parser.add_formats(:date, 'mm/dd/yyyy')
  config.parser.remove_formats(:date, 'd/m/yy')
  config.parser.remove_formats(:date, 'd-m-yy')
  config.parser.remove_formats(:date, 'dd-mm-yyyy')

Relevant model code

  class CostReport < ActiveRecord::Base
    validates_date  :report_period_start,
                    :allow_nil => true,
                    :allow_blank => true

  class Sa1 < CostReport
    validates_date  :last_payroll_date,
                     :allow_nil => true,
                     :allow_blank => true

Console behavior

Sa1.valid? => true
Sa1.report_period_start = 'qwert'
Sa1.valid? => true
Sa1.last_payroll_date = 'qwert'
Sa1.valid? => false
Sa1.errors[:last_payroll_date] => ["is not a valid date"]

CostReport.valid? => true
CostReport.report_period_start = 'qwert'
CostReport.valid? => true
CostReport.last_payroll_date = 'qwert'
CostReport.valid? => false
CostReport.errors[:last_payroll_date] => ["is not a valid date"]

adzap commented Nov 3, 2012

The issues are from my reading of this:

#1 Validation for last_payroll date seems to leak to the super class (CostReport)

#2 Validation for report_period_start is not working on the either class.

If you don't inherit Sa1 from CostReport (comment out the class definition) does the report_period_start validation work?

The first issue isn't a Validates Timeliness thing. I think it's due to the Rails magic around STI. For example:

c = CostReport.find(1)
c.class => Sa1

As for the 2nd issue, I've tried a couple of other approaches to get the validation for report_period_start to work.

First, I included that validation in both CostReport and Sa1 via a module. The behavior was the same.

Second, I simply duplicated the validation, putting the exact same rules in both class definitions. The behavior was the same. That one really took me by surprise.

I can confirm similarly odd behavior with Rails 3.2.9, Ruby 1.9.3-p286, timeliness 0.3.7 and validates_timeliness 3.0.13 and 3.0.14.

jimherz commented Sep 27, 2013

For anyone interested, I submitted a pull request that fixes this issue: #107

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment