|
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. *** Created attachment 191349 [details] [review] Bug 15349: Accept email addresses with display name in system preferences To test: 1. Before applying this patch, navigate to system preferences 2. Search for preference KohaAdminEmailAddress 3. Enter anything that is not in the format of valid "email@address.com" 4. Observe error "Please enter a valid email address." 5. Apply patch 6. Enter anything that is not in the format of valid "email@address.com" and not in the format of "display name <email@address.com>" 7. Observe error "Please enter a valid email address (display name allowed)." 8. Enter email@address.com 9. Save all Administration preferences 10. Observe no errors 11. Enter Display Name <email@address.com> 12. Save all Administration preferences 13. Observe no errors We would love to see this go forward so I've proposed a patch. It currently only handles KohaAdminEmailAddress but should be easily extensible to other email fields. (In reply to Lari Taskula from comment #16) > We would love to see this go forward so I've proposed a patch. It currently > only handles KohaAdminEmailAddress but should be easily extensible to other > email fields. If we want it to be extended to branch emails and/or other fields in the staff client, then staff-global.js is probably the correct location for the new validation method. Created attachment 191366 [details] [review] Bug 15349: Accept email addresses with display name in system preferences To test: 1. Before applying this patch, navigate to system preferences 2. Search for preference KohaAdminEmailAddress 3. Enter anything that is not in the format of valid "email@address.com" 4. Observe error "Please enter a valid email address." 5. Apply patch 6. Enter anything that is not in the format of valid "email@address.com" and not in the format of "display name <email@address.com>" 7. Observe error "Please enter a valid email address (display name allowed)." 8. Enter email@address.com 9. Save all Administration preferences 10. Observe no errors 11. Enter Display Name <email@address.com> 12. Save all Administration preferences 13. Observe no errors I understand email address validation is not a trivial task so instead of introducing a new regular expression, the proposed patch is now using the same regex as jQuery validation plugin https://jqueryvalidation.org/email-method/ https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address So the validating regex is exactly the same as before except that it now allows the display name as well. Created attachment 191373 [details] [review] Bug 15349: Accept email addresses with display name in system preferences To test: 1. Before applying this patch, navigate to system preferences 2. Search for preference KohaAdminEmailAddress 3. Enter anything that is not in the format of valid "email@address.com" 4. Observe error "Please enter a valid email address." 5. Apply patch 6. Enter anything that is not in the format of valid "email@address.com" and not in the format of "display name <email@address.com>" 7. Observe error "Please enter a valid email address (display name allowed)." 8. Enter email@address.com 9. Save all Administration preferences 10. Observe no errors 11. Enter Display Name <email@address.com> 12. Save all Administration preferences 13. Observe no errors Signed-off-by: Ayoub Glizi-Vicioso <ayoub.glizi-vicioso@inLibro.com> |