To recreate: - turn off EasyAnalyticRecords - turn on UseControlNumer - find a bib, create a new child record from it - in the parent bib, confirm there is no "Show analytics" link - turn off UseControlNumber - confirm link now shows in parent record
Added bug 26333 as a see also. We've got one bug that impacts libraries with UseControlNumber on and another that impacts them if UseControlNumber is off, which is a bit of a bind.
The parent records needs to be a serial (LDR something = s), could this be the issue?
I saw bug 15851 about how this relates to the serials. Right now, the link shows on the parent record regardless of whether or not it's a serial if UseControlNumber is off. Is that the intended behavior? There absolutely may be some cataloging standard or intended behavior that I'm missing, but it seems like UseControlNumber should impact how the link is formed but not whether or not it appears in the first place.
(In reply to Andrew Fuerste-Henry from comment #3) > I saw bug 15851 about how this relates to the serials. > Right now, the link shows on the parent record regardless of whether or not > it's a serial if UseControlNumber is off. Is that the intended behavior? > There absolutely may be some cataloging standard or intended behavior that > I'm missing, but it seems like UseControlNumber should impact how the link > is formed but not whether or not it appears in the first place. Actually, on master it should depend on the LDR - only showing for serials. And useControlNumber should only impact how the link is built (what you said). I can't right now, but the XSLT should reveal it all. - Are they using standard ones? bug 15851 will change that, I think, but it will be 20.11 only as a new feature.
(In reply to Katrin Fischer from comment #4) > said). I can't right now, but the XSLT should reveal it all. - Are they > using standard ones? I've been playing with this in the default master data, which is using the default xslt
Hm in master Tomas dev will have changed the behaviour - it shoudl only show now if theere are linked records.
Ok, I have no retested this and also have issues with the link not showing up :( Tomas, any chance you could have a look? - My record was a serial - Used the "add child" functionality - Made sure 001 and $w were set The link to the analytical record doesn't show up with UseControlnumber, only without. Searchengine: Zebra
I will take a look tomorrow! You can check the query manually with yaz-client to see what's going on
(In reply to Tomás Cohen Arazi from comment #8) > I will take a look tomorrow! You can check the query manually with > yaz-client to see what's going on Haven't mastered that yet - but I will likely be around tomorrow if I can help in any way.
I've managed to reproduce this issue, but it took me a while to figure. As a start, I have to say that bug 15851 only highlighted another issue. That bug introduced a search to be done before rendering the detail page: 'rcn:'. $record->field('001')->data . ' AND (bib-level:a OR bib-level:b)' This search is the exact same search already existed on the always-diplayed link. In other words, if the link is not showing, it is because there are no results. And this means if we showed the link, it wouldn't produce results either. I managed to reproduce it simply by picking a record from the sample data, that contains a 001 field, and using the 'New child record'. Add a title, fix the missing fields and save. The host record didn't show the analytics link. But also Zebra didn't return any results: root@kohadevbox:koha(bug_26480)$ yaz-client unix://var/run/koha/kohadev/bibliosocket Connecting...OK. Sent initrequest. Connection accepted by v3 target. ID : 81 Name : Zebra Information Server/GFS/YAZ Version: 4.2.30 98864b44c654645bc16b2c54f822dc2e45a93031 Options: search present delSet triggerResourceCtrl scan sort extendedServices namedResultSets Elapsed: 0.006809 Z> base biblios Z> f @and @attr 1=1045 14207979 @or @attr 1=1021 a @attr 1=1021 b Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 0, setno 1 SearchResult-1: term=14207979 cnt=1, term=a cnt=2, term=b cnt=1 records returned: 0 Elapsed: 0.006004 Z> The CCL version (more readable, similar to the code) gives the same results: Z> querytype ccl2rpn Z> set_cclfile /etc/koha/zebradb/ccl.properties Z> f rcn=14207979 AND (bib-level=a OR bib-level=b) Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 0, setno 2 SearchResult-1: term=14207979 cnt=1, term=a cnt=2, term=b cnt=1 records returned: 0 Elapsed: 0.008100 Z> So the next step was to look for what is our pipeline sending Zebra for indexing: root@kohadevbox:koha(bug_26480)$ xsltproc /etc/koha/zebradb/marc_defs/marc21/biblios/biblio-zebra-indexdefs.xsl <(sudo koha-mysql kohadev <<< \ "select metadata from biblio_metadata where biblionumber=443 limit 1\\G" | \ sed -n 's/metadata: //;2,$p' ) <?xml version="1.0" encoding="UTF-8"?> <z:record xmlns:z="http://indexdata.com/zebra-2.0" xmlns:marc="http://www.loc.gov/MARC21/slim" xmlns:kohaidx="http://www.koha-community.org/schemas/index-defs" type="update" z:id="443"> <z:index name="llength:w">00337</z:index> <z:index name="rtype:w"> </z:index> <z:index name="Bib-level:w"> </z:index> <z:index name="Date/time-last-modified:w">20201112180000.0</z:index> <z:index name="date-entered-on-file:n">20111</z:index> <z:index name="date-entered-on-file:s">20111</z:index> <z:index name="pubdate:w"> </z:index> <z:index name="pubdate:n"> </z:index> <z:index name="pubdate:y"> </z:index> <z:index name="pubdate:s"> </z:index> <z:index name="pl:w"> </z:index> <z:index name="ta:w">|</z:index> <z:index name="ff8-23:w"> </z:index> <z:index name="ff8-29:w">0</z:index> <z:index name="lf:w">0</z:index> <z:index name="bio:w"> </z:index> <z:index name="ln:w">eng</z:index> <z:index name="ctype:w">||||</z:index> <z:index name="Record-source:w"/> <z:index name="Title-cover:w Title-cover:p Title-cover:s Title:w Title:p">Algo algo</z:index> <z:index name="Host-item:w">Conway, Damian</z:index> <z:index name="Host-item:w">Perl best practices /</z:index> <z:index name="Record-control-number:w">14207979</z:index> <z:index name="cn-bib-source:w">ddc</z:index> <z:index name="itemtype:w itemtype:p itype:w itype:p">CF</z:index> <z:index name="Local-Number:n Local-Number:w Local-Number:s">443</z:index> <z:index name="biblioitemnumber:n biblioitemnumber:w biblioitemnumber:s">443</z:index> <z:index name="Code-institution:w Record-source:w">Ost</z:index> <z:index name="Title:w Title:p">Algo algo</z:index> <z:index name="itype:0">CF</z:index> <z:index name="Any:w Any:p"> ...<output truncated, it is just Any indexes> You can see there is Record-control-number, with the right value on it. But if you look closer, you will notice the Bib-level index is empty. So that's it. I opened the record for editing, opened the LEADER builder, everything looks correct. Close it. And now the LEADER has more data on it. And on saving the searches in Zebra work, and the link is displayed as expected. In my opinion, this might be a bug. On how the default leader value it built, specifically on child records. Because when it is opened for creation, you see the 'a' or 'b' value, but the rest of the leader is empty and saving it produces a wrong behaviour.
(In reply to Katrin Fischer from comment #7) > > The link to the analytical record doesn't show up with UseControlnumber, > only without. If UseControlNumber it produces a search on the title (773$t) so it is expected to find things. > Searchengine: Zebra We should file a bug for the default leader created. I'm not sure it affects ES the same way, but as it will be offsets on the string, I guess the problem will be the same in ES.
Hm, I believed I had set the leader - because I had pointed out that exact thing in comment#4 - time to maybe give it another try.
(In reply to Katrin Fischer from comment #4) > (In reply to Andrew Fuerste-Henry from comment #3) > > I saw bug 15851 about how this relates to the serials. > > Right now, the link shows on the parent record regardless of whether or not > > it's a serial if UseControlNumber is off. Is that the intended behavior? > > There absolutely may be some cataloging standard or intended behavior that > > I'm missing, but it seems like UseControlNumber should impact how the link > > is formed but not whether or not it appears in the first place. > > Actually, on master it should depend on the LDR - only showing for serials. Right now, only for bib-level <> a AND bib-level <> b. Not just serials. https://gitlab.com/koha-community/Koha/-/blob/master/koha-tmpl/intranet-tmpl/prog/en/xslt/MARC21slim2intranetDetail.xsl#L201-231
(In reply to Katrin Fischer from comment #12) > Hm, I believed I had set the leader - because I had pointed out that exact > thing in comment#4 - time to maybe give it another try. Feel free to reopen it, if you find other ways to break it. This were just my findings. And I think it deserves its own bug (the fact that because of the added 'a' the leader is not auto-populated as the rest of the control fields.
Created attachment 174387 [details] Parent record I am able to recreate this bug with Elasticsearch 7 and the following records (child record will be added after as I can only add one at a time). The parent record has leader7 = s, and a 001. When I click on "Elasticsearch record", I can see both are indexed correctly. [...] "bib-level": [ "s" ], [...] "control-number": [ "14274" ], [...] On the child record, the parent's control number is in 773$w, indexed under record-control-number [...] "record-control-number": [ "14274" ], [...] UseControlNumber is set to Use. The Show analytics link does not show.
Created attachment 174388 [details] Child record
I forgot to mention that I imported both of those records in a fresh ktd with es7. If I disable UseControlNumber, the link appears but it is a search on title and in this case it's too vague (apparently a lot of genealogy serials are named Entre nous and they are not the same). That's why we really need the control number to specify which serial it is.
Hammat found that the child record has to have a or b in LDR/06. Which makes sense. However, why is the behaviour different with or without UseControlNumber? I think the behaviour should be consistent, unless someone can explain why it is different?