https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Zeno Tajoli <z.tajoli@cineca.it> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.tajoli@cineca.it --- Comment #2 from Zeno Tajoli <z.tajoli@cineca.it> --- In unumarc is possible to use Leader pos. 8 [Hierarchical code]. The value '1' means 'highest level record', so it is sure it has children. In MARC21 I think we need a proprietary subfield. I suggest one from tag 942. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #4 from Zeno Tajoli <z.tajoli@cineca.it> --- We can change the wording.

From "Analytics: Show analytics" to "Analytics: Search if present".

-- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #6 from Hugo Agud <hagud@orex.es> --- 3rd. move to the OPAC the current functionality that indicates that some items includes analytics like the intranet does . -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@bugs.koha-c | |ommunity.org --- Comment #8 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- As I am not sure to understand the need correctly, I have provided a quick (and dirty) patch. Let me know if it fixes the needs and I will improve it later if it is what you are waiting for. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #10 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- The flag ($analytics_flag) is set from detail.pl:289 286 #count if item is used in analytical bibliorecords 287 my $countanalytics= GetAnalyticsCount($item->{itemnumber}); 288 if ($countanalytics > 0){ 289 $analytics_flag=1; 290 $item->{countanalytics} = $countanalytics; 291 } -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #12 from Zeno Tajoli <z.tajoli@cineca.it> --- Hi, in fact Katrin underline the problematic point: in MARC21 standard catalouging nothing in parent biblio record of a serial says if it has analitics. Probably a good option is: 1)A new Sys pref "AnaliticsWithControlNumbers" and say: "Set it 'ON' only if you use control numbers in 77x$w and don't use EasyAnalytics". 2)A new function like "GetAnalyticsCount" but based on controlnumber and rcn-Index. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #14 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Hugo Agud from comment #13)

At the what we need is to know if a bib record has analytics, we do not need silly xslt links based on bib-leve:s (journals) and on the other hand we have forgotten about chapters not only serial (bib-level:b)

The links have been created so you can hide them very easily with CSS if you don't want or need them.

