case contact creation date bug about casa HOT 7 OPEN

Opened a PR (link above). I said that it "addressed" this issue rather than "resolves" since we don't know the precise issue. It will not auto-close this issue, we should probably confirm with users whether or not it has improved?

from casa.

I would think that using browser native date input would be more consistent, this is a tough one.

I looked at this a bit. Didn't find anything that would obviously lead to the bug -- but I have some thoughts.

1. CaseContact model uses a strange enum implementation for string column status. Rails may get confused by this (and devs certainly could be -- I was). This enum setup is how the status active?, started?, details?, etc.. methods used by the wicked wizard form are setup, and don't seem to do anything else. This is probably fine.
   • We can get rid of the enum and define them explicitly, as the gem suggests.
2. CaseContact occurred_at has three validations, that run only if status is active_or_details? (determined by above).
   • We can change them to run anytime record is not started, because after first form details page, where date selection happens, contact should never go back to 'started' status. This may help validations run when expected, especially during edits -- I'm unsure what status should be during an edit step, do we kick things back from active to the edit form step? What if that edit is abandoned? We don't update status once status == 'active'

I don't think this will fix the issue. But it may give better validation feedback to users? I have done some work already. Can look at the work here.

We could also log attributes when contacts are update? Get some actual idea of what date/format is sent...

I think that in order to get some idea of what is going on, we should probably know what browsers (and versions, if possible) users are having this trouble on.

from casa.

Can ignore my previous comment.

One idea I have is to change the date input from the RangedDatePicker component to a straight rails form.date_field, and let standard browser & rails validations happen. RangedDatePicker does not set standard max_date/min_date for the input but sets them in data attributes, and handles the range validation via js (in app/javascript/src/validated_form.js) to do this:

(note also 'minimize' does nothing on it currently (in safari at least), and will cover fields / submit button)

It would also be more consistent with validation for rest of the form. Is changing that an option?

The only other idea I have is to make a tagged log on every occurred_at change with relevant info.

from casa.

The javascript from app/javascript/src/case_contact.js also runs every time the form (or any page?) loads and changes the value of the input, in a kind of hacky way that browser input may not like?

function enGBDateString (date) {
  return date.toLocaleDateString('en-GB').split('/').reverse().join('-')
}

from casa.

Taking out that date conversion on page load doesn't break any other specs, so I'll work up a PR for that. I can't guarantee it's the issue, but seems very likely to me!

from casa.

interesting. A thing that I was thinking of and I am not sure if it is even logged as an issue currently is there is a page /all_casa_admins/patch_notes. And on that page if you set a patch note often times after you save the page and reload some of the drop down inputs will change.

I could not replicate what the volunteer was seeing which is why I don't have much to add here but that error is sorta similar so maybe there is a common thread?

from casa.

hmm... looks like a similar setup in app/javascript/src/all_casa_admin/patch_notes.js, which uses same notification library, and does some heavy DOM manipulation, but separate from the javascript involved here.

from casa.