Summary: | Problem with email pattern check on forms | ||
---|---|---|---|
Product: | Koha | Reporter: | Katrin Fischer <katrin.fischer> |
Component: | Templates | Assignee: | Owen Leonard <oleonard> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | dcook, kyle, lucas, nick, resetka.bedi, tgoatley, tomascohen |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9815 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28870 |
||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: |
Description
Katrin Fischer
2015-12-10 10:15:57 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>" *** 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. *** |