Closed Bug 756314 Opened 12 years ago Closed 12 years ago

Full email addresses entered in the CC list are ignored if the "Confirm Match" page is displayed

Categories

(Bugzilla :: Creating/Changing Bugs, defect)

4.0.6
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 4.0

People

(Reporter: Dolske, Assigned: glob)

References

Details

(Keywords: dataloss, regression)

Attachments

(1 file, 1 obsolete file)

I just filed bug 756216. It didn't contain the CC list I initially specified.

The CC list I set while entering the bug was "kev@mozilla.com, benjamin@smedbergs.us, :rs, khuey@kylehuey.com, akeybl@mozilla.com, ".

Upon clicking Submit, bugzilla informed me that ":rs" was ambiguous, and let me select the right user from a <select>.

I was a bit surprised to find that it added _only_ the dis-ambiguated user (rob strong) to the CC list, and silently dropped the other users I specified. (The others entries in my list above were ok, I pasted it again without :rs and they were added in the additional submission.)
I cannot reproduce upstream.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Version: unspecified → 4.0.6
i can reproduce this on landfill (4.0, 4.2 and tip).
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
So the problem happens with full email addresses entered in the CC list when another incomplete email address triggers the "Confirm Match" page. All incomplete email addresses are correctly listed, though, so this only affects full email addresses. Nobody reported this problem before probably because the auto-completion feature makes this less a problem.
Status: REOPENED → NEW
Flags: blocking4.2.2+
Keywords: dataloss, regression
OS: Mac OS X → All
Hardware: x86 → All
Summary: CC list dropped when filing bug with an ambiguous CC entry → Full email addresses entered in the CC list are ignored if the "Confirm Match" page is displayed
Target Milestone: --- → Bugzilla 4.2
Bugzilla 3.6.9 is not affected, so we regressed this in 4.0. Considering this bug as dataloss, it's a blocker for 4.0.7.
Flags: blocking4.0.7+
Target Milestone: Bugzilla 4.2 → Bugzilla 4.0
Regression due to bug 634243.
Depends on: 634243
Assignee: create-and-change → glob
Attached patch patch v1 (obsolete) — Splinter Review
as far as i can tell, the right thing to do here is to only exclude the hidden field if it's empty.
Attachment #625925 - Flags: review?(LpSolit)
Comment on attachment 625925 [details] [diff] [review]
patch v1

This change is in the right direction, but this is not enough. You also have to revert the first change from attachment 512478 [details] [diff] [review] else a partial login name which matches exactly one login name will be inserted twice, which triggers an error for single-select fields.

Steps to reproduce:

- Enter "LpSolit" (or any partial name which matches only one account) in the assignee field.
- Enter a login name which matches several accounts in the CC list.
- Click commit, and select one account for the CC list in the confirmation page.

=> you get an error that LpSolit@...,LpSolit@... doesn't exist.
Attachment #625925 - Flags: review?(LpSolit) → review-
Attached patch patch v2Splinter Review
thanks for the clear steps to reproduce LpSolit!
this should address that issue.
Attachment #625925 - Attachment is obsolete: true
Attachment #627717 - Flags: review?(LpSolit)
Comment on attachment 627717 [details] [diff] [review]
patch v2

r=LpSolit
Attachment #627717 - Flags: review?(LpSolit) → review+
Status: NEW → ASSIGNED
Flags: approval4.2+
Flags: approval4.0+
Flags: approval+
Committing to: bzr+ssh://bjones%40mozilla.com@bzr.mozilla.org/bugzilla/4.0/
modified template/en/default/global/confirm-user-match.html.tmpl
Committed revision 7709.

Committing to: bzr+ssh://bjones%40mozilla.com@bzr.mozilla.org/bugzilla/4.2/
modified template/en/default/global/confirm-user-match.html.tmpl
Committed revision 8090.

Committing to: bzr+ssh://bjones%40mozilla.com@bzr.mozilla.org/bugzilla/trunk/
modified template/en/default/global/confirm-user-match.html.tmpl
Committed revision 8246.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.