Two works can't be edited

[grahamjevon]

The following two works were uploaded via BX. But when I click on "Edit", I get an error:

• https://bl.iro.bl.uk/concern/datasets/12208b77-74d6-44b5-88f9-df04db881d63
• https://bl.iro.bl.uk/concern/datasets/ef537c70-87cb-495a-86c8-edffefa6bdc6

I believe the cause of this error is an invalid date format in the "submitted to publisher" field.

Presumably the solution is to either:

• edit this field in the console so the error is removed
• delete this work so that a replacement work can be added

[cziaarm]

F, [2023-09-26T20:18:30.244145 #1] FATAL -- : [2e7fbe96b334bcaa7f6c243553526056]   
F, [2023-09-26T20:18:30.244208 #1] FATAL -- : [2e7fbe96b334bcaa7f6c243553526056] ActionView::Template::Error (invalid date):
F, [2023-09-26T20:18:30.244342 #1] FATAL -- : [2e7fbe96b334bcaa7f6c243553526056]      8: </label>
[2e7fbe96b334bcaa7f6c243553526056]      9: <p class="help-block"><%= t("simple_form.hints.defaults.date_#{date_type}") %></p>
[2e7fbe96b334bcaa7f6c243553526056]     10: 
[2e7fbe96b334bcaa7f6c243553526056]     11: <%= select_year(parse_date(f.object.model.send("date_#{date_type}"), 'year').to_i,
[2e7fbe96b334bcaa7f6c243553526056]     12:                   {
[2e7fbe96b334bcaa7f6c243553526056]     13:                     start_year: (Date.today.year + 6),
[2e7fbe96b334bcaa7f6c243553526056]     14:                     end_year: (Date.today.year - 159),
F, [2023-09-26T20:18:30.244374 #1] FATAL -- : [2e7fbe96b334bcaa7f6c243553526056]   
F, [2023-09-26T20:18:30.244404 #1] FATAL -- : [2e7fbe96b334bcaa7f6c243553526056] app/services/ubiquity/parse_date.rb:50:in `strptime'
[2e7fbe96b334bcaa7f6c243553526056] app/services/ubiquity/parse_date.rb:50:in `parse_date_by_format'
[2e7fbe96b334bcaa7f6c243553526056] app/services/ubiquity/parse_date.rb:23:in `return_date_part'
[2e7fbe96b334bcaa7f6c243553526056] app/helpers/ubiquity/date_change_helper.rb:5:in `parse_date'
[2e7fbe96b334bcaa7f6c243553526056] app/views/shared/ubiquity/dates/_date_fields.html.erb:11:in `_app_views_shared_ubiquity_dates__date_fields_html_erb__1464356250071594816_33112640'
[2e7fbe96b334bcaa7f6c243553526056] app/views/shared/ubiquity/dates/_date_submitted.html.erb:4:in `_app_views_shared_ubiquity_dates__date_submitted_html_erb___2172055316231889650_33112940'
[2e7fbe96b334bcaa7f6c243553526056] app/views/records/edit_fields/_date_submitted.html.erb:2:in `_app_views_records_edit_fields__date_submitted_html_erb___3011452234801469780_33112920'
[2e7fbe96b334bcaa7f6c243553526056] app/views/hyrax/base/_form_metadata.html.erb:15:in `block in _app_views_hyrax_base__form_metadata_html_erb__3986029924638840220_33112340'
[2e7fbe96b334bcaa7f6c243553526056] app/views/hyrax/base/_form_metadata.html.erb:14:in `each'
[2e7fbe96b334bcaa7f6c243553526056] app/views/hyrax/base/_form_metadata.html.erb:14:in `_app_views_hyrax_base__form_metadata_html_erb__3986029924638840220_33112340'
[2e7fbe96b334bcaa7f6c243553526056] app/controllers/application_controller.rb:162:in `inject_theme_views'
[2e7fbe96b334bcaa7f6c243553526056] app/middleware/no_cache_middleware.rb:11:in `call'

[cziaarm]

https://github.com/scientist-softserv/britishlibrary/pull/478

[cziaarm]

Hi @grahamjevon,

This error was being caused by the fact that incoming dates of the format "DD/MM/YYYY" (which can be saved via Bulkrax), cannot be parsed as the the thing that parses the dates and puts them in the edit form only handles "MM/DD/YYYY".

I have assumed that we want UK date formats and switched around the date parse to expect those. This will fix the error you reported (once deployed to production). I have tested this on staging with the record https://bl.bl-staging.notch8.cloud/concern/datasets/4506e7b1-4df4-4002-b21e-60acde4d6165

A caveat: The date parsing cannot handle both types of the dates... it is either one or the other. While UK format is probably the right way to go, if we have dates stored in the US format the will error in exactly the way you have reported above.

[grahamjevon]

Good news. The BL repo only has 23 records that have a BX ID and contain a date that is more than just a year. This is a manageable number to check manually when the date parser is changed. I'd be very surprised if any of the other tenants contain more than this, but I will check to be safe. But form that perspective, I think it will be ok to deploy this.

I note that in the export, some of these dates are in format 06/10/2023 and some are in 2023-10-06 (See #484 for another ticket related to this). Should we prioritise one of these formats in the csv template when importing or can the repo be tweaked to ope with both? Currently, I aim to follow "2023-10-06", but am mindful that Excel likes to switch it (though we warn partners against using Excel).

[cziaarm]

Hi @grahamjevon, thanks for checking through those.

It'll cope with either DD/MM/YYYY or YYYY-MM-DD (just not both the slash-based formats at the same time).

I guess that the duality has come from the original date input from the form that UB put in and the date handling from Bulkrax. TBH It would be easier if all dates to be stored the same way (even if we are being unfussy about how they are entered) #484 is a good example of needing to be aware of all possible date storage formats... I'll follow up on that ticket, but sounds like we are happy to deploy this change #478 ? (which is specifically the edit form handling DD/MM/YYYY dates as opposed to MM/DD/YYYY ones)

[grahamjevon]

Yes, we are happy to deploy this change. I have checked exports from all the tenants and there are minimal works added via BX with a full date that might be affected by this switch. And they probably need checking anyway.

[NoraRamsey]

I've reviewed the metadata from the tenants and I'm happy to pass this along