@amw290 The Vienna Primo catalog works fine for me. Run through https://www.zotero.org/support/troubleshooting_translator_issues

In case it helps for analyzing: univie is using ezproxy.

@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.

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?

@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

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.

@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.

@zuphilip: You are absolutely right! - The PNXs (sections of PNX record) are identical but the EL links are rewritten and proxied:

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?

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.

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.

@dstillman My colleague is back and just changed the EZproxy config - the namespace URIs are not proxied anymore. I just checked the PNX:
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!