Sometimes you will want to use something like Library X <library@...> in your email settings in Koha. This works for example nicely for the branch email address and the emails are sent out correctly. The problem is, that you can't save the value in the staff interface, as the checks for valied entries in the form reports it as an invalid email address. It would be nice if the check on the form was more flexible or could be overwritten.
Koha is inconsistent about where an email formatted that way is acceptable. I think before we could solve this we would need to either enable it everywhere or at least identify where it is and isn't possible. See bug 9815 - "<<branches.branchemail>> can't contain "The Library" <library@example.com>"
*** Bug 24233 has been marked as a duplicate of this bug. ***
*** Bug 28706 has been marked as a duplicate of this bug. ***
This one is really interesting. At a glance at the documentation and source code, Email::Valid might be able to support that...
Could we either: 1 - add an 'Email display name' field for branches 2 - add a syspref that adds the branch name to the from field when sending emails?
(In reply to Nick Clemens from comment #5) > Could we either: > 1 - add an 'Email display name' field for branches > 2 - add a syspref that adds the branch name to the from field when sending > emails? Hm why not change the validation and allow adding them directly? We have disabled the validation on the branch email field and added things like "Library xy <email@email.com>" and it does actually work well in production for a long time. At least in 18.11, but also in my tests with 20.11. At least in our setup where we are also using Reply-to and return-path.
In the meantime you can step around email validation on branches.tt by adding the following to your IntranetUserJS sys pref: //turn off email validation for branches.tt if ( $('#admin_branches').length && window.location.href.indexOf("op=add_form") > -1 ) { $('#branchemail').removeClass('email'); }
Bug 28870 solves the backend email validation issues, and accepts formatted addresses. The remaining problems are related to the jquery library we use: https://jqueryvalidation.org/email-method/ one path for solving it, could be trying to extract the regex from Email::Address and override the one in the jQuery library with it. Another option could be to add a route for email validation so an async check is done.
(In reply to Tomás Cohen Arazi from comment #8) > Bug 28870 solves the backend email validation issues, and accepts formatted > addresses. The remaining problems are related to the jquery library we use: > > https://jqueryvalidation.org/email-method/ > > one path for solving it, could be trying to extract the regex from > Email::Address and override the one in the jQuery library with it. Another > option could be to add a route for email validation so an async check is > done. I missed this comment, so it looks like they should not cause issues and it's only a matter of the validation now, right?
(In reply to Katrin Fischer from comment #9) > (In reply to Tomás Cohen Arazi from comment #8) > > Bug 28870 solves the backend email validation issues, and accepts formatted > > addresses. The remaining problems are related to the jquery library we use: > > > > https://jqueryvalidation.org/email-method/ > > > > one path for solving it, could be trying to extract the regex from > > Email::Address and override the one in the jQuery library with it. Another > > option could be to add a route for email validation so an async check is > > done. > > I missed this comment, so it looks like they should not cause issues and > it's only a matter of the validation now, right? You mean validating in the form. Right? I'm that case, that's what I think
*** Bug 29655 has been marked as a duplicate of this bug. ***
I was just thinking about the native input type "email" but it looks like it doesn't accept "Library X <library@...>" either. Would we really want to support "Library X <library@...>" in all contexts or just system preferences and branch emails? If we supported it for users, it could stop SSO from working.
We only had the request for library email addresses so far, I think that's the main use case.
*** Bug 31205 has been marked as a duplicate of this bug. ***