The link between bib and analytics is 773 field... here the big issue is most of fields are text 773$t and the one to one link are 773$0 773$9 or even 773$x(issn (journals) or 773$w(controlnumber) depends on every library, how they have created the analytics...they will have more or less filled tags

If you're using koha and have created the analytics with koha you will have a nice 773 to work create links ;)

Not all libraries catalog solely in Koha. But: you can create analytics within Koha in 2 different ways already. One is EasyAnalytics which is tied to the items, the other is from the detail view available as well and supports Controlnumber linking: New > New child record. If a 001 exists, it will be used. The different linking methods/options are the reson that there is a fallback from $w to a Title search. More logic could be added there to include other possible good search parameters like ISBN/ISSN.

Now in the staff cients, in the analytics tab you have info about if that item has anaytics attached and how many... because the 773$9 (one to one link and it works fine)

Please keep in mind that this is only available for libraries using EasyAnalytics.

I think there is not a 100% solution, because there will be plenty of different situations and one solution won't match all possible situations

I like the idea of the syspref 'GetAnalyticsCount' but we must be clear enought with the customers explaining how the links works

The idea it should be, that the library must check their current 773 tags and fix it. (they have a nice batch record modification tool)

There is 3 potential ways: for current biblionumber --> appear the link if there is any 773$0 that matchs the biblio or

There is no $0 defined for 773 in MARC standard?

for current itemnumbers --> appear a link if there is any 773$9 that matchs the itemnumber

or for current issn --> apprear a link if there is any 773$x that matches 022$a

Please don't forget $w here - it's actually one of the best possible links, as the matching should be exact based on ID.

I don not like the control-number: the use of control number I dislike because koha is not using 001 control-number

Please keep other workflows in mind. Our records are linked outside of Koha by ID in an external cataloguing environment, everything is held together by 001. One central cataloguing environment, data delivered to lots of different ILS. Also: 001/$w IS MARC standard. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Joy Nelson <joy@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joy@bywatersolutions.com --- Comment #15 from Joy Nelson <joy@bywatersolutions.com> --- Cait- I can appreciate that your libraries have workflows related to analytics here. However, the vast majority of other libraries using MARC21 standard do not intend the Leader position 7 to indicate that there are analytics present. I believe that Koha should be displaying the bibliographic data in a way that is accurate to the data that is entered. In this case not display an analytic tag just because leader position 7 =s. I have a number of libraries who would love to see this 'feature' removed and have Koha catalog and display in the correct fashion (according to marc21 standards). joy -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #17 from Joy Nelson <joy@bywatersolutions.com> --- Cait- I agree that this could be a responsive feature in Koha. However, to most librarians it appears that Koha is 'doing something' (displaying analytic links) that is not supported by the correct cataloging of records. Catalogers put a lot of effort into correctly cataloging their collections. And when this cataloging results in behavior that is not related to the industry standards, it causes frustration, confusion and some lack of confidence in the tool. Yes, it could be hidden, but by doing so we are expecting the bulk of Marc21 libraries to hide something that should never be there in the first place. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #19 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I'd be happiest with a solution where we fixed the idea from Jonathan so that it works for both use cases - EasyAnalytics and simple 773 linking. Looking at the patch it seems to be missing the code to actually calculate the $analytics_flag? I think we could all agree that this would be a nice enhancement, showing a link only when there are analytics. Or just never show a link if EasyAnalytics is used? I am just not sure how to do it, which is the whole reason it was not implemented like that from the beginning :( With some guidance I would be happy to give it a try. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #20 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Joy Nelson from comment #17)

Cait- I agree that this could be a responsive feature in Koha. However, to most librarians it appears that Koha is 'doing something' (displaying analytic links) that is not supported by the correct cataloging of records. Catalogers put a lot of effort into correctly cataloging their collections. And when this cataloging results in behavior that is not related to the industry standards, it causes frustration, confusion and some lack of confidence in the tool.

Yes, it could be hidden, but by doing so we are expecting the bulk of Marc21 libraries to hide something that should never be there in the first place.

Sounds reasonable to me. 'Can you hide it' should not be the approach imo.. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #22 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Sorry, 2011. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Brian <bklein@dubuque.lib.ia.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bklein@dubuque.lib.ia.us --- Comment #23 from Brian <bklein@dubuque.lib.ia.us> --- Has any more progress been made on Bug 15851? Carnegie Staff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #25 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hi Joy, sorry, I missed getting back to this :( (In reply to Joy Nelson from comment #24)

Katrin, Currently this analytic feature only works where the leader7=s. I'd like to propose the following changes to this feature to allow it be used by your library and others in a more standard method.

1. Allow the link to appear when leader7 =s or leader7=m. Both monographs and serial records can have component parts and as such have children that should be displayed by this feature. The Show analytics link is searching for bib-level:a (Monographic component part) and bib-level:b (Serial component part).

Yes, that makes sense. Actually we have that link in some custom XSLT, but use a different class to allow changing visibility independently for m and s.

2. Add a search function to this display page that checks the index (Host-item) to see if any children are present. If so, then display the "Show Analytics Link". This search would search for control number or title depending on the value of usecontrolnumber sys pref.

I would be totally ok with that. I just never figured out how to do this myself. Some help here would be great. I am not sure Host-item will work as an index or if a new index for $w in 773 would be needed for the controlnumber part.

3. Add a syspref for this method of analytic cataloging, much like we have for Easy Analytics and 'use control number'. Allow libraries the ability to turn off the analytic cataloging if they don't use it. Call it "ShowLinktoChildfromParent"?

I am not sure about adding more and more prefs when CSS would work, but if we add the function in 2) it makes sense to have a real switch to avoid unnecessary processing. I had some hope that [Bug 11175] Show the parent record's component parts in the detailed views would help resolve the issues or replace the current way, but it hasn't worked out. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=7107 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #28 from Hugo Agud <hagud@orex.es> --- 100% agree katrin, perfect summary! However I have been thinking on it and I suggest to go one step further, add to the scrip the chance of filling 001 with 999$c In some migrated libraries they came to koha using type2 (773w-->001), the issue is that 001 is mandatory for linking and at koha is empty by default, I suggest to add an option to the script to copy 999c to 001 and helps librarian to create anañytics using 773$w--001 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #30 from Hugo Agud <hagud@orex.es> --- At the end what we wish display the link propertly .... the only issue (it is big) it could came with counter, not with the link. I mean if we have one bib record and one analytic with all fields filled (773W0 --> 001 + 773$0 or even 773$9) The worth scenario is couning two times, but even then we have a valid link with but wrong count number... ok, 100% agree but evern is better to have no links ;) On the other hand it is just a matter of dedup linking I mean, host bib couldn't link to same bib analyic record more than one...then if the count take care of that, issue fixed Almost all migrsted libraries have analytics using 773$w and 773$0, and perhpas some of them will migrate from 773w to 7730 because is stronger and better as you can add analytics to issue level, if we manage that, the solution is stronger -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|gmcharlt@gmail.com |tomascohen@gmail.com Change sponsored?|--- |Sponsored CC| |tomascohen@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #32 from Tomás Cohen Arazi <tomascohen@gmail.com> --- I've started thinking on a solution to this, due to my recent works on XSLTs and plugins. I'll keep you posted. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #34 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I understand the disagreement, but we have added lots of other information on the base that it can be hidden with CSS if unwanted - serials are more likely to have analytics than monographs, so that's why the limit was introduced in the first place. In our own XSLT we also have a version for monographs (same but different class) and control both of them with CSS. But I know our libraries would love it too to only see it when there actually are child records. I am not sure I understand how 1) would look like, can you explain a bit more? With 2) we also need to account for every way a record can be added or edited in Koha - including the imports. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #36 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 106260 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=106260&action=edit Bug 15851: Display analytics links for more cases The current XSLT displays the link to linked analytics only for serials. This patch makes it show for all the relevant position 7 on the leader values. I left out a and b as recommended by expert librarians on my team, but I can revert that if required. The current implementation adds a new CSS class for each case, so libraries willing to keep the current behaviour or just have more granular control on the cases they want the link to display, just can. This patch makes sense with the follow-up one, which will display the link only if there are really related records. To test: 1. Open a non-serial record, notice there's no link to analytics 2. Apply this patch and reload => SUCCESS: There's an 'Analytics' link 3. Inspect the produced HTML => SUCCESS: A special class with analytic_* value has been added, and thus we now can control its display through CSS 4. Sign off :-D Sponsored-by: Orex Digital -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #38 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Ok, this is my attempt. The basic idea is split in two: - Display analytic links for more cases (i.e. not just serial) - If the result for showing the link is considered (today) good enough, just use the same query in the code to make the decision on the .pl+XSLT combination If this approach to 'hiding when unnecessary' is good enough (I think it is) we could file a new but for adding new conditions (like ISBN, etc). Feedback welcome! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #40 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Hugo Agud from comment #39)

