Bugzilla

Comment 1

•

14 years ago

Well, being able to switch off the archiving feature entirely is suggestion (b) in bug 511741 comment #1, which in the next comment was suggested to be moved into a separate bug. Thus, unless it's filed anywhere else already, that would be *this* bug and therefore not a duplicate.

Also see my bug 511741 comment #3, related to bug 517514, for combining this with the granularity option and UI under development there.

Comment 2

•

14 years ago

According to Roland in the attached URL, bug 511741 is tracking the ability disable archive, so setting this more specific bug to block.


Note that in the technical sense, this bug is in fact an enhancement: TB has never before had the ability to disable archiving completely. While it does seem reasonable that this feature should have been added when archiving was, this did not happen, so this is a missing feature, not a bug.

Blocks: 511741

URL: http://getsatisfaction.com/mozilla_me...

Severity: normal → enhancement

Version: unspecified → 3.0

Comment 3

•

14 years ago

I'll go ahead and confirm that, an unconfirmed bug shouldn't block a confirmed one after all. ;-) The reasoning in comment #2 makes sense, the bug here would have to provide some backend solution for disabling the archive feature first before it can be considered for a first-use warning as suggested in bug 511741.

Status: UNCONFIRMED → NEW

Ever confirmed: true

OS: Windows XP → All

Hardware: x86 → All

Whiteboard: dupme

Reporter

Comment 4

•

14 years ago

