Bug 32747 - OPAC detail page explodes for items without itemtype
Summary: OPAC detail page explodes for items without itemtype
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: master
Hardware: All All
: P5 - low major (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
: 33351 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-01-30 16:02 UTC by Katrin Fischer
Modified: 2024-01-22 12:56 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2023-01-30 16:02:23 UTC
When there is an item without itemtype the OPAC detail page explodes:

Error trace

Can't call method "itemtype" on an undefined value at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 713


I know we agreed not to fix this everywhere, but I think there is definitely a need to fix it in this very spot, because it's on a main page in the OPAC. 


One thing that can cause this: We just very recently made itemtype mandatory on the acq item form. On order items often had no itemtypes in the past and it was not a problem. Libraries would assign the itemtype on delivery/receive, avoiding any issues in circulation. There might be quite a lot of those 'in the wild'.
Comment 1 Fridolin Somers 2023-02-21 18:30:24 UTC
Closely related to Bug 21842 that has been closed with wont fix.

I'd be happy to reopen it ;)
Comment 2 Katrin Fischer 2023-02-21 19:03:16 UTC
Not that close... we agreed on not always checking - but this is the end user exploding pages.
Comment 3 Fridolin Somers 2023-02-22 08:14:19 UTC
(In reply to Katrin Fischer from comment #2)
> Not that close... we agreed on not always checking - but this is the end
> user exploding pages.

Indeed, OPAC should be bulletproof ^^
Comment 4 Jonathan Druart 2023-02-22 08:30:46 UTC
This is caused by data inconsistencies, there is a script to catch them. We should not fix that IMO.
Comment 5 Jonathan Druart 2023-02-22 08:32:10 UTC
(In reply to Fridolin Somers from comment #3)
> (In reply to Katrin Fischer from comment #2)
> > Not that close... we agreed on not always checking - but this is the end
> > user exploding pages.
> 
> Indeed, OPAC should be bulletproof ^^

No, data should be correct. We provide a script that must be run when data is migrated. Then it's no longer possible to break it using the UI (unless you mess with the config).
Comment 6 Katrin Fischer 2023-02-22 09:29:43 UTC
Koha does only have a recent history of enforcing the itemtype as a mandatory field. We have tried to get libraries to fix things, but it's not an easy process. Especially as the acq form didn't have it mandatory until ... last release?
The data inconsistencies script is fine for migrations, but libraries using Koha for a long while don't know about it. 

This is what I think, being a bit more lenient... but I guess you got a point too.
Comment 7 David Cook 2023-03-29 23:25:17 UTC
*** Bug 33351 has been marked as a duplicate of this bug. ***
Comment 8 David Cook 2023-03-29 23:26:10 UTC
Looks like Pierre Chalon is reproducing this out of the box on PTFS Europe and BibLibre's sandboxes.
Comment 9 Katrin Fischer 2023-10-28 15:07:09 UTC
(In reply to David Cook from comment #8)
> Looks like Pierre Chalon is reproducing this out of the box on PTFS Europe
> and BibLibre's sandboxes.

The bug is definitely confirmed and real. 

The problem is: should we fix it or not. Item type is no mandatory and Koha won't work correctly without it in a lot of places.
Comment 10 Katrin Fischer 2023-10-28 15:07:20 UTC
So: is this a WONTFIX?
Comment 11 Victor Grousset/tuxayo 2024-01-22 12:56:24 UTC
Should the error be more graceful? To be more straightforward in making it known to librarians that some cataloguing work is needed on old data.
So that they don't need to have their sysadmin/provider investigate the error (whose message is likely hidden in production) to know the cause.

And/or a least add check in about.pl (it doesn't complain currently)