I hae tested the patch and it works fine! however the code applied to opac is not applied to staff xslt and it shows the links always, even when there is not analytics.

My idea was to have feedback on the approach, and then move to other areas. The 'how to find analytics' discussion (i.e. the queries that are done) should be moved to another bug, for example. Thanks for testing, and I will add the intranet counterpart for you to SO ASAP. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Hugo Agud <hagud@orex.es> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #106260|0 |1 is obsolete| | --- Comment #41 from Hugo Agud <hagud@orex.es> --- Created attachment 106821 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=106821&action=edit Bug 15851: Display analytics links for more cases The current XSLT displays the link to linked analytics only for serials. This patch makes it show for all the relevant position 7 on the leader values. I left out a and b as recommended by expert librarians on my team, but I can revert that if required. The current implementation adds a new CSS class for each case, so libraries willing to keep the current behaviour or just have more granular control on the cases they want the link to display, just can. This patch makes sense with the follow-up one, which will display the link only if there are really related records. To test: 1. Open a non-serial record, notice there's no link to analytics 2. Apply this patch and reload => SUCCESS: There's an 'Analytics' link 3. Inspect the produced HTML => SUCCESS: A special class with analytic_* value has been added, and thus we now can control its display through CSS 4. Sign off :-D Sponsored-by: Orex Digital Signed-off-by: Hugo Agud <hagud@orex.es> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #106821|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #43 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 106988 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=106988&action=edit Bug 15851: Display analytics links for more cases The current XSLT displays the link to linked analytics only for serials. This patch makes it show for all the relevant position 7 on the leader values. I left out a and b as recommended by expert librarians on my team, but I can revert that if required. The current implementation adds a new CSS class for each case, so libraries willing to keep the current behaviour or just have more granular control on the cases they want the link to display, just can. This patch makes sense with the follow-up one, which will display the link only if there are really related records. To test: 1. Open a non-serial record, notice there's no link to analytics 2. Apply this patch and reload => SUCCESS: There's an 'Analytics' link 3. Inspect the produced HTML => SUCCESS: A special class with analytic_* value has been added, and thus we now can control its display through CSS 4. Sign off :-D Sponsored-by: Orex Digital Signed-off-by: Hugo Agud <hagud@orex.es> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #45 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 106990 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=106990&action=edit Bug 15851: (follow-up) Only display the analytics link when required (staff) This patch replicates the introduced behaviour, for the admin interface. To test, follow the test plan from the OPAC, but on the intranet. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #47 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to David Cook from comment #46)

I was wondering what kind of performance impacts this would have on a large database with lots of analytics, but a code review shows that it looks good enough (depending on your views).

Looking at C4::Search::SimpleSearch, we're passing an offset of 0 and max_results of 0, which generates a range of 1..0 which is nothing, so no records are actually fetched from Zebra.

It's not very elegant, but it should be functional, even for a large database.

I take it as a compliment-ish comment, thanks :-P

I tested an unrelated search using yaz-client on a very large database (over 1 million bib records), and for a query with 17626 hits, it took .432 seconds.

Can you give me the query so I can try on my databases as well?

For some people, adding .432 seconds to web page load time is unacceptable, but I imagine most of us might not care too much.

I'd agree. We could make it an opt-in feature? PreciseAnalyticsLink or smth.

I'd argue that this lookup should be performed asynchronously after the HTML page has loaded.

The MARC data could trigger whether to show an "Analytics" label I suppose, and then the result of the async lookup would say something like "Show Analytics" or "None" or something like that.

Anyway, that's just a thought. I'm not interested in doing any work on this. I'm just always interested in performance.

The current patches are fine, so I'm not being critical, but I think an optimization would be to do an async lookup.

I like the idea. Will draft an endpoint for fetching such information using the exact queries we use here. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #49 from David Cook <dcook@prosentient.com.au> --- Ok using .yazclientrc to set the following: 1. querytype ccl2rpn 2. set_cclfile /path/to/etc/zebradb/ccl.properties Trying the following: 1. Host-item="This is a test" 2. rcn=1000 and (bib-level=a or bib-level=b) Both of these returned results in 0.002 seconds with 0 hits. The search performance is interesting. Going back to these: 1. "find e" 2. "find the" They're both using the "Any:w" index, but "e" takes .09 seconds to return 37500 hits while "the" takes 3.39 seconds to return 1125000 hits. Zebra has to take the same amount of time to scan the index, so the time spent in yaz-client isn't on Zebra finding the data. It's spent on either Zebra/yaz-client/both processing the data. The time taken seems to be linear/O(n) not for searching per se but rather in terms of returning a search result. Now it's just unclear whether it's Zebra or yaz-client (or both) causing the time delay. I might try writing a quick little Perl script to see how it fairs when using Zoom with Zebra... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #51 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to David Cook from comment #49)

Ok using .yazclientrc to set the following:

1. querytype ccl2rpn 2. set_cclfile /path/to/etc/zebradb/ccl.properties

Trying the following:

1. Host-item="This is a test" 2. rcn=1000 and (bib-level=a or bib-level=b)

Both of these returned results in 0.002 seconds with 0 hits.

The search performance is interesting.

Going back to these:

1. "find e" 2. "find the"

They're both using the "Any:w" index, but "e" takes .09 seconds to return 37500 hits while "the" takes 3.39 seconds to return 1125000 hits.

Zebra has to take the same amount of time to scan the index, so the time spent in yaz-client isn't on Zebra finding the data. It's spent on either Zebra/yaz-client/both processing the data.

The time taken seems to be linear/O(n) not for searching per se but rather in terms of returning a search result.

Now it's just unclear whether it's Zebra or yaz-client (or both) causing the time delay.

I might try writing a quick little Perl script to see how it fairs when using Zoom with Zebra...

