https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29016 --- Comment #37 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198351 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198351&action=edit Bug 29016: (QA follow-up) Restore biblio<->item log expansion The catalog detail page links to the modification log with modules=CATALOGUING&object_type=biblio&object=<biblionumber>. The old server-rendered viewer matched both biblio-level entries (object = biblionumber, info LIKE 'biblio%') and item-level entries (object IN (itemnumbers of this biblio), info LIKE 'item%'). Converting to the AJAX DataTable kept that expansion only in the CSV export branch, so the on-screen view silently dropped item-level history. Recreate the expansion in the AJAX path: * tools/viewlog.pl: when (single CATALOGUING module + object_type =biblio + non-empty object) collect the biblio's itemnumbers and expose them, along with object_type, to the template. * viewlog.tt: include object_type and biblio_itemnumbers in the search_params JSON the inline script builds for the JS. * viewlog.js: when those params are present, build the same -or clause the old SQL produced and skip the regular per-object filter. The info substring filter is also suppressed in that branch (the old code did the same: it dropped %info% in favour of the -or). Test plan: 1. Enable CataloguingLog. 2. Edit the biblio and a couple of its items. 3. From the biblio detail page, open "Modification log". 4. Verify the table shows both the biblio MODIFY rows and the item MODIFY rows for that biblio (and only those). 5. From Tools -> Log viewer, plain Cataloguing filter still returns the unfiltered log set as before. -- You are receiving this mail because: You are watching all bug changes.