Bug 27507 - Search host record using control number identifier / organization code
Summary: Search host record using control number identifier / organization code
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Joonas Kylmälä
QA Contact: Katrin Fischer
Depends on: 29268 28830
  Show dependency treegraph
Reported: 2021-01-21 11:03 UTC by Joonas Kylmälä
Modified: 2023-05-03 19:38 UTC (History)
6 users (show)

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

Bug 27507: Specify organization code when searching host record (3.74 KB, patch)
2021-01-21 11:12 UTC, Joonas Kylmälä
Details | Diff | Splinter Review
Bug 27507: Specify organization code when searching host record (3.78 KB, patch)
2021-04-20 11:09 UTC, Martin Renvoize
Details | Diff | Splinter Review
Bug 27507: Specify organization code when searching host record (3.78 KB, patch)
2023-01-05 14:40 UTC, Andrii Nugged
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Joonas Kylmälä 2021-01-21 11:03:38 UTC
In /cgi-bin/koha/catalogue/detail.pl currently if you are viewing a record with 773w field the page shows "In: XXXX" with a search link to the host record. Currently when the 773w field format is in the LOC format of (OrgCode)ControlNumber we only search using the ControlNumber part. When importing records to Koha from different databases it is necessary to search also using the organization's code that is in the parentheses – otherwise we get in the results also unrelated records from other organizations.

We need the 003 / Control-number-identifier search addition from bug 11175 to implement this.
Comment 1 Joonas Kylmälä 2021-01-21 11:12:20 UTC Comment hidden (obsolete)
Comment 2 Marcel de Rooy 2021-01-21 12:33:33 UTC
Interesting !
Comment 3 Martin Renvoize 2021-04-20 11:09:50 UTC Comment hidden (obsolete)
Comment 4 Martin Renvoize 2021-04-20 11:12:39 UTC
This works as described and is something I've wanted to do for a while myself since first deep-diving into multi-part bibliographies.

Caveat, I wrote a lot of the details on the wiki around this area of functionality many years ago and most of that detail has since left my brain.. I'm not a cataloguer so can't really comment as to how correct this is vs how much of this goes on in the real world.. how backwards compatible it is.

I'd love to see a more library focused QA person get to grips with that side.. the dev side of me loves this refinement.

Wiki pages: https://wiki.koha-community.org/wiki/Multipart_Bibliographics
Comment 5 Martin Renvoize 2021-08-06 06:27:30 UTC
I've been doing some more work on bug 11175 and I think there might be a DRY solution to this we could use.. rather than using functions in the XSLT Utils I think we could/should be using the constructed query string from Koha::Util::Search, passing it as a variable as 11175 does for the inline view expansion over 300 records.

I'll submit that patch later today.
Comment 6 Martin Renvoize 2021-08-09 08:04:37 UTC
Waiting on some more cleaning up work being done on 11175
Comment 7 Katrin Fischer 2021-10-10 15:29:19 UTC
As Marcel already stated, this is really interesting!

I am starting with some simple testing and code review - I have not dug into 11175 yes, but I believe it covers a certain type of link, while what has been started here could be useful for a lot of the other link types.

1) Only add cni search part, if CNI is present

As the patch stands right now it will always add the AND cni: bit, even if the $w doesn't contain a CNI part. I think it would be a little nicer, if we made the template create the whole query string and account for the missing CNI part.

This template could then be easily reused for all 7xx and 8xx linking fields present in the code.

2) Staff and OPAC should be changed

We already got a lot of inconistencies here - so we should at least try not to make it worse. Same change should be applied to the OPAC files.

Glad to have some discussion!
Comment 8 Martin Renvoize 2021-10-18 17:42:54 UTC
Right... tidying up as taken place on bug 11175 now, but in fact this bug relates more closely to bug 20310 I believe.. that's where we add the reverse 'get_marc_host' query for fetching a host via the childs' 773 as this does here.

Katrin is right.. we need to have a think about the AND..  the above bug appears to handle it with an OR: `(OrgCode)ControlNumber OR ControlNumber` ... perhaps that could work here?
Comment 9 Martin Renvoize 2021-10-19 08:11:29 UTC
OK.. I'm coming to the conclusion I think the search in bug 20310 is wrong..
Comment 10 Martin Renvoize 2021-10-19 09:08:52 UTC
hmm, also $w appears to be repeatable.. should we be iterating here?

My thoughts so far.. we need a new function that.

1. Iterates through $w subfields and looks for one of the following:
1a. (RCI)Controlnumber where the RCI matches the OrgCode syspref
1b. Controlnumber
2. Once we've found the form we're expecting from above (1a in preference to 1b if both exist).
3. Produce the search string 'control-number=Controlnumber' for 1b. or `control-number=Controlnumber AND rci=RCI` if 1a is found.  It may also be helpful to add the `OR control-number=Controlnumber` search to 1a to account for cases where OrgCode was added to new children but was is missing from the host?

Does this sound viable?
Comment 11 Andrii Nugged 2021-10-26 20:27:12 UTC
ok, bug 11175 in master, let's move Bug 20447 and this one :).

Martin: I rebased 20447, now let's check what we can do here...
Comment 12 Andrii Nugged 2023-01-05 14:40:09 UTC
Created attachment 145063 [details] [review]
Bug 27507: Specify organization code when searching host record

This allows now importing records to Koha database from multiple
different organizations and keeps the "In: XXX" links in the
catalogue/detail.pl page unique.

To test:
 1) Add host record with 001 and 003 values of "1234" and "TEST"
 2) Add host record with 001 and 003 values of "1234" and "TEST2"
 2) Add component record with 773w value of (TEST)1234
 3) Notice the link in the component record goes to search page with
    two results
 4) Apply patch
 5) Notice the link in the component record goes directly to the first
    host record created with 001 = 1234 and 003 = TEST
 6) Test also that if you modify the 773w link with just the value of
    "1234" the search will still work and give you two results

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 13 Andrii Nugged 2023-01-05 14:41:51 UTC
(this one above is just rebased on the current master, 

let's see what to do further, 

our productions use this feature because it is related to related records so it's needed)
Comment 14 Martin Renvoize 2023-01-05 17:24:32 UTC
Right.. so going back to this.. I still think this patch is incorrect in it's implementation.. the idea taken forward in bug 11175 was to pass a prebuild query to the xslt rather than constructing it again.. i.e DRY coding so we don't fall out of sync again..

https://git.koha-community.org/Koha-community/Koha/src/branch/master/opac/opac-detail.pl#L621 - We pass the query to the template here.. seems it's moved out of the XSLT entirely now.. I can't remember without digging how it all fits together now.

But the point is.. we don't want the query to get out of sync between what's used server-side and what's displayed client-side.

I also still think the query needs work as bug 29268 highlights.
Comment 15 Andrii Nugged 2023-01-31 23:44:07 UTC
ah... and now it's totally incompatible with 

buy a huge lump, so even rebase is not straight.

I also need to "digging", because this also wasn't mine at the start :). Let's check further, what we can do.