Can you try zoomsh? Is what IndexData recommends. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #53 from David Cook <dcook@prosentient.com.au> --- yaz-client: e 37500 hits .09 seconds Koha: e 37500 hits 2.110 seconds (2 seconds being loading Perl modules, so .110 sec) yaz-client: the 1125000 hits 3.39 seconds Koha: the 1125000 hits 5.315 seconds (2 seconds being loading Perl modules, so 3.315 sec) If we convert from async code to sync code, we can get the following: 1125000 hits 3.78 seconds (2 seconds being loading Perl modules, so 1.78 sec) If we comment out the code after the search(), we can see that it still takes 3.7-4 seconds to run, so the time delay appears to be on the Zebra side. I see high CPU usage but not high memory usage, so it looks like it's processing something. Of course, Zebra is a bit of a black box for us. For a Plack enabled Koha, my guess is that this search should have a minimal impact, unless a bib record has hundreds of thousands/millions of articles referencing it. The highest hit is probably going to be < 100, and since the time is dependent on the size of the search result rather than the size of the index, database size should be irrelevant. The biggest impact in terms of performance will probably be loading Perl modules via "use Koha::SearchEngine::Search". For Plack, this will be a once off for a worker that hasn't loaded opac-detail.pl before. For CGI, it could add 1-2 seconds of latency each time opac-detail.pl is loaded. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #55 from David Cook <dcook@prosentient.com.au> --- (In reply to Tomás Cohen Arazi from comment #52)

And also the plain PQF query while you're on it

So the "e" and "the" queries are plain PQF queries. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Patch doesn't apply --- Comment #57 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Can you please rebase? Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 15851: Display analytics links for more cases Applying: Bug 15851: Only display the analytics link when required error: sha1 information is lacking or useless (koha-tmpl/opac-tmpl/bootstrap/en/xslt/MARC21slim2OPACDetail.xsl). error: could not build fake ancestor Patch failed at 0001 Bug 15851: Only display the analytics link when required The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem run "git bz apply --continue". If you would prefer to skip this patch, instead run "git bz apply --skip". To restore the original branch and stop patching run "git bz apply --abort". Patch left in /tmp/Bug-15851-Only-display-the-analytics-link-when-req-6AcS8l.patch -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #106988|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #106990|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #59 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 108050 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=108050&action=edit Bug 15851: Only display the analytics link when required This patch makes opac-detail.pl query for analytics the same way it would do with the generated link (i.e. based on UseControlNumber) and passes a flag to the XSLT so it displays (or not) the 'Analytics' link. To test: 1. Apply the first patch 2. Have a known record without analytics 3. Open the record in the OPAC => FAIL: It shows the 'Analytics' link 4. Have a record known to have analytics and open in OPAC, on a separate tab => SUCCESS: It shows the 'Analytics' link 5. Apply this patch and restart_all 6. Reload the tabs => SUCCESS: It shows the link where it has to, and hides it where it shouldn't be displayed 7. Sign off :-D Sponsored-by: Orex Digital Signed-off-by: Hugo Agud <hagud@orex.es> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #62 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Katrin Fischer from comment #61)

This works well without UseControlNumber so far, but when I turn it on, the link that was visible before, disappears:

Parent record: 001 15661423

Child record: LDR 00395 a2200121 4500 = monographic component part 773 0 _dCambridge, Mass. : Belknap Press of Harvard University Press, 2009. _aWilson, Peter H. _z9780674036345 (hardcover : alk. paper) _w15661423 _tThe Thirty Years War :

Can you please check?

Will check. If you use master, and the link shows. Does it give you any results? It now shows based on those results. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off --- Comment #64 from Tomás Cohen Arazi <tomascohen@gmail.com> --- This works, and only highlights UseControlNumber doesn't work correctly in ES, which should have it's own bug reported. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #66 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Katrin Fischer from comment #65)

