Open Bug 532159 Opened 15 years ago Updated 2 years ago

Disable archive settings for gmail accounts. / When Archive folder is changed on gmail granularity is not respected.

Categories

(Thunderbird :: Account Manager, defect)

x86
All
defect

Tracking

(Not tracked)

People

(Reporter: Usul, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 3 obsolete files)

1. set archive_folder to soemthing different than All mail
2. set granularity to 2

Archive some emails.

They end up flat in the archive_folder instead of per month.
Maybe... they fixed it in 3.3 Alpha 3, but it is back in TB 5.0 Beta 1 for Gmail.
(In reply to comment #2)
> Maybe... they fixed it in 3.3 Alpha 3, but it is back in TB 5.0 Beta 1 for
> Gmail.

It wasn't properly "fixed" in 3.3a3; Gmail just lost the special-case logic that it used to have, which caused the default to be yearly archiving for Gmail. That's obviously a pretty bad default, and so the easiest way was to restore the old logic.

The correct way to fix this is to set the pref to "flat archiving" on Gmail account creation (or on migration to a newer version), but my knowledge of account/identity settings is pretty limited.
I'm seeing this issue with a non-Gmail IMAP account on my own mail server.

I originally had set it up to use YYYY-MM sub-folders under "Archives", but then changed it to just archive into one folder. Thunderbird shows the "one folder" option as being selected in preferences but appears to be ignoring it and still archives into sub-folders.
Isn't this fixed by bug 640342?
(In reply to :aceman from comment #6)
> Isn't this fixed by bug 640342?

Historry is perhaps as follows.
  1. Bug 475852 forced single archive level for safety => this bug was opened.
  2. Somehow change was lost, because comment of patch for 640342 is "Re-add the code from bug 475852",
      then change by bug 475852 was applied again => This bug still occurs.
  3. After it, by Bug 798663, isGmail is always correctly set if Gmail IMAP server is accessed
      even if accessed to imap.googlemail.com instead of imap.gmail.com,
  4. After it, UI for Archive Settimgs is also changed(archive granuality setting is hidden if Gmail IMAP),
      in order to aavoid user's confusion.

I believe keeping "Archive of Gmail IMAP in Thunderbird" == "Archive of Gmail in Gmail's Web Interface" is important, because "Archive in Thunderbird" implies "Move mails"(i.e. mail is copied to Archive folder and is deleted from original folder, so mail in Arcihves folder won't be lost unless user does do delete at Archives folder or subfolder of Archives"). 
Becuse of particularity of Gmail/Gmail IMAP, [Gmai]/All Mail/yyyy/mm/ABC is merely a Gmail Label. So, "copy mail in Gmail/All Mail to Gmail/Trash" always removes Gmail Label of "[Gmai]/All Mail/yyyy/mm/ABC" from a mail.
i.e.
User looses mail in  "[Gmai]/All Mail/yyyy, "[Gmai]/All Mail/yyyy/mm", "[Gmai]/All Mail/yyyy/mm/ABC", merely by "copy/move mail in [Gmail]/All Mail or other Gmail IMAP Folder(==Gmail Label) to [Gmail]/Trash.

I think "Adding Gmail Label of [Gmai]/All Mail/yyyy/mm/ABC to a mail by single Archive operation" is convenient for power users, but it's pretty dngerous for general users.
I think "filter like action" is better than "Archive" for such purpose, and it's not so hard work for addon developers.
   Button to add Gmail Label of "AA/BB/CC/yyyy/mm/PQR/XYZ" == Button to copy mail to AA/BB/CC/yyyy/mm/PQR/XYZ in Tb.
If Gmail IMAP, "archive like mail copy" is relatively simple, because Gmail IMAP folder is merely a Gmail Label.
    When "create AA/BB/CC/DD" is requested, Gmail merely generates Gmail Label of  "AA/BB/CC/DD".
        => only AA/BB/CC/DD is returned to LIST. AA, AA/BB, AA/BB/CC is not returned to LIST
        => Tb shows AA, AA/BB, AA/BB/CC as italic/gryed folder at folder pane == folder of msgFolder.noSelect=true.
    When "AA/BB/CC/DD" exists but "AA/BB/CC" doesn't exist, gmail geerates "AA/BB/CC" when "creare AA/BB/CC" is requested.
So, "copy a mail to AA/BB/yyyy/mm/PP/QQ like archive" is as follows if Gmail IMAP.
1. get msgDBHdr of a mail, obtain Date of  the mail, generate "yyyy/mm" from mail date.
2. if AA/BB/yyyy/mm/PP/QQ doesn't exist,                 "create AA/BB/yy/mm/PP/QQ".
    if AA/BB/yyyy/mm/PP/QQ is noSelect=true folder, "create AA/BB/yy/mm/PP/QQ".
3. Copy the mail to AA/BB/yyyy/mm/PP/QQ.
4. Needless to say, "copy/move to [Gmail]/Trash", "copy/move to [Gmail]/Spam" should be prohibited by above operation.
    "copy/move mail to folder under [Gmail]/All Mail" should be prohibited too.
If you install "Custom Buttons" addon, you can see example of a button for "Add Gmail Label of ABC/yyyy/mm to a mail".
As "Archive options" is disabled for gmail accounts, isn't this WFM/WONTFIX?
To  Ludovic Hirlimann [:Usul](Bug opener) :
Do you still beleve that following is bad action or incorrect action?
(A)  default of "Archive in Thunderbird for Gmail IMAP"  == Move to [Gmail]/All Mail with no granuality option 
       == Remove Gmail Label (same as Gmail Web Interface).
      If "Archives Folder specified by Copies&Folders setting" doesn't exists, silently falls bck to this default,
      withput changing  Copies&Folders setting.
(B)  When Gmail IMAP follder is selected by user as "Archive" folder and the folder exists,
      "Archive in Thunderbird for Gmail IMAP" == Move to specified Gmail IMAP folder with no granualrity option
       == Change Gmail Label of a mail

I can't understand reason why granualrity option is prohibited in case (B).
If other Gmail IMAP folder(==Gmail Label) is permitted by Tb as Archive folder, I think granuarity option should be provided.
If perfect "Archive is same in Tb and Gmail" is mandatory, when Gmail IMAP folder(==Gmail Label) is specified as Archive folder, [Gmail]/All Mail should be always used, regardless of folder choice by user at Copies&Folders.
Attachment #8550836 - Attachment description: Button Script sample : Add Gmail Label of <Archive>/yyyy/yyyy-mm to selected mails, by copy or move(hardcoded) to folder specified in archive option with granuarit → Button Script sample : Add Gmail Label of <Archive>/yyyy/yyyy-mm/<kept-structure> to selected mails, by copy or move(hardcoded) to folder specified in archive option with granuarit
Attachment #8550836 - Attachment description: Button Script sample : Add Gmail Label of <Archive>/yyyy/yyyy-mm/<kept-structure> to selected mails, by copy or move(hardcoded) to folder specified in archive option with granuarit → Button Script sample : Add Gmail Label of <Archive>/yyyy/yyyy-mm/<kept-structure> to selected mails, by copy or move(hardcoded) to folder specified in archive option with granuarity
Attachment #8550690 - Attachment is obsolete: true
(In reply to WADA from comment #12)
> I can't understand reason why granualrity option is prohibited in case (B).

Because, in GMail All Mail is *the* archive. You're not supposed to use anything else and doing so would just be confusing in the end.
(In reply to Magnus Melin from comment #14)
> (In reply to WADA from comment #12)
> > I can't understand reason why granualrity option is prohibited in case (B).
> Because, in GMail All Mail is *the* archive. You're not supposed to use
> anything else and doing so would just be confusing in the end.

If so, I believe "other Gmail IMAP folder than [Gmail]/All Mail" should be ignored for consistency, in order to avoid user's confusion.
- If "Archives folder of account" requests "Archives of this Gmail IMAP aclount", force [Gmail]/All.Mail.
- If "Otther:" requests "other Gmail IMAP folder than [Gmail]/All Mail, force [Gmail]/All.Mail.
I believe this is needed to close this bug as WONTFIX.

As known by my button scriipt sample, which is almost dead copy of Tb's archive code, filter/archive like "adding Gmail Label using copy/move in Tb" is easily implemented as pretty simple extension.
If you install "Custom Buttons" addon, you can do it merely by "add a button", "paste the button script sample".
Let me step in here, since I wrote the code that disabled this (the second time) in bug 640342. The only reason you can't change archive granularity for Gmail accounts was because it was an easier patch than setting the default for Gmail accounts to be "flat" and allowing people to change it. If there's someone who knows how default settings for identities works, then by all means, add the ability for Gmail users to set the archive granularity.

I really can't follow the attachments WADA is posting (they don't seem to be actual patches?), so I don't have much to say on that front, but if someone would like to allow Gmail users to set the archive granularity, go for it. Just make sure that the default for Gmail is "flat", and that non-Gmail defaults to "yearly" (I think that's the default anyway).
(In reply to Jim Porter (:squib) from comment #17)

IIUC, why bug 640342 was requested was;
   [Gmail]/All Mail]/xxx/yyy is never subfolder of [Gmail]/All Mail. 
   [Gmail]/All Mail]/xxx/yyy is merely a Gmail Label named [Gmail]/All Mail]/xxx/yyy.
   Move mail from "[Gmail]/All Mail" to "[Gmail]/All Mail]/xxx/yyy" won't move mail. It merely adds Gmail Label 
   So, when user copied or moved a mail from [Gmail]/All Mail to [Gmail]/Trash or [Gmail]/Spam,
   mail in [Gmail]/All Mail/xxx/yyy disappers => data loss for user.
   So, if Archives == [Gmail]/All Mail, prohibiting granularity is mandatory.
   Power users can use granularity and/or Archives == a Gmail Label with correctly understanding Gmail's particularityl.
   But general user can't. "Archuve for Gmail IMAP in Tb" === "Archive in Gmail Web Interface" should be kept for general users.
Is it wrong?

> If there's someone who knows how default settings for identities works, then by all means,
> add the ability for Gmail users to set the archive granularity.

Do you say "Archuve for Gmail IMAP in Tb" === "Archive in Gmail Web Interface" is not mandatory?
Please note that my request is;
   When "other folder than [Gmail]/All Mail of the Gmail IMAP account" is selected at "Other:", please force Archives=[Gmail]/All Mail.
   Force Archives==[Gmail]/All Mail if user requested any Gmail IMAP folder of this account as Archive folder, please. 
Note:
If Archives = [Gmail]/Trash or [Gmail]/Spam, above "data loss" won't occur. However, another "data los" for user occurs :
   Archived mail is removed from [Gmail]/All Mail

Purpose of my attaching script code to this bug is to state:
   "Archive for Gmail IMAP in Tb" === "Archive in Gmail Web Interface" is pretty important.,
   Simple addon or extention is possible and easy for your purpose.
   Power user can modify granularity option via Config Editor if he wants to use the option setting for such addon or extension.
   Please don't request granularity option of Gmail IMAP account any more.
IIRC, "Trash folder==[Gmail]/Trash if IMAP delete model=move to Trash" is forced currently, in order to avoid user's confusions due to particuliaty of Gmail IMAP, and in order to avoid "data loss for user" due to user's confusions.
(In reply to WADA from comment #18)
>    So, if Archives == [Gmail]/All Mail, prohibiting granularity is mandatory.

I'm reasonably sure that's not the case. The main issue was that it caused archiving in Thunderbird to add extra labels that you wouldn't expect in Gmail's web UI. I don't recall ever seeing a dataloss issue.

> > If there's someone who knows how default settings for identities works, then by all means,
> > add the ability for Gmail users to set the archive granularity.
> 
> Do you say "Archuve for Gmail IMAP in Tb" === "Archive in Gmail Web
> Interface" is not mandatory?

I see no reason why it would be. It might cause Gmail to put the message in both the root "All Mail" folder as well as whatever subfolder Thunderbird decided it belonged in, but I don't think that would actually break anything.
(In reply to Jim Porter (:squib) from comment #19)
> (In reply to WADA from comment #18)
> >    So, if Archives == [Gmail]/All Mail, prohibiting granularity is mandatory.
> I'm reasonably sure that's not the case. The main issue was that it caused archiving in Thunderbird to add extra labels
> that you wouldn't expect in Gmail's web UI.

It's applicable to any mail copy/move from "other than [Gmail]/Trash and [Gmail].Spam" to "other than [Gmail]/Trash and [Gmail]/Spam".
Because Gmail Label is shown as imap folder to Gmail IMAP client, and because "create folder by imap client" == "creaate Gmail Label", "Gmail Label correspomds to folder which is shown in folder pane of Tb" always exists in Gmail Web UI".

Please note that user never calls "Gmail Label of [Gmail]/All Mail/yyyy/yyyy-mm/<folder_structure> created by Tb's archive" "extra labels that he wouldn't expect in Gmail's web UI", if user correctly understand particularity of Gmail/Gmail IMAP.
I believe "Sub folders under [Gmail]/All Mail which is created by Tb's archive" and "such sub folders are merely a Gmail Label" surely produces general user's confusions in addition to compliant of "extra labels that he wouldn't expect in Gmail's web UI".
This is reason why I believe "Tb's archive for Gmail IMAP" should be "Remove Gmail Label" == same action as archive in Gmail Web UI.
  - Archive folder in Tb should be [Gmail]/All Mail always, if user requested "folder of Gmail IMAP" as archive folder.
  - Because of [Gmail]/All Mail, subfolder of it shouldn8t be generated by Tb's archive feature.<= this is already done by you
I'm totally fine with having the defaults so that it looks good for the most people. What I do object though, is ignoring the handcrafted settings I entered in the Advanced Config Editor:

I've set the Archive Folder to "Archives" - like in all my other (non-GMail accounts) - and the granularity in the Advanced Config Editor to "2" - like in all my other (non-GMail accounts). Moving the mails manually there I can create exactly the structure I'd like to have, mirroring the setup of all the other accounts. Even checking out the web interface, it correctly assigns the "Archives/2015/2015-10" label correctly.

As a solution I would propose removing the forceSingle check introduced in http://hg.mozilla.org/comm-central/rev/ff095e73f250 or additionally adding a guard that the forceSingle check is only applied when the Archive Folder is set to "[Gmail]/All Mail]".
(In reply to david from comment #21)
> I'm totally fine with having the defaults so that it looks good for the most people.
> What I do object though, is ignoring the handcrafted settings I entered in the Advanced Config Editor:

IIRC, such setting worked pretty well, because "Disabling granularity setting if Gmail IMAP" is dobe by "graying out granularity setting at setting panel" only, and backend code for granularity prefs seeting is not touced.

Was your "handcrafted settings by Config Editor" correct?
Did you restart Tb after your setting change via. Config Editor?

If setting change from UI for arcive setting, UX code updates both prefs.js setting and global valuable used by Archve feature while Tb is runing.
But, if you changed prefs.js setting only via Config Editor, no one will read the modified prefs.js setting for using it by Archive feature.
Did you enter archive setting panel and pressed OK after your setting change via. Config Editor?
If so, UI and UX for archive setting panel perhaps reset granularity value.
I have a corporate gmail account where I have configured a manual archive folder. I have followed the above discussion and tried setting the preferences manually and then starting thunderbird ; however it still wants to archive in the top level manually configured folder and not the yearly subfolders I wanted. 

Is this not possible?
Severity: normal → S3
Component: Folder and Message Lists → Account Manager
Summary: If Archive folder is changed on gmail granularity is not respected. → Disable archive optinos for gmail accounts. / When Archive folder is changed on gmail granularity is not respected.
Summary: Disable archive optinos for gmail accounts. / When Archive folder is changed on gmail granularity is not respected. → Disable archive settings for gmail accounts. / When Archive folder is changed on gmail granularity is not respected.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: