Closed Bug 562589 Opened 14 years ago Closed 14 years ago

If I disable migration wizard I'm in situation where all IMAP -folders are set to download no matter what I do to account in question (Needs a way to keep offline-use setting upon migration to Tb 3, even if Migration Assistant is disabled on purpose)

Categories

(Thunderbird :: Migration, enhancement)

enhancement
Not set
normal

Tracking

(blocking-thunderbird3.1 rc1+, thunderbird3.1 rc1-fixed, thunderbird3.0 .5-fixed)

RESOLVED FIXED
Thunderbird 3.3a1
Tracking Status
blocking-thunderbird3.1 --- rc1+
thunderbird3.1 --- rc1-fixed
thunderbird3.0 --- .5-fixed

People

(Reporter: timo.pietila, Assigned: bwinton)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.19) Gecko/2010031422 Firefox/3.0.19 (.NET CLR 3.5.30729)
Build Identifier: 

During migration from TB2 to TB3 with migration wizard disabled by config script: lockPref("mailnews.ui.show.migration.on.upgrade",false); and account download disabled for IMAP accounts with lockPref("mail.server." + serverFromAccount + ".offline_download", false); (there's a script to find IMAP accounts -> serverFromAccount) I'm in situation where offline download is disabled for account, but all folders in account are still set to download.

Migration wizard can set that with single click, but I'm guessing that requires coding that is not easy to do with config-script.

Reproducible: Always

Steps to Reproduce:
1. Build a config script with account offline download and migration wizard disabled
2. Migrate from TB2 to TB3
3. Look at the folder offline download status.
Actual Results:  
Account offline download is disabled as it should in account settings (UI still remains). All folders however are still set to download.

Expected Results:  
Folders are set not to download.

Easiest way to fix this IMO is to make migration _not_ change any user preferences if they are available in both TB2 and TB3. Show migration wizard to user in first use and let them decide what to do, or change things later if they wish. There might be reason for user to decide to offline download only few folders, none of the folders or all of the folders. That setting is gone with current migration process no matter how you set things.

This is big issue for corporate users with roaming profiles. Corporates just can't afford offline download because of that increases roaming profile size in intolerable amount. This sceanrio also is something that doesn't happen for home users, but they suffer the same loss of previous offline settings.
Depends on: 545563
(In reply to comment #0)
> account download disabled for IMAP accounts with lockPref("mail.server." +
> serverFromAccount + ".offline_download", false);

Meaning of this prefs.js setting is:
  When an IMAP folder is created or subscribed,
  set offline use=off (Folder properties, Synchronization, on if true).
  i.e. default of offline use=on/off of an IMAP folder.
This setting itself has no direct relation to enabled/disabled of auto-sync.
Auto-sync of Tb 3 respects offline use=on/off of folder property, "per folder control of auto-sync" became possible.  

To disable auto-sync of an account, next is required.
> (a) mail.server.serverX.autosync_offline_stores=false To disable auto-sync of 
>     (sorry but I don't know it works as exected or has some issues.)
To disable auto-sync entirely, next is required.
> (b) mail.server.default.autosync_offline_stores=false 
> (c) No mail.server.serverX.autosync_offline_stores=true
If above setting, folder property of offline-use=on/off becomes irrelevant to auto-sync because auto-sync is disabled, and the offline-use=on/off is used for download at "Work Offline" only.

UI for auto-sync setting never touches (a)/(b). Confusing but current UI for auto-sync is;
  Unchecked->Checked
    Set mail.server.serverX.offline_download=true
    Set offline use=on of all folders of the IMAp account  
  Cecked->Unchecked
    Set mail.server.serverX.offline_download=false
    Set offline use=off of all folders of the IMAP account
Assignee: nobody → bwinton
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
That's correct for autosync (tested it), but the situation where every folder is tagged for offline download still applies. If that is not used by anything as long as user does not press "download now" on folder properties it is minor issue, but rather confusing one.

Question: is that the only case when TB triggers download? just to make sure that this "autosync disabled" is safe option even when folders have this tag.
The code in question is http://mxr.mozilla.org/comm-central/source/mail/base/content/msgMail3PaneWindow.js#771

You can see that whether or not we start the Migration Assistant (whose code name is "FeatureConfigurator"), we upgrade all of the folders to set the Offline flag.

So, yeah, we should probably do something better here.  And since this has the potential to adversely affect upgrading users, and should be a fairly small fix, I'm nominating it for blocking rc1.

Thanks,
Blake.
blocking-thunderbird3.1: --- → ?
See Bug 541209(upon upgrade to Tb 3.0), Bug 544740(upon new account creation) for similar issues. See also WONTFIXed Bug 505759 and bugs pointed in that bug for issues around "auto-sync is enabled by default" and "offline use=off of all folder is automatically set".
Okay, here's a fairly tiny fix for this.  (I didn't change any of the code when I moved it into a new function, other than indentation.)  Andrew, what do you think?

Thanks,
Blake.
Attachment #442695 - Flags: review?(bugmail)
(In reply to comment #5)
> Add a pref to disable folder migration.

> +// We want to upgrade the folders to offline, so that we can get gloda goodness.
> +pref("mail.ui.migrate.folders.on.upgrade", true);

If new prefs.js entry will be introduced, I think "IMAP" and "offline use"(Gloda, if possible) is better to be explicitly represented in preference entry name.
Please note that one of major triggers of this bug is unclear meaning of next settings and very-hard-to-distinguish naming for peoples even if they are familiar with computer system, for who have to manage computer system used in a company even though lack of sufficient documentations which should have been provides by Mozilla.org or Mozilla Messaging company or community peoples like me. 
  mail.server.serverX.offline_download
  mail.server.default.autosync_offline_stores
  mail.server.serverX.autosync_offline_stores
I have to say that IMO you are breaking one of the very fundamental features of IMAP by forcing offline download to get benefit of _VERY MINOR_ email client function. Gloda is minor improvement, because function it servers is minor. No matter how good you make the search it will stay minor. 

Nobody is using email clients for "searching messages", they are using it to "read messages".

Nobody really cares if there is Gloda or not. That basic search function of TB2 has is enough for 99,99% of users, and rest that do actually need better search could settle to system that has much less impact on IMAP behavior than Gloda.

Because of that Gloda is no excuse to change folder or account offline download behavior during migration. Unless you have any other reason I strongly suggest that offline behavior is left unchanged by default, and _migration wizard_ is used to change that and _only_ _if_ user chooses so. Migration wizard should then explain what that change actually means for offline behavior.

Better yet, make that Gloda add-on. It certainly is not core function of email client. Much less than "collapsed headers", which actually impacts email UI affecting _READING_ of messages.
(In reply to comment #7)

Timo Pietilä, sorry but here is bugzilla.mozilla.org, not discussion forum. And, "one problem per a bug" is rule at B.M.O.
This bug is for next problem now.
  Even if user disables auto-sync by next setting via lockPref,
    mail.server.default.autosync_offline_stores=false
    mail.server.serverX.autosync_offline_stores=false
  and even though user sets offline-use=off for all IMAP folders by Tb 2,
  offline-use=on of all IMAP folders is automatically set,
  upon first use of Tb 3.0.x
(In reply to comment #6)
> > Add a pref to disable folder migration.

This is a good start - at least corporate admins would be able to disable this behaviour, which is probably unwanted in any large-scale TB migration.

I don't like the idea that the pref's value is true by default (which I think was also Timo's opinion, if I understood correctly). I can imagine tons of failed TB migrations because of this automatic downloading. But it's not a subject of this bug.

At least with this pref - in organizations where TB is deployed with customized settings and somebody has had time to research the subject and find out the existence of such preference beforehand - admins can prevent their users' profiles to suddenly grow to gigabyte-extents. So yes, this pref is absolutely a minimum requirement.

> > +// We want to upgrade the folders to offline, so that we can get gloda goodness.
> > +pref("mail.ui.migrate.folders.on.upgrade", true);
> 
> If new prefs.js entry will be introduced, I think "IMAP" and "offline
> use"(Gloda, if possible) is better to be explicitly represented in preference
> entry name.

True, that name is confusing. Based on the name only, I would presume that if the value was changed to false, folders might not get migrated to TB3 at all and would disappear, get unsubscribed, or somehow left to a state which is not compatible with TB3.
(In reply to comment #2)
> If that is not used by anything as long as user does not press "download now" on folder properties
> it is minor issue, but rather confusing one.
> Question: is that the only case when TB triggers download? just to make sure
> that this "autosync disabled" is safe option even when folders have this tag.

Manual download by "Download Now" bottun is basically independent from offline-use=on/off setting. If auto-sync is disabled, I think "Download Now" button of Tb 2 works any time like Tb 2. However, when auto-sync is enabled, "Download Now" button of Tb 3.0.x worked only when offline-use=off. Request by "Download Now" button looks to be intercepted and ignored by auto-sync, because auto-sync is probably executing schedule based downloading.
Confusing but there are two different use of offline-use setting, by auto-sync and by "Work Offline".
  offline-use=on : mails are downloaded by auto-sync if auto-sync is enabled
                   mails are automatically downloaded upon "Work Offline"
                    (really works well with auto-sync=enabled currently?)
                   "Download Now" button is ignored if auto-sync is enabled
                   "Download Now" button works if auto-sync is disabled
  offline-use=off: mails are not downloaded by auto-sync
                   mails are not automatically downloaded upon "Work Offline"
                   "Download Now" button works any time
Blake, is there a wiki page that covers things like this and does cover / would cover this preference?  I would like to understand the context a little better and know that this is something we care about enough to document; if we don't care enough to do that, then we probably don't need the preference.  (Preference adding is a red flag.)
I think these prefs are basically for TB autoconfig for migration etc. for corporate use. They could be hidden prefs for user, because user don't need to change those.

Anyway, I agree that the good documentation for those is in order. What I needed to do to get migration going as smoothly as possible for my organization required quite a lot of googling and putting together bits and pieces here and there and asking questions in newsgroup. AFAIK there is no single place to cover setting prefs for autoconfig. If there is it is quite hard to find.

If it is any assistance I could post my config.cfg to whoever is making wiki page for it and notes about how to edit and things to consider (or is it "anybody can edit" wiki?).
(In reply to comment #5)
> Add a pref to disable folder migration.

As migration is done only once upon first use of Tb 3.0, and as mail.server.serverX.offline_download is new pref from Tb 3.0,
  mail.server.serverX.offline_download=true  : default, removed from prefs.js
  mail.server.serverX.offline_download=false : saved in prefs.js
I think new pref is not required.
(1-A) mailnews.ui.show.migration.on.upgrade=true
      migration aid puts mail.server.serverX.offline_download=false in prefs.js
      if user asks not to touch offline-use 
(1-B) mailnews.ui.show.migration.on.upgrade=false
      User puts mail.server.serverX.offline_download=false in prefs.js
      before first use of Tb 3.0, if user want offline-use never be touched.
(2) Use mail.server.serverX.offline_download upon migration.
     if (threadPaneUIVersion < 7)
     {
       // Mark all imap folders as offline at the very first run of TB v3
       // We use the threadpane ui version to determine TB profile version
       For Each IMAP server
         if(mail.server.serverX.offline_download=false)
         { Never touch offline-use of any real folder of the IMAP account;}    
         else if(mail.server.serverX.offline_download=true or is not defined)
         { Set offline-use=on of all real folders of the IMAP account;}    
         else
         { Set offline-use=off of all real folders of the IMAP account;}    
         (fail safe. see Bug 550411)
I think that Wada's suggestion could work for me.

Timo, would that work for you as well?

Thanks,
Blake.
If I understand that correctly: 

Situation 1-B: if settings (both) are set to false by config script then migration does not touch to the user current offline settings. 

That would be perfect for me.
(In reply to comment #11)
> Blake, is there a wiki page that covers things like this and does cover / would cover this preference?

I tried to create new page at Mozilla Wiki for main page to put such documentations in it, and I could create next data in Mozilla Wiki, after creation of my account at Mozilla Wiki today.
> https://wiki.mozilla.org/MediaWiki_talk:Noarticletext
>   Thunderbird 2.0.x to Thunderbird 3.0.x Upgrade Guide
But, I couln't make the Wiki data "active new page in Mozilla Wiki".  
Help me, please.
(In reply to comment #16)
> (In reply to comment #11)
> > Blake, is there a wiki page that covers things like this and does cover / would cover this preference?
> 
> I tried to create new page at Mozilla Wiki for main page to put such
> documentations in it, and I could create next data in Mozilla Wiki, after
> creation of my account at Mozilla Wiki today.
> > https://wiki.mozilla.org/MediaWiki_talk:Noarticletext
> >   Thunderbird 2.0.x to Thunderbird 3.0.x Upgrade Guide
> But, I couln't make the Wiki data "active new page in Mozilla Wiki".  
> Help me, please.

https://wiki.mozilla.org/Thunderbird:Enterprise:Prefs should be editable.

(In reply to comment #12)
> If it is any assistance I could post my config.cfg to whoever is making wiki
> page for it and notes about how to edit and things to consider (or is it
> "anybody can edit" wiki?).

Yes that's the idea behind a wiki it's self editable and any body with a account can add/edit/update the content of the page.
After discussion with drivers, we think this does need to block.
blocking-thunderbird3.1: ? → rc1+
I believe this patch will be enough to make Timo happy.

The Migration Assistant could be better about not touching, or resetting individual folders' flags, but I think that's a different bug, and it may or may not block.

Thanks,
Blake.
Attachment #442695 - Attachment is obsolete: true
Attachment #443536 - Flags: review?(bugmail)
Attachment #442695 - Flags: review?(bugmail)
Whiteboard: [has patch, needs review, landing]
(In reply to comment #19)
> The Migration Assistant could be better about not touching, (snip)

Enhancement of Migration Assistant based on enhancement by this bug will probably be requested in Bug 541209.
Comment on attachment 443536 [details] [diff] [review]
[Checked in to trunk, 3.1, and 3.0] A patch that implements Wada's suggestion.

I transplanted Wada's wiki contribution to the correct page.  I think a mis-click on the 'this page has no content' page resulted in him editing the talk page for that page rather than the correct page...
Attachment #443536 - Flags: review?(bugmail) → review+
Whiteboard: [has patch, needs review, landing] → [needs landing]
(In reply to comment #21)
> I transplanted Wada's wiki contribution to the correct page.

Andrew Sutherland, Thanks! I looked Noarticletext part only then I was thinking it's a sort of template I made for new page...
I could successfully create Thunderbird:Enterprise:Migration by looking into Enterprise:Prefs you created for me.
> https://wiki.mozilla.org/Thunderbird:Enterprise:Migration
To all comment posters in this bug.
This is draft for migration guide. Please change it to appropriate structure and modify its content to appropriate one.
(In reply to comment #19)
> A patch that implements Wada's suggestion.
>(snip)
> The Migration Assistant could be better about not touching, or resetting
> individual folders' flags, but I think that's a different bug, and it may or
> may not block.

I absolutely agree with you. But, even after your change, order of execution is still next.
(line number is before your change)
768     if (threadPaneUIVersion < 7)
769     {
770       // Mark all imap folders as offline at the very first run of TB v3
771       // We use the threadpane ui version to determine TB profile version
(snip, your change is made at here)
787       // Open a dialog explaining the major changes from version 2.
788       if (gPrefBranch.getBoolPref("mail.ui.show.migration.on.upgrade"))
789         openFeatureConfigurator(true);
790 
791       gPrefBranch.setIntPref("mailnews.ui.threadpane.version", 7);
792 
793     } // version 7 upgrades

Although your change is sufficient for this bug, above order is bad for next;
 - Support of disable of IMAP offline-use change by featureConfigurator.js
   for personal user 
 - Support of disable of Gloda by featureConfigurator.js or other
   for corporate and personal user
 - Support of stop forcing "Smart Folders" view by featureConfigurator.js or
   other for corporate user
   (if Tb 3.2, name is changed and is not forced, so no need to change)
I think order of offline-use setting part and FeatureConfigurator part is better to be reversed in you change prior to other enhancement requests. It looks for me that normal order is reversed order.
What do you think?
Will something wrong occur if execution order is reversed? 

Note: featureConfigurator.js is currently for IMAP's auto-sync option only.
http://mxr.mozilla.org/comm-central/source/mail/base/content/featureConfigurator.js#121
121       // Look for imap servers.
129       // If there aren't any imap servers, don't show the autosync page.
(In reply to comment #7)
As I wrote before, I created next Mozilla Wiki page.
> https://wiki.mozilla.org/Thunderbird/Enterprise/Migration
It's currently summary of findings in this bug, some of your concerns around IMAP, and some issues around IMAP seen in bugzilla.mozilla.org, although it's  titled as "Migration Guide".
Timo Pietilä, if you have other concerns or are experiencing problem around IMAP in migration from Tb 2 to Tb 3, please add items to the page. Theres is no need to put accurate information nor proper answer/guide yet, so adding concerns or issues is sufficient.
(In reply to comment #23)
> I think order of offline-use setting part and FeatureConfigurator part is
> better to be reversed in you change prior to other enhancement requests. It
> looks for me that normal order is reversed order.
> What do you think?
> Will something wrong occur if execution order is reversed? 

The problem is that it's non-trivial to switch those around, because the FeatureConfigurator is being launched "later", and may not be launched at all.

I could re-order the code, but that wouldn't change the order of execution of the various functions, so it won't actually help.

In any case, all of this discussion belongs in a different bug, because I've just committed this patch, and since it fixes the original problem I'm marking this bug closed.  ;)

Committed as:
http://hg.mozilla.org/comm-central/rev/4d9b9f285196
and
http://hg.mozilla.org/releases/comm-1.9.2/rev/0f852a8f52c4

Thanks,
Blake.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
OS: Windows XP → All
Hardware: x86 → All
Resolution: --- → FIXED
Whiteboard: [needs landing]
(In reply to comment #25)
> The problem is that it's non-trivial to switch those around, because the
> FeatureConfigurator is being launched "later", and may not be launched at all.

Roger.

> In any case, all of this discussion belongs in a different bug, because I've
> just committed this patch, and since it fixes the original problem I'm marking
> this bug closed.  ;)

I see.

> Committed as:
> http://hg.mozilla.org/comm-central/rev/4d9b9f285196
> and
> http://hg.mozilla.org/releases/comm-1.9.2/rev/0f852a8f52c4

Thanks for fixing this bug.

By the way, is there any plan to land your patch on next Tb 3.0.x?
If your patch will be landed on Tb 3.0.x, we can always say "You should have set mail.server.serverX.offline_download=false before your upgrade. Have you really searched Google well by yourself using your hand?" to any future complaints after your patch :-)
I didn't plan to, but feel free to ask Standard8 if he feels it would be useful there.  :)
(In reply to comment #27)
> I didn't plan to, but feel free to ask Standard8 if he feels it would be useful there.  :)

Blake Winton, can you attach patch for Tb 3.0.5 with approval‑thunderbird3.0.5=?
Whiteboard: [Want patch landed on Tb 3.0.x because safe]
(In reply to comment #26)
> By the way, is there any plan to land your patch on next Tb 3.0.x?
> If your patch will be landed on Tb 3.0.x, we can always say "You should have
> set mail.server.serverX.offline_download=false before your upgrade. Have you
> really searched Google well by yourself using your hand?" to any future
> complaints after your patch :-)

Sorry, but that kind of answer for things like this really, really bug me, especially when directed at normal users.

It is simply *not* *normal* for a user to have to manually edit a preference file before launching a program that upgrades *itself*, *and* *then* *restarts* *itself* *after* *the* *upgrade*, just to prevent the program from messing with his carefully selected *existing* *preferences*.

Yes, it would be appropriate if a Sys Admin complained about his fubared mass migration, but if I were an ordinary, non commercial user and complained, such a retort would only make me be inclined to tell you where to shove your mail client.

The bottom line is, this is a major usability bug that absolutely should be fixed *properly* before an upgrade is *forced*, and if the developers *choose* to not do so, they should not then turn around and make ridiculous responses like the above when people complain.
(In reply to comment #30)

Charles Marcus, are you planning to do what you did in already closed Bug 505759 again in this bug?

Please read and understand comment #25 before add any further comments to this bug.
Further enhancement(s) or change(s) which is required to resolve problem of your Bug 541209 should be requested in that bug instead of in this bug.
To resolve problem of Bug 541209, further change like next is required.
a) Keep current 'FeatureConfigurator is being launched "later"',
   back out "setting offline-use=on by migration code" by Migration Assistant.
b) Keep current 'FeatureConfigurator is being launched "later"' is kept,
   do "setting offline-use=on by migration code" after Migration Assistant.
c) Change from 'FeatureConfigurator is being launched "later"'
   to 'FeatureConfigurator is being launched "immediately"',
   and reverse order of "set offline-use=on" and "launch FeatureConfigurator".
As Dan Mosedale asked you to check with Tb 3.1b1 in that bug, and b) and c) is apparently not done yet, I asked him whether change like a) is already done in Tb 3.1b2 or not.
Comment on attachment 443536 [details] [diff] [review]
[Checked in to trunk, 3.1, and 3.0] A patch that implements Wada's suggestion.

Since the previous patch applies pretty cleanly, I'll just ask for approval here instead of attaching a new patch.

Thanks,
Blake.
Attachment #443536 - Attachment description: A patch that implements Wada's suggestion. → [Checked in to trunk and 3.1] A patch that implements Wada's suggestion.
Attachment #443536 - Flags: approval-thunderbird3.0.5?
FYI.
Following is bug 541209 comment #19 by David :Bienvenu.
> Yeah, this code needs to go away -
> http://mxr.mozilla.org/comm-central/source/mail/base/content/msgMail3PaneWindow.js#775
I sounds that solution will be b) like one.
Attachment #443536 - Flags: approval-thunderbird3.0.5? → approval-thunderbird3.0.5+
And committed to the TB3.0 tree as:
http://hg.mozilla.org/releases/comm-1.9.1/rev/bab463cdd8d1

Later,
Blake.
Attachment #443536 - Attachment description: [Checked in to trunk and 3.1] A patch that implements Wada's suggestion. → [Checked in to trunk, 3.1, and 3.0] A patch that implements Wada's suggestion.
Whiteboard: [Want patch landed on Tb 3.0.x because safe]
Whiteboard: [Fixed by all of Tb 3.0.5pre, Tb3.1pre, Tb3.2pre]
Whiteboard: [Fixed by all of Tb 3.0.5pre, Tb3.1pre, Tb3.2pre]
Target Milestone: --- → Thunderbird 3.2a1
Severity: major → enhancement
Version: unspecified → Trunk
Summary: If I disable migration wizard I'm in situation where all IMAP -folders are set to download no matter what I do to account in question → If I disable migration wizard I'm in situation where all IMAP -folders are set to download no matter what I do to account in question (Needs a way to keep offline-use setting upon migration to Tb 3, even if Migration Assistant is disabled on purpose)
Timo Pietilä(bug opener), can you check with nightly build?

As Blake Winton landed patch on Tb 3.0 branch too, you can check with any of next release or future versions. You can get nighltly builds at following site. You can check by UNZIP only if you download win32.zip and if you check on Win.
Please change to VERIFIED if you confirm that problem of this bug was fixed by the patch, please.

Tb 3.0.6pre
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1-l10n/
Tb 3.1pre
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.2/
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.2-l10n/
Tb 3.2a1pre
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central-trunk/
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central-l10n/
Will test as soon as I get a bit time, just now I'm kind of busy doing some near-deadline stuff. I'll trust that this fixes things for me but testing and confirimng is obviously better than blind trust.
Code which changed to offline-use=on for all IMAP folders upon migration has been moved to Migration Assistant by bug 569161. So, if Migration Assistant is disabled, offline-use setting of any IMAP folder is never touched upon migration to Tb 3.1 and Tb 3.2. Patch of bug 569161 is landed on Tb3.1rc2 and Tb3.2a1(As of 2010/06/07). So, currently available workariund  is:
> To disable per folder "offline use" setting change upon migration (Tb 3.0.5 to Tb 3.1rc1):
>   lockPref("mail.server." + serverFromAccount + ".offline_download", false);
> To disable per folder "offline use" setting change upon migration (Tb 3.1rc2 or later):
>   lockPref("mailnews.ui.show.migration.on.upgrade",false);
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: