Closed Bug 278414 Opened 20 years ago Closed 19 years ago

Cannot add 'cc' notification for Flags when using emailsuffixes

Categories

(Bugzilla :: Email Notifications, defect)

2.18
defect
Not set
major

Tracking

()

RESOLVED FIXED
Bugzilla 2.20

People

(Reporter: peterkayatwork, Assigned: LpSolit)

Details

Attachments

(2 files)

When using e-mail suffixes to append @host.com to e-mail addresses, one cannot
add an e-mail address (email@host.com) to the CC list for a Flag.

One gets the error:

<bright red>
The e-mail address you entered (email@host.com) didn't pass our syntax checking
for a legal email address. Enter only the username (the @host.com will be
appended). It must also not contain any of these special characters: \ ( ) & < >
, ; : " [ ], or any whitespace.
</bright red>

in editflagtypes.cgi, sub validateCCList, there's the line:
    foreach my $address (@addresses) { CheckEmailSyntax($address) }
CheckEmailSyntax checks against the parameter "emailregexp", which rejects
"email@host.com".

According to the documentation, we allow arbitrary CC lists for Flags, so
"email@host.com" should be valid.

If we allow arbitrary CC lists for Flags (why *do* we do that for flags but not
for normal CC lists?) then we will need a seperate way to validate the CC e-mail
addresses.
Marc, I reassign this bug to you. I will let you set the correct flags (if
necessary) and confirm this bug. CC'ing kiko who reviewed your patch in bug 277389.
Assignee: justdave → wurblzap
Depends on: 277389
Hardware: PC → All
Removing dependency because it doesn't exist :)

CheckEmailSyntax is named incorrectly. Its name should be CheckLoginSyntax. We
need a real CheckEmailSyntax which doesn't care about emailregexp (which should
be called loginregexp -- but this change is imo out of scope of this bug).
Status: UNCONFIRMED → NEW
No longer depends on: 277389
Ever confirmed: true
I'm not currently working on this... I'll take it if/when I do. Until then, it's
up to grabs.
Assignee: wurblzap → nobody
Flags: blocking2.22?
I'd like to see this fixed in 2.20 also, but I don't think it's severe enough to block the 2.22 release. We've lived with it OK in 2.20. People who use emailsuffix should only rarely have a need to CC somebody on a flag who isn't inside the company.
Severity: normal → major
Flags: blocking2.22? → blocking2.22-
The effect of this bug is that installations using emailsuffix can't use the CC feature of flags at all.
Flags: blocking2.22- → blocking2.22?
Oh, OK. In that case, it makes more sense to block 2.22 on it.
Flags: blocking2.22? → blocking2.22+
Assignee: nobody → LpSolit
Status: NEW → ASSIGNED
Attachment #205586 - Flags: review?(wurblzap)
Target Milestone: --- → Bugzilla 2.20
Attachment #205587 - Flags: review?(wurblzap)
Attachment #205586 - Flags: review?(wurblzap) → review+
Attachment #205587 - Flags: review?(wurblzap) → review+
Flags: approval?
Flags: approval2.20?
Frédéric filed bug 319953 to follow up.
Flags: approval?
Flags: approval2.20?
Flags: approval2.20+
Flags: approval+
tip:

Checking in editflagtypes.cgi;
/cvsroot/mozilla/webtools/bugzilla/editflagtypes.cgi,v  <--  editflagtypes.cgi
new revision: 1.30; previous revision: 1.29
done
Checking in template/en/default/global/user-error.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user-error.html.tmpl,v  <--  user-error.html.tmpl
new revision: 1.144; previous revision: 1.143
done


2.20:

Checking in editflagtypes.cgi;
/cvsroot/mozilla/webtools/bugzilla/editflagtypes.cgi,v  <--  editflagtypes.cgi
new revision: 1.19.4.1; previous revision: 1.19
done
Checking in template/en/default/global/user-error.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user-error.html.tmpl,v  <--  user-error.html.tmpl
new revision: 1.115.2.9; previous revision: 1.115.2.8
done
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: