Using incorrect date format in resource cost history results in cost history data loss

[erohlfs]

When using the Resource cost history's sub start and sub end with the mm/dd/yyyy format, any variation other than mm/dd/yyyy will result in a loss of existing cost history data.
To recreate:

1. Create a few cost history entries using mm/dd/yyyy, Add, and Submit
2. Verify that you now see those entries in your cost history
3. Click edit cost history
4. Now, create a new entry that does not use mm/dd/yyyy (this could be either yyyy/mm/dd or simply have a typo such as mmdd/yyyy) - the same issue will occur whether you enter a non mm/dd/yyyy format in either the sub start or sub end fields
5. Coral will let you Add. When you click Submit, the submit button will gray out and no further action occurs
6. Click Cancel
7. Refresh your resource and go back into acquisitions
8. Note that either all of your previously entered cost history is gone or CORAL has retained an entry

There are a few issues other than the loss of data entry. 1. No error message letting the user know that an improper date format was used. 2. It's not obvious to the user why Coral retained a certain entry versus deleting the others (I've seen it retain first entry, most recent year, highest payment. I can't pinpoint why CORAL selects a specific entry's data to retain).

[erohlfs]

2. It's not obvious to the user why Coral retained a certain entry versus deleting the others (I've seen it retain first entry, most recent year, highest payment. I can't pinpoint why CORAL selects a specific entry's data to retain).

It looks like CORAL may be retaining the last entry created, prior to the attempt to add an entry with an incorrect date format.

[LibrarianMike]

Here is hoping we can get this fixed -- I have bad habit of triggering it at least once in a session of updating cost histories....

[LibrarianMike]

This bug is still present in 2024.10 and the Accessibility branch. In 2024.10 it appears to trigger a window hang, but when the page is refreshed, all cost history information for the resource will disappear.

[stephanieleary]

In resources/ajax_processing/submitCost.php, line 10, all existing payments are deleted before the incoming data is processed and validated. If there is anything in the cost history form that causes $resourcePayment->save(); to fail, the old data is never restored.

We need to process and validate the form input before replacing the existing data.