[Bug 26480] New: With UseControlNumber on, "Show analytics" link doesn't show on parent record
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 Bug ID: 26480 Summary: With UseControlNumber on, "Show analytics" link doesn't show on parent record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs@lists.koha-community.org Reporter: andrew@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: m.de.rooy@rijksmuseum.nl 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=26333 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 --- Comment #1 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 --- Comment #2 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- The parent records needs to be a serial (LDR something = s), could this be the issue? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 --- Comment #3 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 --- Comment #4 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 --- Comment #5 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- (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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 --- Comment #6 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hm in master Tomas dev will have changed the behaviour - it shoudl only show now if theere are linked records. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 Lucy Vaux-Harvey <lucy.vaux-harvey@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucy.vaux-harvey@ptfs-europ | |e.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |15851 Severity|normal |major CC| |tomascohen@gmail.com --- Comment #7 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 [Bug 15851] Only display "Analytics: Show analytics" when records have linked analytics -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 --- Comment #8 from Tomás Cohen Arazi <tomascohen@gmail.com> --- I will take a look tomorrow! You can check the query manually with yaz-client to see what's going on -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 --- Comment #9 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |tomascohen@gmail.com |ity.org | Keywords| |rel_20_11_target CC| |jonathan.druart@bugs.koha-c | |ommunity.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |INVALID --- Comment #10 from Tomás Cohen Arazi <tomascohen@gmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 --- Comment #11 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m, katrin.fischer@bsz-bw.de -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 --- Comment #12 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 --- Comment #13 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (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... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 --- Comment #14 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rel_20_11_target | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 Bug 26480 depends on bug 15851, which changed state. Bug 15851 Summary: Only display "Analytics: Show analytics" when records have linked analytics https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to master |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 Magnus Enger <magnus@libriotech.no> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=31608 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |caroline.cyr-la-rose@inlibr | |o.com --- Comment #15 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- Created attachment 174387 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=174387&action=edit 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 --- Comment #16 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- Created attachment 174388 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=174388&action=edit Child record -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |--- Status|CLOSED |REOPENED --- Comment #17 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 --- Comment #18 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- 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? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #19 from David Cook <dcook@prosentient.com.au> --- (In reply to Caroline Cyr La Rose from comment #18)
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?
I think https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11175 caused some problems... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 --- Comment #20 from David Cook <dcook@prosentient.com.au> --- (In reply to Caroline Cyr La Rose from comment #18)
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?
And I'm seeing "Show analytics" when I shouldn't because without "UseControlNumber" it doesn't check for the component part "a" or "b"... When searching the title, we're also not doing a phrase search when we should be... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|With UseControlNumber on, |"Show analytics" display is |"Show analytics" link |very inconsistent |doesn't show on parent | |record | --- Comment #21 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #20)
When searching the title, we're also not doing a phrase search when we should be...
Actually, I think in Elasticsearch it is doing a phrase search, but it means that if a bib record has a title of "Brotherhood", it will display a "Show analytics" link, because there are other records that have 773$t "Brotherhood of Awesomeness" or something like that. We could do an exact search instead, but that's risky. There's been too many competing approaches to analytics in Koha over the years... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26480 --- Comment #22 from David Cook <dcook@prosentient.com.au> --- This is a tough one. My recommendation is going to be to embrace "UseControlNumber", "autoControlNumber", and ensuring 773$w and LDR07 are set appropriately. That requires no changes to Koha and it is systematically logical. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org