Bug 32747

Summary:	OPAC detail page explodes for items without itemtype
Product:	Koha	Reporter:	Katrin Fischer <katrin.fischer>
Component:	OPAC	Assignee:	Bugs List <koha-bugs>
Status:	RESOLVED WONTFIX	QA Contact:	Testopia <testopia>
Severity:	major
Priority:	P5 - low	CC:	dcook, fridolin.somers, jonathan.druart, martin.renvoize, pierre.chalon, victor
Version:	Main
Hardware:	All
OS:	All
See Also:	https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21842 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31538 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35896
Change sponsored?:	---	Patch complexity:	---
Documentation contact:		Documentation submission:
Text to go in the release notes:		Version(s) released in:
Circulation function:

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)

Comment 12 Martin Renvoize (ashimema) 2024-06-10 16:10:31 UTC

We have other bugs to expose the data checks to librarians more easily.. I think those will help here and we can't easily code around incorrect data.