Bug 15349 - Problem with email pattern check on forms
Summary: Problem with email pattern check on forms
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Templates (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Owen Leonard
QA Contact: Testopia
URL:
Keywords:
: 24233 28706 29655 31205 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-12-10 10:15 UTC by Katrin Fischer
Modified: 2022-07-25 22:12 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2015-12-10 10:15:57 UTC
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.
Comment 1 Owen Leonard 2016-02-17 19:09:31 UTC
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>"
Comment 2 Katrin Fischer 2021-07-13 14:27:16 UTC
*** Bug 24233 has been marked as a duplicate of this bug. ***
Comment 3 Katrin Fischer 2021-07-13 14:27:20 UTC
*** Bug 28706 has been marked as a duplicate of this bug. ***
Comment 4 David Cook 2021-07-13 23:46:32 UTC
This one is really interesting.

At a glance at the documentation and source code, Email::Valid might be able to support that...
Comment 5 Nick Clemens 2021-07-21 14:40:36 UTC
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?
Comment 6 Katrin Fischer 2021-07-21 15:03:23 UTC
(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.
Comment 7 Lucas Gass 2021-08-09 14:35:57 UTC
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');
}
Comment 8 Tomás Cohen Arazi 2021-08-24 12:35:40 UTC
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.
Comment 9 Katrin Fischer 2022-07-16 12:55:36 UTC
(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?
Comment 10 Tomás Cohen Arazi 2022-07-16 16:06:02 UTC
(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
Comment 11 Katrin Fischer 2022-07-17 12:04:55 UTC
*** Bug 29655 has been marked as a duplicate of this bug. ***
Comment 12 David Cook 2022-07-17 23:35:37 UTC
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.
Comment 13 Katrin Fischer 2022-07-18 09:49:56 UTC
We only had the request for library email addresses so far, I think that's the main use case.
Comment 14 Katrin Fischer 2022-07-25 22:12:06 UTC
*** Bug 31205 has been marked as a duplicate of this bug. ***