(In reply to Tomás Cohen Arazi from comment #64)

...

This works, and only highlights UseControlNumber doesn't work correctly in ES, which should have it's own bug reported.

But with this applied the links all disappear for ES users - I think we should fix the other issue quickly because this will shine a bad light on a nice feature that we want to boldly advertise in release notes.

I agree. Can you file a bug for ES with your findings and make this one dependent on it? They are really unrelated. And ES it's showing non-working links anyway without this patch set -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=26313 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #108049|0 |1 is obsolete| | --- Comment #68 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 109267 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=109267&action=edit Bug 15851: Display analytics links for more cases The current XSLT displays the link to linked analytics only for serials. This patch makes it show for all the relevant position 7 on the leader values. I left out a and b as recommended by expert librarians on my team, but I can revert that if required. The current implementation adds a new CSS class for each case, so libraries willing to keep the current behaviour or just have more granular control on the cases they want the link to display, just can. This patch makes sense with the follow-up one, which will display the link only if there are really related records. To test: 1. Open a non-serial record, notice there's no link to analytics 2. Apply this patch and reload => SUCCESS: There's an 'Analytics' link 3. Inspect the produced HTML => SUCCESS: A special class with analytic_* value has been added, and thus we now can control its display through CSS 4. Sign off :-D Sponsored-by: Orex Digital Signed-off-by: Hugo Agud <hagud@orex.es> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #108051|0 |1 is obsolete| | --- Comment #70 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 109269 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=109269&action=edit Bug 15851: (follow-up) Only display the analytics link when required (staff) This patch replicates the introduced behaviour, for the admin interface. To test, follow the test plan from the OPAC, but on the intranet. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #71 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Testing on a fresh ktd: * Turn on EasyAnalyticalRecords * /cgi-bin/koha/catalogue/detail.pl?biblionumber=25 Edit > link to host use barcode from itemnumber 1 => https://snipboard.io/4TXWVU.jpg I don't see the link What am I missing? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|5959 |26131 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5959 [Bug 5959] Add search link for analytics to serial records https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26131 [Bug 26131] console errors when attempting to open SCO related system preferences -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #109268|0 |1 is obsolete| | --- Comment #74 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 109460 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=109460&action=edit Bug 15851: Only display the analytics link when required This patch makes opac-detail.pl query for analytics the same way it would do with the generated link (i.e. based on UseControlNumber) and passes a flag to the XSLT so it displays (or not) the 'Analytics' link. To test: 1. Apply the first patch 2. Have a known record without analytics 3. Open the record in the OPAC => FAIL: It shows the 'Analytics' link 4. Have a record known to have analytics and open in OPAC, on a separate tab => SUCCESS: It shows the 'Analytics' link 5. Apply this patch and restart_all 6. Reload the tabs => SUCCESS: It shows the link where it has to, and hides it where it shouldn't be displayed 7. Sign off :-D Sponsored-by: Orex Digital Signed-off-by: Hugo Agud <hagud@orex.es> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #76 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 109462 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=109462&action=edit Bug 15851: (QA follow-up) Fix booleans to uppercase to make this work for Elasticsearch and UseControlNumber Same test plan as before, but with UseControlNumber = Use and Elasticsearch. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 --- Comment #77 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Pushed to master for 20.11, thanks to everybody involved! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |release-notes-needed -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|"Analytics: Show analytics" |Only display "Analytics: |showing regardless of |Show analytics" when |whether they have analytics |records have linked | |analytics -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|release-notes-needed | Text to go in the| |This development changes release notes| |how the _Show analytics_ | |link is displayed in both | |OPAC and staff interface. | | | |The main changes are: | |* It | |is only displayed if it | |would actually have results | |(right now it always shows, | |and the link can point to | |empty results) | |* It is no | |longer constrained to | |serials: _collections_, | |_subunits_, _integrating | |resources_, _monographs_ | |and _serials_, all will | |display the link. | | | |New CSS | |classes are added for each | |material type: | | | |* | |_analytic_collection_ | |* | |_analytic_subunit_ | |* | |_analytic_ires_ | |* | |_analytic_monograph_ | |* | |_analytic_serial_ | | | |This | |way, libraries that wish to | |only display those links | |for serials (for example), | |can hide them for other | |resources: | | | |``` | |.analytic_collection | |.analytic_subunit | |.analytic_ires | |.analytic_monograph { | |display: none }; | |``` | | | |This | |CSS classes can be used in | |both OPAC and admin | |interface. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=27575 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to master |RESOLVED Resolution|--- |FIXED CC| |fridolin.somers@biblibre.co | |m -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=21469 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Irene <i.tortorella@arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |i.tortorella@arts.ac.uk -- You are receiving this mail because: You are watching all bug changes.