[configuration] Add date_format as DataType in ConfigSettings

[jesscall]

Brief summary of changes

Quick fix for candidate parameter tabs Date of Birth and Date of Death. Altering the DOB format or the DOD format fields in the configuration module to either YM or Ym should result in the dates in cand param being saved with YYYY-MM-01 as the day of the month rather than whatever the user entered.

Edit:
This PR now adds a new dataType to ConfigSettings: date_format. Fields such as DOB and DOD format will now have a dropdown in which users that select what format they prefer. This should also resolve the ambiguity in candidate parameters that is discussed in the thread below.

Testing instructions (if applicable)

1. See test plan steps 35 & 40

Link(s) to related issue(s)

• Resolves [candidate_parameters] Date format does not match dates specified in config #6678

[driusan]

@jesscall this is failing Travis

[ridz1208]

@jesscall The way I understand it, the casing of the YMD letters actually dictates the formate of dates so I don't think it's a good idea to make all combinations of Ym YM yM ym do the same thing, just in case we decide to support more formats later on.

I think the proper fix to the reported issue would be to throw a configuration error in the config module if you choose a date different then the only 2 supported formats OR to change that configuration field to a drop down and progressively add formats to it as we move forward.

[maltheism]

@ridz1208 @jesscall something like https://www.php.net/manual/en/datetime.format.php might be useful for converting to the correct format.

[jesscall]

@CamilleBeau ready for review

[Notes]:

• The PR has gone in a different direction. It now adds a dropdown to configuration module where the user can select a format from a pre-determined list.
• I've hard-coded this list as there are only 2 formats we support at the moment, however I wouldn't mind creating a table for this since it is possible the list grows over time.
• The caveat for projects is that the date format entered in the text field may not match the dropdown options which will lead to some issues. On upgrade projects should double check and amend where applicable.

[Testing]:

• Please test the configuration module DOB & DOD format fields.
• Also test if the original bug is resolved.

[CamilleBeau]

Error given when sourcing rb while in this branch:

[johnsaigle]

In general the way we display the date shouldn't impact what is saved in the database. The logic should be decoupled. A user can enter a year, month and day on the front-end and we can drop the day value if necessary when it goes into the database. When we display the date, we can show or hide to whatever resolution we want.

As @maltheism suggested, this would be easier with DateTime objects. We can use them to validate date formats or easily replace just the date value. It's a more robust way than working with strings.

---

There's also the config setting dateDisplayFormat. I think it should also be changed in the SQL for consistency along with any other date config settings.

Alternatively - I'm not sure if it's important for the DoD and DoB formats to be different. Could they both instead use dateDisplayFormat?

[ridz1208]

@johnsaigle the way we save the data does impact the display. Users get confused when they can select a day but it defaults to 01 after saving. The display should clearly show that you are selecting a whole month at a time

[maltheism]

@ridz1208 maybe the user's "format" of the date should be saved in the database and used for the standardized date in the database to be reverted to the correct format for the user on the frontened.

[johnsaigle]

@ridz1208 I think we're saying the same thing. We should save whatever the user enters but display it with either the day chopped off or with -01. Alternatively if the day is never needed then I think the issue is with the input fields. We shouldn't prompt for a day if it won't be used.

[jesscall]

@johnsaigle the issue with saving the full date in the DB and then only displaying the day as 01 is that it makes anonymization / identification of a candidate a concern when it comes to data releases.

Re: not having a day field displayed at all:
Most times, data entry staff is just inputting a date of birth that was recorded on paper forms and might cause confusion when entering into LORIS. Also not sure how aware data entry personnel are of the config options or desire for a study to have anonymized data.

I'm open to hearing your opinions as well.
@ridz1208 @maltheism

[maltheism]

@jesscall @johnsaigle @ridz1208 I think having the actual day is important in keeping things consistent. Although, I doubt having the correct day of the month when a person died compared to a few days off is really valuable. It's probably better to not fake a day from the software side of LORIS.

Why not just force the configuration module for DOB & DOD Format to always have "d" in the input field and an input error is displayed if otherwise. You could use regex.

Maybe there should be a field for notes and where if the day isn't known the study admin would just add a note.

[ridz1208]

@maltheism those are ethics regulated requirements, some projects are not allowed to save the day of the date of birth because it's identifiable

[maltheism]

@ridz1208 hmm if that's the case maybe there should be two more date columns in database.
Ex. actual_dod, actual_dob, ethics_dod, ethics_dob

Someone that's born in the 1st of whatever month and dies on the 1st of whatever month. Wouldn't be happy if they were in the ethical study.

[ridz1208]

@maltheism the idea is that we can't store the actual values in the database just like we can't store names and addresses

[maltheism]

@ridz1208 the ethics_dod or ethics_dob could be scrambled and the actual_dob & actual_dod would be left null depending on if it's an ethical study.

Edit: Maybe jess's solution is best after all if the person managing the study doesn't care about the date being accurate.

[jesscall]

@CamilleBeau I suspect the data truncation is happening because of the note i left about existing projects having different values than the preset formats. Should be solved by running the last 4 queries in the patch submitted.

[ridz1208]

@jesscall travis

[CamilleBeau]

Getting ERROR 1265 (01000) at line 2402: Data truncated for column 'DataType' at row 1 when sourcing raisinbread

[driusan]

Maybe it would be a good idea to show a more descriptive label for these on the frontend since it's a dropdown now?

Like 2015-12-29 (Ymd) and 2015-12 (Ym)?

(Date is arbitrary, just something that's unambiguous with the day of the month > 12.. I'm assuming m is numeric month, I haven't looked into it, but it would avoid that type of confusion for users to provide an example in the dropdown label..)