You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Si Chen <si...@opensourcestrategies.com> on 2006/11/03 01:45:27 UTC
email-related issues
Hi -
Just found a couple of email-related issues which I think should be
fixed like this:
1. sendMail returns error when there's a problem sending the email.
The problem is that this rolls back a whole transaction, including
one that is sending emails to everybody on a contact list. I
modified it to return failure instead, and it seems to be working
better. Is it ok if I change it to returnFailure, or would it cause
any problems?
2. UtilValidate.isEmail has code which checks for the "." in an
email commented out in 2001. Do we still want this commented out?
Is it ok if I made two forms of this, one with an optional parameter
to require the dot? That would make our email program much more robust.
Separately I think I need to do some stuff to clean up the way
contact list emails, comm events, etc. work, so if I could get these
out of the way it'd really help.
Best Regards,
Si
sichen@opensourcestrategies.com
Re: email-related issues
Posted by BJ Freeman <bj...@free-man.net>.
Does returnfailure return a code.
that way if get a code that it is a bad address, then mark the email as
inactive.
Si Chen sent the following on 11/2/2006 4:45 PM:
> Hi -
>
> Just found a couple of email-related issues which I think should be
> fixed like this:
>
> 1. sendMail returns error when there's a problem sending the email.
> The problem is that this rolls back a whole transaction, including one
> that is sending emails to everybody on a contact list. I modified it to
> return failure instead, and it seems to be working better. Is it ok if
> I change it to returnFailure, or would it cause any problems?
>
> 2. UtilValidate.isEmail has code which checks for the "." in an email
> commented out in 2001. Do we still want this commented out? Is it ok
> if I made two forms of this, one with an optional parameter to require
> the dot? That would make our email program much more robust.
>
> Separately I think I need to do some stuff to clean up the way contact
> list emails, comm events, etc. work, so if I could get these out of the
> way it'd really help.
>
> Best Regards,
>
> Si
> sichen@opensourcestrategies.com
>
>
>
>
Re: email-related issues
Posted by John Martin <pb...@gmail.com>.
That was my only thought to why it was setup that way. My feeling is that
the form validation routine should be the one determining if a field is
required and error when empty and if not empty do the test using the
validation function.
But I guess that is the way it is so I won't fight it.
Thanks for the reply!
John
On 1/30/07, David E. Jones <jo...@hotwaxmedia.com> wrote:
>
>
> On Jan 30, 2007, at 8:18 AM, John Martin wrote:
>
> > I really don't understand why ('' == valid email). Could you
> > explain why it
> > is intentional that that sort of validation is intentional?
>
> It isn't a valid email, but think about it from a perspective of
> using that set of methods, not just the one.
>
> How else would we have 2 different messages, one for being empty and
> another for not being a validly formatted email address?
>
> -David
>
>
>
>
Re: email-related issues
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Jan 30, 2007, at 8:18 AM, John Martin wrote:
> I really don't understand why ('' == valid email). Could you
> explain why it
> is intentional that that sort of validation is intentional?
It isn't a valid email, but think about it from a perspective of
using that set of methods, not just the one.
How else would we have 2 different messages, one for being empty and
another for not being a validly formatted email address?
-David
Re: email-related issues
Posted by John Martin <pb...@gmail.com>.
Hi Dave -
I really don't understand why ('' == valid email). Could you explain why it
is intentional that that sort of validation is intentional?
I've changed the code over to used the apache commons validator class which
does a much more extensive testing. In doing so, I preserved the requireDot
functionality. I've opened up Jira issue 668 and will include the patch
today. I'll leave the empty condition in place.
https://issues.apache.org/jira/browse/OFBIZ-668
Thanks,
John
On 1/29/07, David E. Jones <jo...@hotwaxmedia.com> wrote:
>
>
> On Jan 29, 2007, at 10:42 AM, John Martin wrote:
>
> > On more careful examination of the isEmail function, the first test
> > is to
> > see if the string is empty and if so it returns true. I can't
> > imagine why
> > that condition should return true, null or an empty string do not
> > constitute
> > an email address. My only thought for a reason would be if the
> > field being
> > tested is an optional field. In that case it shouldn't be the
> > responsibility of the function but the form handler.
> >
> > The function should return an absolute true/false that the string
> > is an
> > email and not.
> >
> > Comments?
>
> You'll find this pattern throughout and it is VERY intentional. Only
> the not empty constraint requires a non-empty string, and that's the
> way it's supposed to be, otherwise you get weird and very confusing
> error messages.
>
> Committers please read: don't ever change this, it is VERY intentional!
>
> -David
>
>
>
>
Re: email-related issues
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Jan 29, 2007, at 10:42 AM, John Martin wrote:
> On more careful examination of the isEmail function, the first test
> is to
> see if the string is empty and if so it returns true. I can't
> imagine why
> that condition should return true, null or an empty string do not
> constitute
> an email address. My only thought for a reason would be if the
> field being
> tested is an optional field. In that case it shouldn't be the
> responsibility of the function but the form handler.
>
> The function should return an absolute true/false that the string
> is an
> email and not.
>
> Comments?
You'll find this pattern throughout and it is VERY intentional. Only
the not empty constraint requires a non-empty string, and that's the
way it's supposed to be, otherwise you get weird and very confusing
error messages.
Committers please read: don't ever change this, it is VERY intentional!
-David
Re: email-related issues
Posted by John Martin <pb...@gmail.com>.
On more careful examination of the isEmail function, the first test is to
see if the string is empty and if so it returns true. I can't imagine why
that condition should return true, null or an empty string do not constitute
an email address. My only thought for a reason would be if the field being
tested is an optional field. In that case it shouldn't be the
responsibility of the function but the form handler.
The function should return an absolute true/false that the string is an
email and not.
Comments?
Thanks,
John
Re: email-related issues
Posted by John Martin <pb...@gmail.com>.
I went to use the new isEmail(String email) method and it surpised me that
the default was to test without the dot. Being that the majority of use of
the isEmail function would be for testing emails originating outside the
company implementing ofBiz, that the test should include testing for the .
(dot).
What is the chance of changing the test to include the dot or am I going to
forced (grin) to use the isEmail(email, true)?
Thanks,
John
On 11/3/06, Si Chen <si...@opensourcestrategies.com> wrote:
>
> Yes, I think these are all good ideas:
>
> 1. Add a new email validation method: I was thinking of adding a
> boolean isEmail(String email, boolean requireDot) and then making the
> current isEmail(String email) just call isEmail(email, false). Would
> that work? Or should I just make a new method isEmailWithDot?
>
> 2. I think you're right also--we should have the
> sendContactListEmail to be a separate service which does not have its
> own transaction but uses separate transaction blocks.
>
> 3. One issue is how to mark some parties as having been sent an
> email, so that if the sendContactListEmail is broken, we can start
> from the middle? I was thinking about add an "In use" status code to
> "lock" the contact list party while an email is being sent to the
> list, but now I'm not sure if it's a good design or not, because you
> might want to send several emails at the same time. If not with an
> "in use" status code, then what? Does anybody have any ideas?
>
> 4. I'm thinking about adding a flag to the contact list to control
> whether contact list emails will be logged in each user, to
> distinguish between mass-marketing email lists which you probably
> don't want to log for fear of choking your database, versus directed
> emails such as product recalls, etc.
>
> On Nov 3, 2006, at 9:38 AM, David E Jones wrote:
>
> >
> > Maybe the best option would be to have 2 different email validation
> > methods in UtilValidate (don't want to add an argument, because
> > some stuff depends on taking a single String argument and returning
> > a boolean).
> >
> > Then the ContactList or something could have a indicator on it
> > specifying whether or not to require a dot after the @.
> >
> > -David
> >
> >
> > On Nov 3, 2006, at 4:51 AM, Yoav Shapira wrote:
> >
> >> Hi,
> >>
> >> On 11/3/06, David Welton <da...@gmail.com> wrote:
> >>> > There was some discussion a long long time ago about this and how
> >>> > some valid email addresses don't have a dot in them. I don't
> >>> know how
> >>> > that could be except perhaps on an internal network or something.
> >>>
> >>> davidw@localhost
> >>
> >> Yup, that's an example. The general issue is in RFC2821, section
> >> 2.3.10. Only the destination host should attempt to parse,
> >> verify, or
> >> manipulate the string after the @. Most of the time this would only
> >> be useful on an internal network where you create aliases and/or run
> >> your own mailing lists inside the network...
> >>
> >> Yoav
>
> Best Regards,
>
> Si
> sichen@opensourcestrategies.com
>
>
>
>
>
Re: email-related issues
Posted by Si Chen <si...@opensourcestrategies.com>.
Yes, I think these are all good ideas:
1. Add a new email validation method: I was thinking of adding a
boolean isEmail(String email, boolean requireDot) and then making the
current isEmail(String email) just call isEmail(email, false). Would
that work? Or should I just make a new method isEmailWithDot?
2. I think you're right also--we should have the
sendContactListEmail to be a separate service which does not have its
own transaction but uses separate transaction blocks.
3. One issue is how to mark some parties as having been sent an
email, so that if the sendContactListEmail is broken, we can start
from the middle? I was thinking about add an "In use" status code to
"lock" the contact list party while an email is being sent to the
list, but now I'm not sure if it's a good design or not, because you
might want to send several emails at the same time. If not with an
"in use" status code, then what? Does anybody have any ideas?
4. I'm thinking about adding a flag to the contact list to control
whether contact list emails will be logged in each user, to
distinguish between mass-marketing email lists which you probably
don't want to log for fear of choking your database, versus directed
emails such as product recalls, etc.
On Nov 3, 2006, at 9:38 AM, David E Jones wrote:
>
> Maybe the best option would be to have 2 different email validation
> methods in UtilValidate (don't want to add an argument, because
> some stuff depends on taking a single String argument and returning
> a boolean).
>
> Then the ContactList or something could have a indicator on it
> specifying whether or not to require a dot after the @.
>
> -David
>
>
> On Nov 3, 2006, at 4:51 AM, Yoav Shapira wrote:
>
>> Hi,
>>
>> On 11/3/06, David Welton <da...@gmail.com> wrote:
>>> > There was some discussion a long long time ago about this and how
>>> > some valid email addresses don't have a dot in them. I don't
>>> know how
>>> > that could be except perhaps on an internal network or something.
>>>
>>> davidw@localhost
>>
>> Yup, that's an example. The general issue is in RFC2821, section
>> 2.3.10. Only the destination host should attempt to parse,
>> verify, or
>> manipulate the string after the @. Most of the time this would only
>> be useful on an internal network where you create aliases and/or run
>> your own mailing lists inside the network...
>>
>> Yoav
Best Regards,
Si
sichen@opensourcestrategies.com
Re: email-related issues
Posted by David E Jones <jo...@undersunconsulting.com>.
Maybe the best option would be to have 2 different email validation
methods in UtilValidate (don't want to add an argument, because some
stuff depends on taking a single String argument and returning a
boolean).
Then the ContactList or something could have a indicator on it
specifying whether or not to require a dot after the @.
-David
On Nov 3, 2006, at 4:51 AM, Yoav Shapira wrote:
> Hi,
>
> On 11/3/06, David Welton <da...@gmail.com> wrote:
>> > There was some discussion a long long time ago about this and how
>> > some valid email addresses don't have a dot in them. I don't
>> know how
>> > that could be except perhaps on an internal network or something.
>>
>> davidw@localhost
>
> Yup, that's an example. The general issue is in RFC2821, section
> 2.3.10. Only the destination host should attempt to parse, verify, or
> manipulate the string after the @. Most of the time this would only
> be useful on an internal network where you create aliases and/or run
> your own mailing lists inside the network...
>
> Yoav
Re: email-related issues
Posted by Yoav Shapira <yo...@cargurus.com>.
Hi,
On 11/3/06, David Welton <da...@gmail.com> wrote:
> > There was some discussion a long long time ago about this and how
> > some valid email addresses don't have a dot in them. I don't know how
> > that could be except perhaps on an internal network or something.
>
> davidw@localhost
Yup, that's an example. The general issue is in RFC2821, section
2.3.10. Only the destination host should attempt to parse, verify, or
manipulate the string after the @. Most of the time this would only
be useful on an internal network where you create aliases and/or run
your own mailing lists inside the network...
Yoav
Re: email-related issues
Posted by David Welton <da...@gmail.com>.
> There was some discussion a long long time ago about this and how
> some valid email addresses don't have a dot in them. I don't know how
> that could be except perhaps on an internal network or something.
davidw@localhost
I sometimes use that for admin purposes to make sure it gets delivered
locally, but I can't see anyone using that to subscribe to a mailing
list with!
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
Re: email-related issues
Posted by David E Jones <jo...@undersunconsulting.com>.
On Nov 2, 2006, at 5:45 PM, Si Chen wrote:
> 1. sendMail returns error when there's a problem sending the
> email. The problem is that this rolls back a whole transaction,
> including one that is sending emails to everybody on a contact
> list. I modified it to return failure instead, and it seems to be
> working better. Is it ok if I change it to returnFailure, or would
> it cause any problems?
Another solution might be to split this into two services, one which
iterates over the contact list and another that sends out each mail
and updates the relates database records. The second service could
then have the require-new-transaction attribute set to true to
isolate those errors.
> 2. UtilValidate.isEmail has code which checks for the "." in an
> email commented out in 2001. Do we still want this commented out?
> Is it ok if I made two forms of this, one with an optional
> parameter to require the dot? That would make our email program
> much more robust.
There was some discussion a long long time ago about this and how
some valid email addresses don't have a dot in them. I don't know how
that could be except perhaps on an internal network or something. I'd
be fine with requiring a dot after the at sign, but it would be good
to get more feedback on this...
-David