Thank you for the quick reply. It seems it doesn't work when I've employed the university's proxy access (for all online sources). So I'll check with them?
@dstillman can we split this into a separate thread starting with amw290 above? Vienna is using the new Primo instance, so the rest of the thread is irrelevant to this issue.
@gduffner -- are you seeing the same? The translator for the new primo catalogs is very simple and I'm a bit surprised it fails under any circumstances.
Ideally I'd need someone with a bit of experience either in web development and/or with that catalog instance to help troubleshoot.
@adamsmith I can't reproduce the proxy problems as I'm from a different Viennese university and don't have access to their proxy. But we are in the same consortium so I know about the technical background and could contact their systems people if needed.
The thread is already four months old, but just now we got our first user feedback (luckily more feedback than complaint) concerning problems with Primo NUI and Zotero Connector. I work for Vienna University Library. For staff and students of our university we use a proxy (EZproxy) - when a user belonging to these user groups logs into Primo he/she automatically gets the proxy. Using Zotero Connector and Primo NUI (URL: https://usearch.univie.ac.at/) works fine, but only without proxy. After logging into Primo and getting the proxy (URL: https://usearch.uaccess.univie.ac.at/) the Zotero icons in results list (folder icon) and full display (book icon) remain the same and active but adding records from results list does not work anymore and adding records from full display leads to adding web pages in Zotero. The error message: "Ein Fehler ist aufgetreten beim Speichern mit Primo 2018. Es wird versucht stattdessen Save as Webpage zu nutzen." - I use Firefox (68.0.1) and Zotero Connector (5.0.57) on a Windows 7 computer. Today I created a debug ID: D1086808763. What can I do to help our users who work with Zotero Connector? Any chance to get this fixed via preferences?
One more technical detail: The user who sent us feedback on saving problems with Zotero Connector uses same version of Zotero, Zotero Connector and Firefox (see comment above) and works on Ubuntu 18.04 LTS. He tried to configure the proxy in Zotero Connector Preferences/Proxy settings - without success: %h.uaccess.univie.ac.at/%p
@dstillman could you check on the exact calls in the debug? @pegra -- how do other proxied resources look? E.g. for a JSTOR article, how does that look proxied? What I'm guessing might not work correctly is the fact that the typical proxy pattern (e.g. as you your user has it configured) applied to https://usearch.univie.ac.at/) would give you https://usearch.univie.ac.at.uaccess.univie.ac.at/
@adamsmith: Thanks a lot for your reply and question. I also tested with configured proxies in the respective Preferences tab and what you describe is what happens.
Here the JSTOR article example:
Article: Hofmann, W. (2010). Goya und Wien. Artibus Et Historiae, 31(62), 233-243. Available at Vienna University Library via: JSTOR Arts and Sciences III
Is that what you need to know for analyzing? Does that help? In Primo the URL changes from usearch.univie.ac.at to usearch.uaccess.univie.ac.at wheres on the JSTOR platform the proxy gets added.
The error indicates that the problem might be your PNX data when you are loged in. However, this is not a general problem, as I just checked our Primo where I can also save entries to Zotero when loged in.
Can you please log into Primo, search for a title and then look at the PNX data? Either add simply "&showPNX=true" to your url or look for the url in the source code of the website, where it has the class "urlToXmlPnx".
@zuphilip: Thanks for your comment. There is no difference between PNX when logged in and PNX without EZproxy. Especially display/type has to be correct as it is used in Primo in many ways (icon display in results list, facets, resource type etc.).
Example (logged in, using EZproxy):
(display) (type)book(/type) (title)Corpus musicae popularis Austriacae : Gesamtausgabe der Volksmusik in Österreich in repräsentativer Auswahl : 20 : Volksmusik in Wien. Weana Tanz (Wiener Tänze), Teil 1 : Geschichte und Typologie / hrsg. vom Wiener Volksliedwerk. Walter Deutsch und Ernst Weber(/title) [...] (facets) [...] (prefilter)books(/prefilter) (rsrctype)books(/rsrctype) [...]
(I changed angle backet to round brackets as I do not know how to mark code so that it is displayed as code.)
These are the types we use in our Primo template in display/type:
article audio book collection database image journal loseblatt map mbw other schriftenreihe score video
=> Anything more I can check?! As the PNX data is the same I suppose the problem must be connected to the change in the URL when logged in.
Okay, that is the problem. It is IMO strange that these namespace links are proxied as well. We can try to handle that case in the translator code by either unproxy all the links in the PNX file or adapt the namespace definitions in ns. However, I would like to solve that more general than just for your university. @dstillman Is there any function for dealing with proxified calls which can be used in translator coding?
Those namespace URIs certainly shouldn't be proxied, so if EZproxy is doing that, either this should be reported to them or some configuration change is necessary. (Given that other EZproxy installations apparently aren't doing this, it may be the latter.)
ZU.urlToProper() should be able to unproxy those, but that doesn't seem particularly appropriate — XML namespace URIs should never be proxied, so this isn't really something the translator should have to worry about.
@dstillman@zuphilip If to your mind it is a problem caused by our EZproxy configuration we will try to solve it on our side. Other EZproxy installations that don´t proxy namespaces seem to be a good reason to believe that... Some colleagues I need for discussing the issue are on vacation right now. Anyway, thanks a lot for helping me to identify what causes the troubles when importing records to Zotero.
Yeah, just to clarify, those aren't actually links to webpages — they're simply identifiers used in the XML to identify the content as being from a particular vocabulary. So proxying them is completely wrong, and it's making the data in the XML meaningless. I have no idea where in an EZproxy configuration that sort of thing would be controlled, though.
However the Zotero connector still does not work when I am logged in and the URL is proxied...
I just produced another Debug ID: D589971192. In the errors I can still find the JavaScript error "Could not locate item type..."
I will be on vacation the next two weeks but my colleague Christian will follow the forum thread. So if you have any findings he will answer. Thanks in advance!
Upgrade Storage
https://usearch.uaccess.univie.ac.at/primo-explore/fulldisplay? ETC...
Ideally I'd need someone with a bit of experience either in web development and/or with that catalog instance to help troubleshoot.
@pegra -- how do other proxied resources look? E.g. for a JSTOR article, how does that look proxied? What I'm guessing might not work correctly is the fact that the typical proxy pattern (e.g. as you your user has it configured) applied to https://usearch.univie.ac.at/) would give you https://usearch.univie.ac.at.uaccess.univie.ac.at/
Here the JSTOR article example:
Article:
Hofmann, W. (2010). Goya und Wien. Artibus Et Historiae, 31(62), 233-243.
Available at Vienna University Library via: JSTOR Arts and Sciences III
Link full display Primo when logged in:
https://usearch.uaccess.univie.ac.at/primo-explore/fulldisplay?docid=TN_jstor_archive_325822482&context=PC&vid=UWI&lang=de_DE&search_scope=UWI_UBBestand&adaptor=primo_central_multiple_fe&tab=default_tab&query=any,contains,goya wien hofmann werner&offset=0
Proxied article link in JSTOR:
https://www-jstor-org.uaccess.univie.ac.at/stable/25822482?seq=1#metadata_info_tab_contents
Is that what you need to know for analyzing? Does that help?
In Primo the URL changes from usearch.univie.ac.at to usearch.uaccess.univie.ac.at wheres on the JSTOR platform the proxy gets added.
Can you please log into Primo, search for a title and then look at the PNX data? Either add simply "&showPNX=true" to your url or look for the url in the source code of the website, where it has the class "urlToXmlPnx".
What is the type given in the PNX data? Can you see why the lines https://github.com/zotero/translators/blob/master/Primo Normalized XML.js#L55-L58 in the Zotero translator fail for your PNX data?
Example (logged in, using EZproxy):
(display)
(type)book(/type)
(title)Corpus musicae popularis Austriacae : Gesamtausgabe der Volksmusik in Österreich in repräsentativer Auswahl : 20 : Volksmusik in Wien. Weana Tanz (Wiener Tänze), Teil 1 : Geschichte und Typologie / hrsg. vom Wiener Volksliedwerk. Walter Deutsch und Ernst Weber(/title)
[...]
(facets)
[...]
(prefilter)books(/prefilter)
(rsrctype)books(/rsrctype)
[...]
(I changed angle backet to round brackets as I do not know how to mark code so that it is displayed as code.)
These are the types we use in our Primo template in display/type:
article
audio
book
collection
database
image
journal
loseblatt
map
mbw
other
schriftenreihe
score
video
=> Anything more I can check?! As the PNX data is the same I suppose the problem must be connected to the change in the URL when logged in.
Can you copy and paste the complete XML somewhere online, e.g. at https://pastebin.com/ ?
XML when using EZproxy:
(?xml version="1.0" encoding="UTF-8"?)
(record xmlns="http://www-exlibrisgroup-com.uaccess.univie.ac.at/xsd/primo/primo_nm_bib" xmlns:sear="http://www-exlibrisgroup-com.uaccess.univie.ac.at/xsd/jaguar/search")
XML without EZproxy (Primo translator / import works in this case):
(?xml version="1.0" encoding="UTF-8"?)
(record xmlns="http://www.exlibrisgroup.com/xsd/primo/primo_nm_bib" xmlns:sear="http://www.exlibrisgroup.com/xsd/jaguar/search")
[Again round brackets, sorry for that!]
Any idea how to solve this?
ZU.urlToProper() should be able to unproxy those, but that doesn't seem particularly appropriate — XML namespace URIs should never be proxied, so this isn't really something the translator should have to worry about.
record xmlns="http://www.exlibrisgroup.com/xsd/primo/primo_nm_bib" xmlns:sear="http://www.exlibrisgroup.com/xsd/jaguar/search"
However the Zotero connector still does not work when I am logged in and the URL is proxied...
I just produced another Debug ID: D589971192.
In the errors I can still find the JavaScript error "Could not locate item type..."
I will be on vacation the next two weeks but my colleague Christian will follow the forum thread. So if you have any findings he will answer.
Thanks in advance!
var itemType = ZU.xpathText(doc, '//p:display/p:type', ns) || ZU.xpathText(doc, '//p:facets/p:rsrctype', ns) || ZU.xpathText(doc, '//p:search/p:rsrctype', ns);(
pin this case ishttp://www.exlibrisgroup.com/xsd/primo/primo_nm_bib, so unprefixed in your case.)Could you either post the PNX somewhere (e.g., pastebin) or check to see why those XPaths aren't matching?