103172 - Remove the password field in the mapi authentication dialog

Status: VERIFIED FIXED

(MailNews Core :: Simple MAPI, defect, P1)

Description

[Scott MacGregor]

Currently when I invoke a mapi transaction, I get a nice dialog which comes up
asking me for my user name and password. But sending doesn't require a password.
I find myself very confused as to what I should type in the password field. I
think Esther also got confused about this field. 

Looks like entering incorrect passwords, empty passwords, etc. still cause the
send to go through without a problem. 

Since we don't use the password field for sending, and our simple mapi support
is only for sending right now, can we remove the password field for this
release? I think that would make things less confusing. And it would have the
side effect of fixing bugs like 102644

Comment 1

[Scott MacGregor]

nominating for branch consideration.

Comment 2

[Tiantian Kong]

Reassign to Rajiv.

Comment 3

[Tiantian Kong]

Copied sol's comments from the security bug to here.

------ Additional Comments From [e-mail] 2001-10-05 12:51 -------

I'm using commercial branch 2001-10-05-05, and am finding the experience of
sending a document from PowerPoint via the SMAPI support in our email client a
bit confusing.

I can't tell from the discussion above whether this behavior is being addressed,
or whether it should be the subject of another bug.

The confusion - when viewing a presentation in PowerPoint, I select from the
main menu "File | Send To | Mail Recipient ..."

    Our email client: When our mail client is the default MAPI client, I am next
presented with a dialog that asks "Please enter your username and password." I
find this *very* confusing. What username am I being asked for? I have 5 email
accounts - which username is being asked for? Note that this is not a silent,
programmatic initiation of SMAPI, but rather the result of an explicit request
from me. I guessed correctly, and was then taken to the Mail compose window
where the PowerPoint doc was correctly attached. I hit send - everything worked
as expected.

     Outlook Express: When OE is the default MAPI client, after pressing "File |
Send To | Mail Recipient ..." I am next presented with the email compose window,
to which the PowerPoint doc has been attached. After I hit "Send", I am then
asked for my password - apparently as a security precaution. The fact that the
password dialog comes up *after* I press send seems much more intuitive to me -
I know that the password is associated with the email account I am sending the
message from.

Comment 4

[Rajiv Dayal]

Please find below the patch that stops displaying the Logon dialog. The change
will display the Profile Manager if Mozilla is not already running and based on
the profile selected the Compose Window will display a list of all valid mail
accounts in the 'From' combo-box of the compose window (the default behaviour
for compose window). This is also the behaviour as seen on Outlook although it
is not as per the MAPI specs. But doing this alike Outlook will eliminate
several of our user issues (bug #s: 102611, 102772, 102795, 102642).

This will however require that the MAPI apps making call to "Blind Send" (send
with no UI) will either call MAPILogon with valid username and password as its
parameters or the customer/user will use a mail account with no smtp password to
do blind send.

Comment 5

[Rajiv Dayal]

Attachment: patch to remove the Logon dialog

Comment 6

[Rajiv Dayal]

Hi JF and Scott, 
Can u please r and sr the attached patch.
thanks, - rajiv.

Comment 7

[Jaime Rodriguez, Jr.]

pls check this into the branch - PDT+, assuming we get the reviews.

Comment 8

[Scott MacGregor]

Comment on attachment 52605 [details] [diff] [review]
patch to remove the Logon dialog

sr=mscott

(I also just tried it out and I'm not getting the dialog anymore).

Comment 9

[(not reading, please use [e-mail] instead)]

Comment on attachment 52605 [details] [diff] [review]
patch to remove the Logon dialog

r=sspitzer

Comment 10

[Scott MacGregor]

hey Rajiv, I just checked this in for ya on the branch since you don't have cvs
write access yet. 

QA: you can start testing that the dialog is no longer present in tomorrow's builds.

Comment 11

[Rajiv Dayal]

thanks Scott. I will definitly test the 094 branch for this tomorrow. Trix can u
also test this.

Comment 12

[Jean-Francois Ducarroz]

sorry, I wasn't quick enough on this one.

Comment 13

[Scott MacGregor]

*** Bug 103871 has been marked as a duplicate of this bug. ***

Comment 14

[Scott MacGregor]

*** Bug 103861 has been marked as a duplicate of this bug. ***

Comment 15

[Scott MacGregor]

*** Bug 102795 has been marked as a duplicate of this bug. ***

Comment 16

[Trix Supremo]

verified on 2001-10-12-05-0.9.4