Internal server error on viewing full record when copy create_date is null

Bug #1418772 reported by Jeff Davis on 2015-02-06
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Undecided
Unassigned
2.6
Undecided
Unassigned
2.7
Undecided
Unassigned

Bug Description

I've confirmed this issue in both 2.6 and master, using the XUL client. I haven't confirmed it with the web-based client, but I expect the issue to exist there too.

Steps to replicate:
1. Set create_date to NULL for a record in asset.copy.
2. In the staff client, attempt to view the bib record that your example item is attached to. Instead of seeing the record, you'll get an Internal Server Error.

The issue is that the parse_datetime function in EGCatLoader/Util.pm can't handle an undefined date. It's unnatural for asset.copy.create_date to be null, so the error is uncommon, but the situation can arise with migrated legacy data and so on.

Jeff Davis (jdavis-sitka) wrote :

I've pushed a fix to working branch user/jeffdavis/lp1418772_error_on_null_create_date:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=a400928

This fixes the issue in master, but the fix may not apply cleanly to earlier versions of EG, since copy_table.tt2 has changed since 2.6.

tags: added: pullrequest
Galen Charlton (gmc) wrote :

I've pushed this to master, rel_2_6, and rel_2_7. Note that because of the prior push of the patches for bug 1366026 to master and merge conflicts with rel_2_6, each branch has a slightly different variation. I also added a follow-up so that unitialized variable warnings wouldn't be logged if an undef date was passed to parse_datetime.

Thanks, Steven and Jeff!

Changed in evergreen:
milestone: none → 2.8-beta
status: New → Confirmed
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers