Description
Joonas Kylmälä
2021-01-21 11:03:38 UTC
Created attachment 115528 [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 Interesting ! Created attachment 119904 [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> 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 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. Waiting on some more cleaning up work being done on 11175 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! 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? OK.. I'm coming to the conclusion I think the search in bug 20310 is wrong.. 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? 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... 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> (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) 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. ah... and now it's totally incompatible with koha-tmpl/intranet-tmpl/prog/en/xslt/MARC21slim2intranetDetail.xsl 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. |