(In reply to comment #2)
> Note that in the technical sense, this bug is in fact an enhancement: TB has
> never before had the ability to disable archiving completely.

Lol... well, it never had *archiving* either.

Regardless, I hope this gets added soon, this really really 'bugs' me...

Comment 5

•

14 years ago

could someone clarify whether this bug is just about disabling *automatic archiving*, or, also including manual archiving with the "a" key / Archive button?

because the bug's description reads quite differently depending which meaning you take.

i would agree that having automatic archiving newly enabled in TB3 by default, with no warning and no way to turn it off, is a Really Bad Idea. (particularly if it operates on folders other than the Inbox, but that i haven't figured out yet.) either way, the somewhat urgent tone of the original description makes sense. while manual archiving seems to me like a different case.

i found on this page:
http://support.mozillamessaging.com/en-US/kb/Archived+messages
the following statement:
"The frequency of the automatic archiving is based on the mail.server.default.archive_granularity setting, which is set to "1" (monthly) by default. To disable automatic archiving, change the value to "0"."
...however on any other page i've found referencing that setting, it's described only as affecting whether your Archives folder has year/month subfolders or not.

so, is that statement true, and if so, does it solve this bug?

Comment 6

•

14 years ago

I'm not aware of any "automatic" archiving, it's always a manual process unless a filter option is available already (I only see Move or Copy as filter action but not Archive).

That support article appears to be incorrect. Currently, it is not possible to disable archiving (otherwise this bug would have been closed already), the only effect this preference has is the subfolder structure. A value of "0" simply implies that no subfolders are created in the specified Archives folder.

Updated

•

14 years ago

Depends on: 547493

Comment 7

•

14 years ago

Have a look at http://mxr.mozilla.org/comm-central/ident?i=archiveGranularity, the values of that preference are defined in nsIMsgIncomingServer.idl:

> 535   /**
> 536    * @{
> 537    * This attribute and constants control the granularity of sub-folders of the
> 538    * Archives folder - either messages go in the single archive folder, or a
> 539    * yearly archive folder, or in a monthly archive folder with a yearly
> 540    * parent folder. If the server doesn't support folders that both contain
> 541    * messages and have sub-folders, we will ignore this setting.
> 542    */
> 543   const long singleArchiveFolder = 0;
> 544   const long perYearArchiveFolders = 1;
> 545   const long perMonthArchiveFolders = 2;
> 546   attribute long archiveGranularity;

The respective handling of archive requests is done in mailWindowOverlay.js in the archiveSelectedMessages function. This would be a good starting point for switching off archiving, e.g., by introducing another (-1) enumerated value to prevent that function from adding any archive actions to the batch.

Comment 8

•

14 years ago

(In reply to comment #5)
> could someone clarify whether this bug is just about disabling *automatic
> archiving*, or, also including manual archiving with the "a" key / Archive
> button?

I assumed this was about disabling manual archiving.

> because the bug's description reads quite differently depending which meaning
> you take.

It does indeed.

> i would agree that having automatic archiving newly enabled in TB3 by default,
> with no warning and no way to turn it off, is a Really Bad Idea.

I would too. I would in fact capitalize that further.

> i found on this page:
> http://support.mozillamessaging.com/en-US/kb/Archived+messages
> the following statement:
> "The frequency of the automatic archiving is based on the
> mail.server.default.archive_granularity setting, which is set to "1" (monthly)
> by default. To disable automatic archiving, change the value to "0"."
> ...however on any other page i've found referencing that setting, it's
> described only as affecting whether your Archives folder has year/month
> subfolders or not.

I was considerably surprised (not to say alarmed) to read that statement just now in the article linked, which appears to say that TB does in fact turn on automatic archiving by month, especially because this has not taken effect on any of my (two dozen, mostly IMAP) accounts (some added before upgrade to 3.0, some after), even though the pref given is still at its default value of 1.
I filed a clarification doc bug (bug 547493) on that, blocking this one.

Comment 9

•

14 years ago

The granularity is "per month" by default, you still have to invoke "Archive" manually (I'd have noticed if it's archiving automatically once every month).

Comment 10

•

14 years ago

Ok... well, that article is actually the help file about archiving, it's what you get when you choose "Thunderbird Help" from the Help menu, and look under "General - Archived messages". And it does appear to be completely wrong.

That might explain Charles Marcus' original description of this bug a little better?

Because otherwise I don't really see anything being "shoved down our throats" etc. - just don't press the Archive button. There are even extensions already to remove the button and remap the "a" key.

Charles?

Comment 11

•

14 years ago

Jeff, you may want to read the motivation in bug 511741 and the support thread Nathan has linked to in the heading of this bug. The issue is an /accidental/ archiving. Thus, if someone doesn't need the feature, it makes sense to provide an option to disable it.

Whiteboard: [gs]

Updated

•

14 years ago

Blocks: 547493

No longer depends on: 547493

Comment 12

•

14 years ago

personally i won't use the archiving because its date-based folder structure doesn't suit me. so it's fine with me if there's a way to disable it altogether. a better solution might be to improve it so it's more useful.

the issue of accidental archiving is only caused by the single-key shortcut. therefore i would rather see a solution addressing single-key shortcuts in general, rather than disabling the individual features they invoke.

but i don't feel very strongly about either of these, either way.

i only commented after reading in the help menu that the archiving would happen automatically. i guess it turns out it doesn't. as far as i'm concerned it's not really that urgent to disable manual archiving, i can learn to ignore it. now that nathan has filed a bug on the documentation, i guess i'm done here.

i'm not sure that the original reporter's issue was with accidental archiving, maybe he had the same misunderstanding as i did. so let's hear from him.

Reporter

Comment 13

•

14 years ago

(In reply to comment #10)
> Ok... well, that article is actually the help file about archiving, it's what
> you get when you choose "Thunderbird Help" from the Help menu, and look under
> "General - Archived messages". And it does appear to be completely wrong.
> 
> That might explain Charles Marcus' original description of this bug a little
> better?
> 
> Because otherwise I don't really see anything being "shoved down our throats"
> etc. - just don't press the Archive button. There are even extensions already
> to remove the button and remap the "a" key.
> 
> Charles?

Ok, I was in a really bad mood when I made that comment, so I apologize for that. But yes, I want a way to completely disable archiving. I don't want our users to 'accidentally' archive anything, because no matter what the key/key combination is, some of them will do it.

And fyi, if Archiving *had* been made fully automatic as described in that help article - well, we probably wouldn't be having this conversation because I probably would have never used TB again - and this is from someone who loves TB, and has been using it in our 50+ small company exclusively since about version 0.8.

When features like this are designed, consideration really needs to be given to those of us who are trying to use TB in a corporate environment.

Hopefully, eventually, TB (and FF) will become enterprise ready by supporting Group Policies (wow - I just checked and there doesn't even seem to be a bug open for this???), and when that happens, Admins will *require* the ability to define things like this.

For example, I still maintain that one of the more useful purposes for archiving is quota management (move messages off a server to relive an over quota issue), so at a minimum, the archiving feature needs to be a lot more robust (able to define a completely different location for archiving messages, like, for example - the Local Folders, an archive server (slower/less expensive storage), etc...

[OT]
There are/were a few things about TB3 that really annoyed me when I first started using it, and I felt like the devs were ruining a potentially awesome update of TB by forcing some UI changes on everyone - Tabs is one example. I really hated them at first - I still don't like them, but have figured out how to disable them for everything but the Calendar, so I can live with that for now, even though I still want the option to open the Calendar in the current Tab to achieve old TB2 behavior. Another example is totally ignoring my carefully selected offline folder settings for my 16+ IMAP accounts and just forcing everything to full offline mode. Honestly, that one thing is probably responsible for most every 'rant' I've made since TB3 went gold... I still get infuriated when I recall figuring out what happened and that it was intentional.
[/OT]

Comment 14

•

14 years ago

ok, fair enough. so this bug is about completely disabling manual archiving, in case users might do it accidentally.

in the meantime, a work-around for some might be the "keyconfig" addon, which lets you completely disable the Archive key shortcut (and any other "dangerous" keys, like "j"...)
http://forums.mozillazine.org/viewtopic.php?t=72994
http://kb.mozillazine.org/Keyconfig_extension:_Thunderbird

also, these two addons let you remove the Archive button from the header toolbar:
https://addons.mozilla.org/en-US/thunderbird/addon/45601
https://addons.mozilla.org/en-US/thunderbird/addon/13564

good luck...

Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland

Reporter

Comment 15

•

14 years ago

Thanks for the pointers to the extensions... I already found/installed one  that lets me remap the key from 'A' to SHIFT-a, to minimize the chances of this happening, but doing things like this manually is a *lot* of work in a corporate environment...

Updated

•

14 years ago

URL: http://getsatisfaction.com/mozilla_me... → http://gsfn.us/t/nswy

Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland

Comment 16

•

14 years ago

(In reply to comment #5)
> could someone clarify whether this bug is just about disabling *automatic
> archiving*, or, also including manual archiving with the "a" key / Archive
> button?
> 
> because the bug's description reads quite differently depending which meaning
> you take.
> 
> i would agree that having automatic archiving newly enabled in TB3 by default,
> with no warning and no way to turn it off, is a Really Bad Idea. (particularly
> if it operates on folders other than the Inbox, but that i haven't figured out
> yet.) either way, the somewhat urgent tone of the original description makes
> sense. while manual archiving seems to me like a different case.
> 
> i found on this page:
> http://support.mozillamessaging.com/en-US/kb/Archived+messages
> the following statement:
> "The frequency of the automatic archiving is based on the
> mail.server.default.archive_granularity setting, which is set to "1" (monthly)
> by default. To disable automatic archiving, change the value to "0"."
> ...however on any other page i've found referencing that setting, it's
> described only as affecting whether your Archives folder has year/month
> subfolders or not.
> 
> so, is that statement true, and if so, does it solve this bug?


the statement is not true, there is NO automatic archiving, Standard8 aka Mark Banner corrected http://support.mozillamessaging.com/en-US/kb/Archived+messages

thanks for the heads up!

Bryan Clark (DevTools PM) [:clarkbw]

Reporter

Comment 17

•

14 years ago

Glad the support page is fixed, but we still need a way to disable Archiving completely.

Comment 18

•

14 years ago

(In reply to comment #17)
> Glad the support page is fixed, but we still need a way to disable Archiving
> completely.

This bug is a bit confusing.  bug 511741 is going to handle disabling the key combination for archiving.  If the header button customization gets finished then users will be able to remove the button giving users few options to archive an email.

I'm a bit unsure what is being requested beyond what is already happening.  AFAIK there aren't other options like this that disable Junk, Reply, Forward, or other functions.  With the ability to disable the key combo and the ability to remove the button; Archiving will be more removable than Junk currently is.

Reporter

Comment 19

•

14 years ago

Well, features like this absolutely *must* have a very simple, non-confusing boolean UI option, like:

[X] Disable Archiving for this account

so that those of us using TB in a corporate environment can disable Archiving by simply modifying this one pref in user.js, rather than having to manually massage the GUI for every users profile.

The TB devs really, really need to start thinking in terms of how something like this will impact corporate users. Meaning, always ask yourself "how can we jigger this option so that corporate admins will be able to control this feature using Group Policies?". Making it a simple user.js pref means I can still apply this option manually now, and making it controllable through GPO when they are supported will then be trivial.

That said, I see no reason why this simple boolean option couldn't simply be the UI method to: a) disable the keyboard shortcut *and*; b) completely *hide* the toolbar buttons - message header and main - so that the user wouldn't even be able to add the buttons to a toolbar if they tried. This would also be much more logical than having to have an FAQ somewhere that support people would always be having to refer people to telling the user:

"If you want to disable archiving, you need to:

1. Disable the Archive key shortcut, and

2. Remove the toolbar buttons from both of your toolbars (if they are present) and resist the urge to re-add them later.

and then telling us corporate users "Sorry, you'll just have to put up with this mess for now.

If you're going to fix this, fix it right, the first time.

Comment 20

•

14 years ago

I'm applying a couple of patches for each release, which can be done in a batch and include removal of the archive shortcut (and button, either by hacking the theme or adding it to the userChrome.css of the default profile). So, it's not convenient but would do as a workaround for the time being.

(In reply to comment #18)
> AFAIK there aren't other options like this that disable Junk, Reply, Forward,

Uhm, neither of those moves the message by default - not even the Junk button, which will just mark the message unless it has been configured otherwise. Thus, you provided (unintentionally) a good parallel, given that moving messages when marked as junk can be turned off as well in the account settings.

Reporter

Comment 21

•

14 years ago

(In reply to comment #20)
> I'm applying a couple of patches for each release, which can be done in a
> batch and include removal of the archive shortcut (and button, either by
> hacking the theme or adding it to the userChrome.css of the default profile).
> So, it's not convenient but would do as a workaround for the time being.

Cool - care to share? I'd also be intersted in the the userChrome hack to remove the buttons, since the boss may not agree to me patching the binary at install time?

;)

Comment 22

•

14 years ago

Attached patch Post-install patch for shortcut & button [TB 3.1.x] — Details — Splinter Review

You don't need to hack the binary, just XUL and CSS code. After installation, put this patch (I had the shortcut disabled already in my collection, but have added hiding the archive buttons for your version) into the chrome folder of the installation and run the following script there:


unzip messenger.jar content/messenger/mailWindowOverlay.xul
unzip classic.jar skin/classic/messenger/messageHeader.css \
                  skin/classic/messenger/multimessageview.css
patch -p0 < charles.patch
zip -0 messenger.jar content/messenger/mailWindowOverlay.xul
zip -0 classic.jar skin/classic/messenger/messageHeader.css \
                   skin/classic/messenger/multimessageview.css


which you've put before into a text file named, let's say, charles.sh - running it from command line (in Linux) or a Cygwin bash shell (Windows, make sure to install the zip and patch packages) should perform the necessary modifications. Obviously, don't have Thunderbird running at that time. Then, repackage the modified installation and deploy to your users. Since the original JAR files have been changed, automated partial updates will fail, thus you'll have to make a full install for each subsequent release and run the script again.

Bryan Clark (DevTools PM) [:clarkbw]

Reporter

Comment 23

•

14 years ago

Awesome... thanks!

Comment 24

•

14 years ago

(In reply to comment #20)
> I'm applying a couple of patches for each release, which can be done in a batch
> and include removal of the archive shortcut (and button, either by hacking the
> theme or adding it to the userChrome.css of the default profile). So, it's not
> convenient but would do as a workaround for the time being.

This is great!  It would be good to have a better way to connect with enterprises who want to share scripts and such.  Perhaps the knowledge base could link to something like this in the developer wiki?

I'm going to mark this as WONTFIX now because there are definitely ways for enterprises, as shown, who don't want this behavior to remove it completely.  bug 511741 is going to handle the first use experience for regular consumers so I don't think bug is necessary.

> (In reply to comment #18)
> > AFAIK there aren't other options like this that disable Junk, Reply, Forward,
> 
> Uhm, neither of those moves the message by default - not even the Junk button,
> which will just mark the message unless it has been configured otherwise. Thus,
> you provided (unintentionally) a good parallel, given that moving messages when
> marked as junk can be turned off as well in the account settings.

Yes, off topic, a couple things are wrong with that.  Mark as junk is an uncommon behavior.  Every major web mail client and desktop client moves junk to the junk folder by default.  We have a support problem with our default; it is incorrect, we just haven't changed it.  The options for Junk do not disable or turn off the Junk feature, it only alters it's behavior from 'mark as junk' to 'move to junk'.

Joey Connick

Comment 25

•

14 years ago

I'm happy to see this hasn't been marked as WONTFIX as yet.  It's nice that there's a kludge workaround but the core issue still remains: if archiving is activated inadvertently, it can cause serious dataloss and there is no undo available.  The fact that the workaround breaks automatic updating is also, I'm sure, a problem for people.

As for "Mark as Junk" being an "uncommon" behaviour, well... not everyone wants to archive their email, especially not in the way it's set up to be done by default now in Thunderbird.  So archiving can definitely be considered uncommon.

David :Bienvenu

Comment 26

•

14 years ago

Of course undo is available.

Bryan Clark (DevTools PM) [:clarkbw]

Comment 27

•

14 years ago

(In reply to comment #25)
Undo does work and with bug 511741 we'll be offering an "undo plus turn off the keyboard shortcut" aka disable dialog on first use of archiving.

> As for "Mark as Junk" being an "uncommon" behaviour, well... not everyone wants
> to archive their email, especially not in the way it's set up to be done by
> default now in Thunderbird.  So archiving can definitely be considered
> uncommon.

Right, the archive feature was designed with the idea that we would be able to extend the way archives are handled.  For instance bug 533815 will keep the folder structure and there are other ideas that we want to make it easier to implement.  The current archive is a one-size fits all but was made to be modified so it works for more people.  I don't think we'd want to disable it because it doesn't archive exactly as we want yet.  I'd really like to see it archive by people, groups of people, and mailing lists.  That's probably all after the 3.1 release.

Reporter

Comment 28

•

14 years ago

I emphatically agree with Joey... Bryan, *please* don't mark this as WONTFIX, this absolutely *needs* to be fixed.

Bug 511741 actually refers back to *this* bug to 'handle' the b) option to 'disable archiving completely', so referring to it as an excuse to WONTFIX this bug is unreasonable.

Bryan - some enterprises (maybe even a lot) will *absolutely* *insist* on a way to completely disable archiving, including eliminating the toolbar buttons and the Archive folder (if it were to inadvertently get created somehow).

This is a good example of what I mean when I keep saying, please, *please* start considering how *enterprise* admins think about these things. Having to manually apply a script/patch is absolutely, positively *not* a long term solution to this issue.

Having a simple, single pref that is easily toggled via Group Policies is what any admin will want and expect (once support for GPOs is achieved).

Mark Johnson

Comment 29

•

14 years ago

I never use or intend to use Archiving. I'd like to recover the screen real estate in the Folders Pane *and* eliminate issues with inadvertent touching of the related Archiving hot keys. I think complete disabling of Archiving is important and it should be an easy fix.

Rob Crowther

Comment 30

•

14 years ago

> Of course undo is available.

Please tell me how to do it then - I want the message back in the folder it came from with the same 'order received'.

boxmiks

Comment 31

•

14 years ago

I just spent a panicked hour and half recovering from an archive operation of 20k email that happened in concert with a **** load of indexing and several crashes. I love TB and appreciate all the hard work that has gone into making this great piece of software.  Pls, don't get enamored with your own ideas.  You almost certainly have not thought out all the ways ppl are using it.  Anything that has so much power for damage should be introduced with great caution and should never be released without a way to restore a previous state.  thanks.

Reporter

Comment 33

•

14 years ago

So, 3.1 is out and still no option to disable archiving.

Thanks for listening TB devs...

Comment 34

•

14 years ago

Considering enterprise deployments is very important, but fixing this particular design bug (yep, that's what it is. sorry) doesn't rely upon that important consideration. It just adds to the urgency. The entire user base, both those inside and outside of administered corporate environments, suffer the same confusion and risk to their established message storage folder structures caused by this implementation. 

It makes no sense that an accidental striking of the "a" key hauls whichever messages happen to be currently selected off to some new top level hierarchy with no user notification. Even with Undo available, if it happens by accident it's not unlikely that the user won't know to use it.

Regarding allowing opt-out at installation or update time, this only helps those users who know to watch out for this. For new users importing existing storage structures into their shiny new Thunderbird, if they have to opt-out of this then it's just a trap.

It is very, very nice that some participants have provided or pointed to solutions users may attempt to fix this themselves, but these solutions do not address the basic design flaw. 

Thanks very, very much for your work and for listening, developers. For valuable exposure to some end user pleadings on this issue, I encourage you to read the comments on one of the cases on this issue opened on getsatisfaction.com by following this link: http://gsfn.us/t/nswy

Comment 35

•

14 years ago

And thank YOU, Charles, for keeping on this.

Comment 36

•

14 years ago

Here's another discussion in which end users are searching for solutions to this design bug. It's very interesting (I say, even though I'm a participant):
http://gsfn.us/t/o8lf

Comment 37

•

14 years ago

(In reply to comment #34)
> It makes no sense that an accidental striking of the "a" key hauls whichever
> messages happen to be currently selected off to some new top level hierarchy
> with no user notification. Even with Undo available, if it happens by accident
> it's not unlikely that the user won't know to use it.

Is this something bug 511741 (notify on first use of feature; disable keyboard shortcut) will be able to fix? If so, it's not technically in scope for this bug, which is about implementing an option to completely disable not only the keyboard shortcut for this feature, but the entire feature itself.

Comment 38

•

14 years ago

Well, there's some overlap. One concerns the other. The reason for this bug is because of the behaviors described and addressed both here and in bug 511741. 

For example, if on first use notification the user has enough presence of mind to turn off the feature, from their perspective it'd gone, removed. Annoyance addressed. However, first use notifications are problematic, since the user may NOT realize the implications of the decision being presented, or even what it is. Remember, if this thing pops up on an accidental key "a" strike, they were probably in the midst of doing something else with the product; some normal user task. All the sudden we jerk them out of that and ask them to make a one-time-only configuration decision with no going back. Annoyance caused.