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.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
3089c74f6f