https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15349 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA CC| |pedro.amorim@openfifth.co.u | |k --- Comment #23 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Hi all, KohaAdminEmailAddress is read in over 40 places, and some of them assume it holds a bare email address. Allowing "Name <address>" in the preference changes that for all of them, now and in the future (Owen raised this in comment 1). OAI-PMH is one existing example: Koha/OAI/Server/Identify.pm publishes the preference as the repository's adminEmail. The OAI-PMH 2.0 schema (https://www.openarchives.org/OAI/2.0/OAI-PMH.xsd) restricts adminEmail to the pattern \S+@(\S+\.)+\S+, so "My Library <library@example.org>" makes Koha's Identify response schema-invalid. Fixing that one consumer wouldn't stop the next one from hitting the same problem. To see it: 1) Go to http://localhost:8081/cgi-bin/koha/admin/preferences.pl?op=search&searchfield=OAI-PMH, set 'OAI-PMH' to 'Enable' and save. 2) With the patch applied, go to http://localhost:8081/cgi-bin/koha/admin/preferences.pl?op=search&searchfield=KohaAdminEmailAddress, set 'KohaAdminEmailAddress' to 'My Library <library@example.org>' and save. 3) Download the OAI-PMH schema, then check Koha's Identify response against it: curl -s -o /tmp/oai.xsd https://www.openarchives.org/OAI/2.0/OAI-PMH.xsd curl -s 'http://localhost:8080/cgi-bin/koha/oai.pl?verb=Identify' | xmllint --noout --schema /tmp/oai.xsd - => FAIL: xmllint reports that adminEmail doesn't match the pattern, and ends with "- fails to validate". 4) Set 'KohaAdminEmailAddress' back to 'library@example.org', save, and run the second command from step 3 again (the schema is already downloaded): curl -s 'http://localhost:8080/cgi-bin/koha/oai.pl?verb=Identify' | xmllint --noout --schema /tmp/oai.xsd - => PASS: xmllint prints "- validates". So the failure in step 3 was caused by the display name. I'd prefer the route Nick suggested in comment 5: - Keep KohaAdminEmailAddress as a bare email address, with the validation unchanged - Add a new KohaAdminEmailName preference alongside it (unfortunately, YASP) - Combine the two only where a From header is built, ideally in one central helper, so every existing consumer keeps getting a plain address and new ones can opt in to the name This would still meet the need behind this bug (showing a library name as the sender) without loosening the email check. It also fails safe: if a sender does not have the name defined, that email just goes out from the bare address, as it does today. -- You are receiving this mail because: You are watching all bug changes.