77652 - tell the user what directory we're going to delete when they confirm the account deletion

Status: NEW

(MailNews Core :: Account Manager, defect)

Description

we need to tell the user what directory we're going to delete when they confirm 
the accout deletion.

here's another discussion bug.

right now, when you delete a mailnews account we don't delete the files on disk.
part of the reason for this is now fixed, see bug 72709.

but before we turn on the code in nsMsgIncomingServer::RemoveAccount() that 
does the recursive delete of the folder pointed to by the account's localPath 
pref, we need to think it through.

here's what I'm worried about:

the user can easily change that pref in our account manager UI.  we don't tell 
them when they remove the account that we are going to remove the directory.

suggestions to get us started:

1)  add that info to the removal confirmation dialog:

change 
"Are you sure you want to remove this account?"

to

"Are you sure you want to remove this account?  any files in the directory 
<foobar> will be removed"

2) or, in the style of the account manager, when cofirming the remove we can 
have 3 choices:  delete and remove files, delete and don't remove files 
(Default), cancel the delete.

Comment 1

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

fixing

Comment 2

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

adding mpt again.

Comment 3

[[e-mail] (gone - use [e-mail] instead)]

Seth means "In the case of (2) Profile Manager" not Account Manager ;-).

Comment 4

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

right, profile manager.

thanks for the clarification.

Comment 5

[Navin Gupta]

When we are trying to remove the account we prompt the user for confirmation, 
we need to change this confirmation dialog to the one like the profile 
manager dialog. 

Comment 6

[jglick]

By directory being removed, do you mean the messages that are being stored 
locally for this account plus account settings for this account will be deleted? 
Some users might not understand the "directory" thing and what that means. So it 
might be better to explain this in different terms.  Robin can suggest wording 
but maybe something like: "This account and any local messages associated with 
it will be removed. Are you sure you want to delete this account?" 

Comment 7

[Navin Gupta]

We will be deleting the server directory that contains all the folders, for pop
 popstate.dat also, I don't know for imap and news what else we store in the 
server directory besides folders. 

Comment 8

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

mass re-assign.

Comment 9

[David :Bienvenu]

taking - working on the autoconfig cleanup stuff reminded me of this bug - I think we should fix this. One caveat is that we can't delete the storage if the account is deferred or deferred to (e.g., the global inbox). What do people think of this? The fix is relatively straightforward; we have to decide if we want to 1) or 2) from comment 0, and we need to handle the deferred account case (in which we shouldn't delete the local storage, or warn the user). Since most users are pop3 users (I maintain), and most probably use the global inbox, most users won't see a change.

Comment 10

[Magnus Melin [:mkmelin] (away, back Aug 4)]

I think I'd like option 2) better.

Comment 11

[Bryan Clark (DevTools PM) [:clarkbw]]

I don't understand why the user is concerned about the files in the directory.  Are we talking about the person's emails being deleted?  If so we should probably word the dialog toward messages instead of about files.

If they aren't using the Global Inbox it seems like they would really understand that all their emails are going to be removed from disk as the account will be removed from the folder pane.  Perhaps this is more of an issue if they have set 'remove messages from server' to be true.

If they are using the Global Inbox then I agree need to ask them about removing messages out of that as it's not completely obvious.

Here's what I'd suggest if this is the case:
( Cancel ) (( Delete and Keep Messages ))  ( Delete and Remove Messages )

Comment 12

[David :Bienvenu]

(In reply to comment #11)
> I don't understand why the user is concerned about the files in the directory. 

Right now the code that's there but not called deletes the whole server directory, and sub-directories. That deletes local mail, filters, .msf files, offline stores, popstate.dat, every file in the server directory. 

For the global inbox case, I think we want to remove the server-specific directory, which is where the filters are stored for that server, and popstate.dat, but not much else (the messages/folders are all in the local folders account dir)

For the non-global inbox case, I tend to agree with Bryan that the user would know they're deleting their e-mail. But I suppose a warning wouldn't hurt.

The case I'm more worried about is where the user has mucked with the local directory setting for the account, e.g., set it to a directory outside their profile that has other files in it, for whatever reasons. We can definitely detect that the directory is outside the profile, and we can tell if it looks like the original server directory we created. We could give a special warning in that case.

Comment 13

[Bryan Clark (DevTools PM) [:clarkbw]]

I'm sure we can slip in a label for the directory somewhere as long as we style it with some GrayText so it's not such a visible object.

Comment 14

[:aceman]

In bug 274452, we are adding a warning to the user and the optional possibility to remove the local directory if he chooses so.

Do let's keep the bug here for the case of Global Inbox, if anything special needs to be done. I will not change the behaviour in case of Global Inbox in bug 274452, just calling the existing nsMsgIncomingServer::RemoveFiles().

Comment 15

[Wayne Mery (:wsmwk)]

(In reply to :aceman from comment #14)

In bug 274452, we are adding a warning to the user and the optional
possibility to remove the local directory if he chooses so.

Do let's keep the bug here for the case of Global Inbox, if anything special
needs to be done. I will not change the behaviour in case of Global Inbox in
bug 274452, just calling the existing nsMsgIncomingServer::RemoveFiles().

You fixed that 8 months later. Do we still need this bug?

Comment 16

[:aceman]

Yes, see comment 7. Also we do not show the exact folder we are going to delete, as this bug requests. I don't know if that is needed, but it means bug 274452 does not cover this bug completely.