Open Bug 77652 Opened 24 years ago Updated 1 year ago

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

Categories

(MailNews Core :: Account Manager, defect)

defect

Tracking

(Not tracked)

People

(Reporter: sspitzer, Unassigned)

References

Details

(Keywords: triaged)

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.
fixing
Assignee: bhuvan → racham
adding mpt again.
Seth means "In the case of (2) Profile Manager" not Account Manager ;-).
right, profile manager. thanks for the clarification.
QA Contact: esther → nbaca
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.
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?"
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.
mass re-assign.
Assignee: racham → sspitzer
Product: Browser → Seamonkey
Assignee: sspitzer → mail
QA Contact: nbaca
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.
Assignee: mail → bienvenu
I think I'd like option 2) better.
OS: Other → All
QA Contact: mailnews-account
Hardware: PC → All
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 )
(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.
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.
Assignee: dbienvenu → nobody
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().
Component: MailNews: Account Configuration → Account Manager
Depends on: 274452
Product: SeaMonkey → MailNews Core
Severity: normal → minor
Summary: tell the user what directory we're going to delete when they confirm the accout deletion → tell the user what directory we're going to delete when they confirm the account deletion

(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?

Flags: needinfo?(acelists)

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.

Flags: needinfo?(acelists)
Severity: minor → S4
See Also: → 1546083
Keywords: triaged
You need to log in before you can comment on or make changes to this bug.