Closed Bug 505035 Opened 15 years ago Closed 15 years ago

Cannot change the column list of all folders at once

Categories

(Thunderbird :: Folder and Message Lists, defect)

Product:
Thunderbird
Component:
Folder and Message Lists
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-thunderbird3.1 beta2+, thunderbird3.1 beta2-fixed, blocking-thunderbird3.0 -, thunderbird3.0 wontfix)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 3.1b2
Tracking Flags:
Tracking Status
blocking-thunderbird3.1 --- beta2+
thunderbird3.1 --- beta2-fixed
blocking-thunderbird3.0 --- -
thunderbird3.0 --- wontfix

People

(Reporter: LpSolit, Assigned: asuth)

References

(Blocks 3 open bugs,
URL
)

Details

(Keywords: late-l10n, Whiteboard: [gs][gssolved])

Attachments

(1 file)

v1 column propagation stuff with unit tests
32.03 KB, patch
davida
: review+
asuth
: ui-review+
Details | Diff | Splinter Review
When upgrading from beta 2 to beta 3, my custom column list has been reset to the default one. I wanted to revert this, but I found no way to do it for all folders at once. I have to visit each folder one by one, and edit the column list. This is painful. There should be a way to edit them globally.
i ack this. there should be something like we know from windows explorer: a) Use this folder type as a template b) Also apply this template to all subfolders
OS: Linux → All
Hardware: x86 → All
Yes, this is a *terrible* annoyance. After upgrading to TB3 RC1, suddenly every folder's threadpane has defaulted to an order that I do not want (I use the Show In/Out extension, for example, and therefore do not want to see the "from "column). And indeed there is no way at all to change the default order, or to allow all folders to inherit the order from another folder. Going to every folder and manually changing the columns using the column picker is nightmarishly slow -- especially because the column picker menu disappears each time you check or uncheck a single item on it. In TB 2, I set a new default long ago, and every new and old folder inherited it. That, or something functionally equivalent, should be restored to TB 3.
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3?
I post here the comment in bug #519526 provided by stepand76 >Steps to Reproduce: >1. Select multiple folders >2. Use Column list chooser to add some columns >3. You will see that change has been applied only on the first selected folder
Blocks: gloda-ui-regressions
No, we're not going to block tb 3 on this.
Flags: blocking-thunderbird3? → blocking-thunderbird3-
I have also a lot of folder where it is annoying to set the columns for all. My suggest would be to add a entry to the columns menu. Something like "Set for all folder" at the bottom of this menu.
Maybe two entries would be best at the bottom of the menu: "set for all folders" and "set as default".
More accurately: "change all folders" and "set as default".
Is bug 510475 a duplicate of this?
(In reply to comment #5) > No, we're not going to block tb 3 on this. Does this mean you don't consider this important enough to fix asap? I have over 1,000 folders. :(
This is a *major* loss of function
On one hand, it's a nice feature to have individual columns settings for each folder. On the other hand, it's a real pain that you can no longer make changes for all folders at once. However, I've noticed that some changes like adding a column (for example, I like to display the Size/Lines of messages) got also applied to other folders (but not to all, for example not the sub-folders of "Sent" on any account, and also not any of the "Local Folders"). Strange thing is, I cannot reproduce this right now.
There appears to be an even deeper bug. 1) Select a folder 2) Choose Restore Defaults from Columns to Display 3) Remove or add a column 4) Choose Restore Defaults from Columns to Display ... and nothing changes. The added or removed column (which was obviously not the default) stays added or removed.
(In reply to comment #14) > There appears to be an even deeper bug. > [steps to reproduce] ... Neil, I recommend you file your observation as a separate bug - if no one has filed it yet.
(In reply to comment #14) > There appears to be an even deeper bug. > 1) Select a folder > 2) Choose Restore Defaults from Columns to Display > 3) Remove or add a column > 4) Choose Restore Defaults from Columns to Display > ... and nothing changes. The added or removed column (which was obviously not > the default) stays added or removed. We know: is bug #504989
Is this going to be added to 3.0.1. Seriously, this is a MAJOR bug. If TB3 wouldn't change columns for existing folders during the upgrade it would be a defect. Annoying, regress, but a defect. Since it does change existing folders it is a major bug. In fact if anyone would like to start changing my ca. 5000 folders I'll be happy to invite them to visit my job. Be warned I might change my mind on order of columns after you start ;P.
blocking-thunderbird3.0: --- → ?
Flags: blocking-thunderbird3.1?
This is a total deal breaker. Back to 2.0.0.23 for me.
I'm definitely sticking to TB2 until this is "fixed" too. I've got TB3 going for test purposes for another bug, https://bugzilla.mozilla.org/show_bug.cgi?id=536873, but even if that problem is found out, I can't switch until this bug is taken care of. I even did a little test with my TB3. I made a new folder, set the columns the way I want, then made a subfolder under it. Of course, the subfolder took on the defaul settings rather than it's parent settings. That's definitely wrong. An existing subfolder should take on it's parent folder settings automatically, and a new subfolder should definitely take on the parent settings when created. This "feature" to allow different settings is great, but anyone who prefers a different column arrangement will hate this feature the way it works now.
This is a deal breaker for me too. Back to 2.0.0.23, immediately after I ran into this bug (which was immediately as well). My actions: 1. I created a custom column layout in TB 2.0.0.23. 2. I "upgraded" to TB 3.0. 3. I discovered the bug. 4. I went back to TB 2.0.0.23. My observation: After step 4, my custom column layout was back in place! Obviously, the installation of TB 3.0 did *not* kill my layout - TB 3.0 just ignored the available layout information. Anyhow, I stick to 2.0.0.23 until this bug is fixed.
Andrew, we should talk about how to deal with this when you get a chance.
blocking-thunderbird3.0: ? → needed
It is interesting how a quite good feature can be discredited by a customization support absence (meaning if something is set/works do not reset/change it)... Non-brave ones stop reading now! Column headings settings for particular folders seem to be placed in particular .msf files in your profile. So column headings can be changed as follows: 1. In TB3 set column headings for one of your folders. 2. Quit TB3. 3. In your profile find the folder's .msf file, edit it and copy the only string ={"..."}} to the clipboard. 4. Then in all .msf files replace all the strings ={"..."}} by the clipboard copy. It is not a solution but it is better than nothing (or setting all column headings manually). I have Windows XP SP2 and Thunderbird/3.0 and it works for me (no side-effects encountered so far) but try it on your own risk.
URL: http://gsfn.us/t/n36m
Whiteboard: [gs]
One possibility: at the bottom of the "choose the headings you want" list is "Restore Defaults". Why not add another option called "Set as Default" that sets the current layout to be the default. Maybe with a dialog box asking "Would you like to set all folders to use this layout? [Yes] [No] [Cancel]". This may not be the ideal solution, but it may also be good enough to satisfy the majority of people.
The dialog box that you mention is crucial, or alternatively a second button "Change all folders". What is needed is two distinct abilities: (1) setting a default that newly created folders will reflect, and (2) changing existing folders without having to open them one by one.
Why isn't there something in 'Preferences' to change the 'Global Column Settings' which you could then apply to 'All Folders' or a selection list which you could add/remove folders in bulk. Then for the 'Columns' menu in each individual folder you could customise and have 'Reset to Global' and 'Reset to Default'.
And now, a terrible annoyance that highlights like nothing else the need for a way to set the columns for all folders. After manually resetting the columns on all 400+ of my folders a month or two ago, I just accepted the update to Thunderbird 3.0.1 -- and every last one of them got reset to Thunderbird's idea of a default, as an unannounced by-product of this update. I am beyond angry!
(In reply to comment #27) > And now, a terrible annoyance that highlights like nothing else the need for a > way to set the columns for all folders. After manually resetting the columns > on all 400+ of my folders a month or two ago, I just accepted the update to > Thunderbird 3.0.1 -- and every last one of them got reset to Thunderbird's idea > of a default, as an unannounced by-product of this update. I'm sorry to hear you lost your customizations. While we are working to resolve this bug, I'll re-iterate the previously mentioned workaround that the settings for most folders are inherited from the Inbox, so try and make sure your inbox is set the way you want your folders set. As to the cause, are you still using Thunderbird as you described on https://bugzilla.mozilla.org/show_bug.cgi?id=81141#c26 ? That is a much more likely explanation for the problem than the upgrade to 3.0.1. The meta-information about the columns is stored in the .msf. If they are getting blown away, those preferences are going to go with them. We have code that tries very hard to propagate the values in event of invalidation of the msf, so as long as the .msf still exists, it should be fine.
> I'm sorry to hear you lost your customizations. While we are working to > resolve this bug, I'll re-iterate the previously mentioned workaround that the > settings for most folders are inherited from the Inbox, so try and make sure > your inbox is set the way you want your folders set. > Have set the inbox with the wanted columns & other folders within the inbox and below it do not match - kept mail 120 folders, sent, junk trash, etc. This is a pain and I'm not about to go through correcting each and every folder just to have it regress with the next update -- Guess I also should have remained with 2.x until 3 was more thoroughly debugged, but it's too late now and am stuck with what the programmers think is best for me. Perhaps another browser will do the job properly such as opera, safari, or chrome?
I'll add my voice to the chorus... I'd like: 1. the ability to 'Set as default view', for new folders, 2. the ability to 'Apply this view to all folder for this account', and 3. the ability to 'Apply this view to all folders for all accounts'. It would be nice if TB could be smart enough to swap the 'Recipient' and 'From' columns in the 'Sent' folders by itself, but that's not that big a deal to change those individually either...
(In reply to comment #28) > > I'm sorry to hear you lost your customizations. While we are working to > resolve this bug, I'll re-iterate the previously mentioned workaround that the > settings for most folders are inherited from the Inbox, so try and make sure > your inbox is set the way you want your folders set. > I just went to my local folders and created a folder called Inbox. I set the columns I wanted in that empty folder and guess what? The columns settings were applied to all my 100's of local folders. So I guess that means the easiest workaround it just to set the columns for the Inbox folder of each your accounts, which for me is only 3 or 4 folders, rather than 100's or 1000's. Still would be nice to fix, but I can live with this. I hope ongoing updates don't undo it every time. David B
Not sure why/how yours did that, because mine sure doesn't act that way. WinXP Pro sp3, fully patched, TB 3.0.1. Are yours POP or IMAP accounts?
(In reply to comment #32) > I just went to my local folders and created a folder called Inbox. "Local folders" != IMAP folders
(In reply to comment #31) > I'll add my voice to the chorus... > > I'd like: > > 1. the ability to 'Set as default view', for new folders, > > 2. the ability to 'Apply this view to all folder for this account', and > > 3. the ability to 'Apply this view to all folders for all accounts'. i'd second that. does not need to be via the column header context menu thou.
Of course, it goes without saying that 'Sent' folders should retain their default behavior of subbing the 'Recipient' column for the 'Sender' column automatically...
(In reply to comment #33) > Not sure why/how yours did that, because mine sure doesn't act that way. > > WinXP Pro sp3, fully patched, TB 3.0.1. > > Are yours POP or IMAP accounts? My yahoo account with many folders is a POP account. Like the other guy said, my local folders are IMAP (but I don't really know for sure) Setting only the inbox columns worked for both. Maybe setting the columns and then minimizing and re-opening the accounts made it take effect? I'm not sure but it seems it did not take effect immediately. I just tried removing the size col and I did NOT see it take effect in other folders, even though I went so far as to close and re-open TB3. So I guess I'm not sure exactly how it happened, but all my folders now have a size col and I did it by modifying the Inbox folder. David B
(In reply to comment #37) > My yahoo account with many folders is a POP account. > > Like the other guy said, my local folders are IMAP (but I don't > really know for sure) Eh? Local folders are - well, local... but certainly not IMAP.
(Probably the above inbox trick works if you have deleted your local cache, or if its the first time you visit a folder??) Here in a small company, we have lots of nested folders in the "public folders" hierarchy (which we all share), and we also use the "show in/out" extension (which includes a column that automatically switches to display from/to addr). We really need the ability to create a column setting that will also be applied to any NEWly created (by someone else!) subfolders of a certain folder. Couldnt it be a property of each folder whether to inherit the column settings from its parent? The default for all new folders would obviously be "true", but would change to "false" as soon I customize it. "Set to default" would restore the "true". Inbox and other "special" folders would instead "inherit" some special fixed defaults. (And (dreaming) it would be perfect if this can be set via some lines in prefs.js or some other simple file so that I can roll this out for all my users. But ok, if inheritance works, then I can cope to do it once manually.)
(I can confirm that newly created (IMAP) folders seem to inherit from Inbox.)
Given that this is a regression and it seems to have caused a fair amount of aggravation, I think it does need to block 3.1. Perhaps asuth or sid0 would be interested in taking a run at it?
blocking-thunderbird3.1: --- → needed
Flags: blocking-thunderbird3.1?
Keywords: regression
(In reply to comment #42) > Given that this is a regression and it seems to have caused a fair amount of > aggravation, I think it does need to block 3.1. Perhaps asuth or sid0 would be > interested in taking a run at it? What specifically are you claiming is the regression? The inability to reset to re-inherit from the default folder? The inability of changes in one folder to reliably affect other folders? If those are they, I think we can probably address this without too much work by: 1) Making the reset option that exists but basically does nothing force a re-inherit. In the inbox this would reset it to the default. 2) Add a new menu option in that same drop-down that says "Apply to other folders in this account." Because actually doing that synchronously could lock up the UI, we would address this by introducing a generation number associated with the persisted columns in the inbox. Each time a folder is displayed we check its generation number against the inbox. If the inbox is more recent, we re-inherit. When someone hits "apply to other folders" in the inbox, we just bump the generation. When someone hits it in other folders, we clobber the settings in the inbox and bump the generation. In order to avoid pathological situations where people's msf files get blown away and generations become inconsistent, bumping the generation means storing a value based on the current timestamp (perhaps decimated to the level of seconds). While I'm in there I'll revisit the cases where we currently do not inherit and consider relaxing the constraints or implementing a quick stopgap measure. For example, newsgroups can probably just abuse a preference given the lack of an inbox.
Assignee: nobody → bugmail
Status: NEW → ASSIGNED
Sorry to interrupt (as an admin speaking for my users) - I highly welcome this as a first step, but if possible I would prefer not to be forced to inherit from inbox. We use many shared folders that should have different columns than the inbox. Isnt it possible to have an "Apply to all subfolders" option ? (Perhaps using a similar mechanism, but inheriting from the respective parent folder (or inbox, if none)?)
(In reply to comment #44) > Isnt it possible to have an "Apply to all subfolders" option ? (Perhaps using a > similar mechanism, but inheriting from the respective parent folder (or inbox, > if none)?) There are performance reasons to only inherit from Inboxes. Namely, their .msf files are always loaded so there is no added cost in accessing or manipulating their properties. (We have a folder cache but it's currently not extensible so it's not entirely trivial to address the problem.) I had originally considered doing a more hierarchical inheritance but assumed that (apart from the inbox), only leaf folders would have messages in them. For example if you have "Archives/2009/June", I would expect only "June" to have messages in it, making inheriting from 2009 or Archives more likely to be troublesome than helpful. I'd be interested if this is not true in your case.
I see. Also in our case, its mostly the leaf folders that will have messages in them, but there are exceptions. In the public folders area (IMAP), we have a folder like "projects" (and probably later also projects-archive), and there resides a subfolder (or a subtree) for each project. Those folders contain both sent and received messages, so its obvious that we want to use customized columns. So my idea was that the users can set up the columns in the "projects" folder, and all subfolders that might be created later will get these settings. So it would also be a nice solution if I could specify a single folder to inherit from, if that makes it easier. We also use virtual folders inside the project folders - I dont know how these would behave?
(In reply to comment #45) > There are performance reasons to only inherit from Inboxes. Namely, their .msf > files are always loaded so there is no added cost in accessing or manipulating > their properties. (We have a folder cache but it's currently not extensible so > it's not entirely trivial to address the problem.) Any property you get/set on a folder using Get/SetStringProperty will get put in the folder cache, and can be read from the folder cache. Setting the property will open the db, but getting the property does not have to open the db.
(In reply to comment #43) > If those are they, I think we can probably address this without too much work > by: > > 1) Making the reset option that exists but basically does nothing force a > re-inherit. In the inbox this would reset it to the default. > > 2) Add a new menu option in that same drop-down that says "Apply to other > folders in this account." Because actually doing that synchronously could lock > up the UI, we would address this by introducing a generation number associated > with the persisted columns in the inbox. Each time a folder is displayed we > check its generation number against the inbox. If the inbox is more recent, we > re-inherit. Option 2 certainly seems a lot more user friendly, option 1 just isn't discoverable.
(In reply to comment #28) > The meta-information about the columns is stored in the .msf. If they are > getting blown away, those preferences are going to go with them. We have > code that tries very hard to propagate the values in event of invalidation > of the msf, so as long as the .msf still exists, it should be fine. So, what are the chances of bug 543963 (I just updated the Subject to be more generic/appropriate) ever being implemented? Deleting the .msf files is a not all that uncommon thing that people do when dealing with minor corruption issues, and having to redo your view customizations every time you do this will be very inconvenient. Not as inconvenient as if/when this bug is addressed, admittedly, but still annoying.
(In reply to comment #49) > So, what are the chances of bug 543963 (I just updated the Subject to be more > generic/appropriate) ever being implemented? I have commented on the bug. > Deleting the .msf files is a not all that uncommon thing that people do when > dealing with minor corruption issues, and having to redo your view > customizations every time you do this will be very inconvenient. The incidence of corrupt .msf files should be at least an order of magnitude lower than it used to be at this point. Additionally, people should not delete them, but instead use the "rebuild index" button from the folder properties dialog. The "rebuild index" button *will* propagate the information, avoiding losing it (thanks again rkent!)
(In reply to comment #48) Option 2 is far better if user needs to change a large number of folders (true in my case). Still, you probably will make an exception for "sent"? (Some people might even have subfolders there...) (I was thinking about inheriting the settings from a virtual ("template") folder residing in templates, rather than inheriting from inbox. Though, this is sophisticated and does not seem to solve a big problem.) Andrew, in comment #45, do you mean _technically_ troublesome? From a users perspective, I would not see a big problem in inheriting over hierarchies of "empty" folders. The only thing is that one might not have messages in the (topmost) folder to adjust the column widths on "live" data - was this what you meant?)
(In reply to comment #47) > (In reply to comment #45) > > > There are performance reasons to only inherit from Inboxes. Namely, their .msf > > files are always loaded so there is no added cost in accessing or manipulating > > their properties. (We have a folder cache but it's currently not extensible so > > it's not entirely trivial to address the problem.) > > Any property you get/set on a folder using Get/SetStringProperty will get put > in the folder cache, and can be read from the folder cache. Setting the > property will open the db, but getting the property does not have to open the > db. I phrased that poorly, apologies. If the folder cache gets cleared, there is no logic to re-walk all existing string properties and propagate them into the folder cache when re-initializing the element, at least as far as I can see. While I don't expect the cache to be blown away as a part of regular operation, there may be even more advice out there for people to randomly delete panacea.dat than randomly deleting their .msf files. Given that, I would want to fix this limitation prior to relying on the folder cache for non-core properties. I think that would require mork enumeration code which I definitively categorize as non-trivial, perhaps unfairly :).
(In reply to comment #51) > (In reply to comment #48) > Option 2 is far better if user needs to change a large number of folders (true > in my case). > Still, you probably will make an exception for "sent"? (Some people might even > have subfolders there...) Sorry, I meant we would do both things, not just one of them. I would still exempt sent. > (I was thinking about inheriting the settings from a virtual ("template") > folder residing in templates, rather than inheriting from inbox. Though, this > is sophisticated and does not seem to solve a big problem.) I would also still exempt virtual folders. Since these are individually created by the user, there is less concern about them having to take two weeks of vacation to manually change all their column settings. (Smart folders are the exception but since they are a finite set of fused folders, they are likewise not a concern.) > Andrew, in comment #45, do you mean _technically_ troublesome? From a users > perspective, I would not see a big problem in inheriting over hierarchies of > "empty" folders. The only thing is that one might not have messages in the > (topmost) folder to adjust the column widths on "live" data - was this what you > meant?) My concern is that the empty folders would never have any value, but they could cause the opposite of what the user desires to happen, at least in a simple implementation. For example, if the user clicks in the "Archives" folder before they have customized the Inbox, the Archives folder now has the settings they don't want. Then every time they go into a leaf folder in Archives, we inherit from Archives instead of Inbox and the user is unhappy. This could be mitigated by skipping folders without messages in them, but that also could introduce inconsistent behavior if you start to have folders where users as an inbox-zero type thing manually re-file the contents of a folder to emptiness. The bottom line is that I could spend weeks creating a well-tested bulletproof super-genius column inheritance implementation, but our extremely limited engineering resources are better spent on attempting to address the problem from other angles. Enabling easier extensions so you can get exactly the logic you want, making it easier to create UIs that let you change the column settings exactly as you want to from a big display of all folders instead of folder-by-folder, improving the display of messages so careful gardening of folder columns is not even an issue, etc. Which is to say, the plan is still to do #1 and #2 as per the above for now. I will keep your use-case in mind for easy extension enablement.
(In reply to comment #53) > (In reply to comment #51) > > (In reply to comment #48) > Sorry, I meant we would do both things, not just one of them. Ah - ok, great! :-) > I would still exempt sent. > > > (I was thinking about inheriting the settings from a virtual ("template") > > folder residing in templates, rather than inheriting from inbox. Though, this > > is sophisticated and does not seem to solve a big problem.) > > I would also still exempt virtual folders. Since these are individually > created by the user, there is less concern about them having to take two weeks > of vacation to manually change all their column settings. (Smart folders are > the exception but since they are a finite set of fused folders, they are > likewise not a concern.) Personally I woud not see a reason why to exclude virtual folders (at least as long as they do not live below "sent") - but I could live with that as long as option #1 still works for virtual folders. > > Andrew, in comment #45, do you mean _technically_ troublesome? From a users > > perspective, I would not see a big problem in inheriting over hierarchies of > > "empty" folders. The only thing is that one might not have messages in the > > (topmost) folder to adjust the column widths on "live" data - was this what you > > meant?) > > My concern is that the empty folders would never have any value, but they could > cause the opposite of what the user desires to happen, at least in a simple > implementation. For example, if the user clicks in the "Archives" folder > before they have customized the Inbox, the Archives folder now has the settings > they don't want. Then every time they go into a leaf folder in Archives, we > inherit from Archives instead of Inbox and the user is unhappy. This could be > mitigated by skipping folders without messages in them, but that also could > introduce inconsistent behavior if you start to have folders where users as an > inbox-zero type thing manually re-file the contents of a folder to emptiness. Ok I did not know that empty folders have no properties. An alternative to auto-inheritance could be a menu option like "apply to all subfolders" - in the case you mentioned, the user would probably discover this option in some leaf folder, and would then realize how he/she can actually use this (i.e. adjusting the columns for "archive" and then choosing "apply to all subfolders" there). Perhaps this would technically be easier since the "source" folder is already opened, but (if I understand correctly) might require to store sth like an "inherit from" property with each folder along with the "generation" number... I admit this were quite cumbersome. Btw, I recently read a suggestion of someone stating that he had tried selecting multiple folders (in the tree pane) and then adjusted the columns, and that he would have expected that his changes would be applied to all the folders he had selected. A clever idea, I believe. But in general - I understand that just doing options #1 and #2 for now is a good pragmatic solution - and I think I can live with it. THANKS for your patience! :-)
(In reply to comment #31) > 1. the ability to 'Set as default view', for new folders, > 2. the ability to 'Apply this view to all folder for this account', and > 3. the ability to 'Apply this view to all folders for all accounts'. I'd prefer having following commands in the context menu: 'Copy this folder settings' 'Paste settings to this folder' 'Paste settings to this and all sub folders' New folder default settings are inherited from the parent folder only (no inbox or any other folder or template). Using these commands you can copy quite fast folder settings to all folders you want.
(In reply to comment #52) > > I phrased that poorly, apologies. If the folder cache gets cleared, there is > no logic to re-walk all existing string properties and propagate them into the > folder cache when re-initializing the element, at least as far as I can see. Ah, I see. I think nsMsgDBFolder::GetStringProperty should be changed to propagate missing properties from the db into the folder cache (i.e., if there's a cache miss, after we've read the property from the db, put it in the cache, so we don't miss again). As a side note, if you delete your panacea.dat file, we will re-open every single db in your profile on folder discovery, and re-populate the folder cache. But these custom string properties don't get propagated in that re-population, which could probably be fixed, though lazy propagation wouldn't be the end of the world.
> assumed that (apart from the inbox), only leaf folders would have messages Such assumption is wrong in general. As an example, I could offer usual structures of public project archive servers and/or usenet news servers. People obviously does not tend/want to keep messages in the leaves only. On the contrary, (perhaps aside of "archives" folders,) messages seem to be distributed in almost all accessible folders.
Until some solution is developed that could offer reasonable inheritance of columns and/or management of columns and their "defaults", is it possible to implement an option that would revert to previous behaviour? Based on many reactions in forums, this feature makes noticeable amount of users revert to previous versions of Thunderbird. The usual reason is, by the way, "I have dozens of folders and I can't modify them all at once".
I would definitely like to see this bug fixed. I am trying to convert from Eudora 7 and not being able to change all the mailbox column displays at once is making this conversion difficult. I have hundreds of mailboxes from the past 14+ years. This is not only annoying, it is an accessibility issue. Too many default columns means there's little room for the items I need to view as I have the font set a bit larger than normal when using Eudora 8. I also don't want to see individual mailbox column settings go away as many people find this usful.
blocking-thunderbird3.1: needed → beta2+
(In reply to comment #22) WORK AROUND to propagate the column list pane layout. Following on this idea (the columnn list pane are described in .msf) I customized the Inbox list pane lay out in TB3 then quit TB3 then delete all the *.msf in inbox subfolder I had TB3 recreates the msf and appears to take the inbox ( or top folder default) I try that on user mailbox with subfolder and it took the inbox default (still takes sometime to reconstruct the msf but a lot safer than editing them) Please confirm if this is a valid work around ? > It is interesting how a quite good feature can be discredited by a > customization support absence (meaning if something is set/works do not > reset/change it)... > > Non-brave ones stop reading now! > > Column headings settings for particular folders seem to be placed in particular > .msf files in your profile. So column headings can be changed as follows: > > 1. In TB3 set column headings for one of your folders. > 2. Quit TB3. > 3. In your profile find the folder's .msf file, edit it and copy the only > string ={"..."}} to the clipboard. > 4. Then in all .msf files replace all the strings ={"..."}} by the clipboard > copy. > > It is not a solution but it is better than nothing (or setting all column > headings manually). I have Windows XP SP2 and Thunderbird/3.0 and it works for > me (no side-effects encountered so far) but try it on your own risk.
This is the only major problem I have with TB3 but it is HUGE. I NEED for EVERY folder to have different columns than the default. Hundreds of folders. It is absurd to change every one of them, and absurd that this feature was taken away.
We're resetting the blocking flag for 3.1 on this bug and instead setting the wanted-thunderbird+ flag. We have too many blocking-3.1 bugs, to the point where it doesn't mean much, and managing the list is making it hard to actually work on closing bugs, which helps no one. Thunderbird 3.1's primary purpose is to allow us to offer a prompted major update to Thunderbird 2 users, to ensure their continued ability to safely use Thunderbird. Thunderbird 2 is built on an outdated version of Gecko, and our long-term ability to maintain the users' safety for Thunderbird 2 users is limited. If you think this bug meets the requirements below, please renominate with a detailed explanation of how it meets the following two criteria, and we will reconsider. To qualify, this bug must either: a) make the upgrade experience from TB2 very painful for a large number of users or b) be a new, reproducible, severe quality issue (eg dataloss, frequent crashes) Just because this bug doesn't block TB3.1 doesn't mean it can't or won't make the release. Once they're done with their blockers (if any), we encourage developers to keep working on non-blocking bugs, and to try to land them as early in the cycle as possible, as non-blocking bugs will become increasingly difficult to land in the later stages of the cycle.
blocking-thunderbird3.1: beta2+ → ---
Flags: wanted-thunderbird+
(In reply to comment #63) > a) make the upgrade experience from TB2 very painful for a large number of > users I think this is obvious here. See all the comments above.
blocking-thunderbird3.1: --- → ?
Yes, exactly, what he said: (In reply to comment #63) > a) make the upgrade experience from TB2 very painful for a large number of > users I think this is obvious here. See all the comments above. Specifically, in my case (and others I see) it's ridiculous to have to manually change thousands of folders instead of just changing the default. Very painful DOWNgrade experience, enormous bug.
Does this mean 3.1 will take care of this bug and the slow loading messages (536873) one? If so, once 3.1 is ready, I'll give it a try.
Flags: blocking-thunderbird3-
This bug makes it impossible for many of us to even consider the upgrade. Until it is fixed there is no way I am willing to upgrade as I am not willing spend the time required to change all my folders.
dmose, this does seem to be a pretty significant pain point for people upgrading, or considering upgrading.
I strongly agree with the recent comments about the pain level caused by this problem.
If I'd been aware of this bug I would not have upgraded. I am on the brink of downgrading.
This bug is a prime example for > a) make the upgrade experience from TB2 very painful for a large number of users and it is also a "new, reproducible, severe quality issue (eg dataloss)" = in our case the folder configuration settings are lost :( Out IT services several users which reported that as a bug.
i agree that it currently *is* painful! do we need to be reminded that for every single person voicing his opinion in here, there are hundreds of others that exactly experience the same problem but do not inform the vendor and simply dispraise it in their community/clique instead? maybe this bug can be solved pragmatically - landing a proposal in a nightly build and see how the testers react?
Peoples, We all agree that it's painful. I am going to fix this, that's why the bug is assigned to me. I've been off fixing much more painful issues that are harder to resolve which is why this bug hasn't been fixed yet. I would appreciate your cooperation in keeping it easy for me to find the useful information in this bug by not reiterating the already understood frustration resulting from this bug. Your passion for Thunderbird is appreciated but it's not manifesting in a constructive and useful fashion.
(In reply to comment #73) There are some propositions: (In reply to comment #1) (In reply to comment #8) (In reply to comment #26) (In reply to comment #31) (In reply to comment #43) (In reply to comment #58) I will try to get some summary of the discussion (maybe not complete but useful at least) with some my propositions. I see two major needs here: 1. To define the default (universal or account wide or both) that new folders will generally use. It could implicitly be the parent folder (or the INBOX if none) or just the INBOX, or it could explicitly be any other folder with the 'Use as Default' setting set. 2. Mass change - the mechanism how to apply some settings to more than one folder at once. The way could be to select a set of folders and apply the default to them (right-clicking and choosing the 'Reset to / Apply Default' sub-menu option). Or at least to be able to use the 'Apply to All Folders' or 'Apply to All Folders in This Account' options while viewing any folder. Or something like that. From the user's point of view I do not see any reason why to do any exceptions and remove any folder from this mechanism (Sent, virtual one, one without messages, one with children). I think this shall be applicable to all folders. And last but not least - what to set applying this column setting mechanism: the list of columns (yes) and their order, width and (maybe) sorting should also be propagated. This issue wasn't discussed much yet but it should be. Upgrading from TB 2.x the column setting should be kept somehow. I hope this helps.
(In reply to comment #73) > Peoples, > > We all agree that it's painful. I am going to fix this, that's why the bug is > assigned to me. I've been off fixing much more painful issues that are harder > to resolve which is why this bug hasn't been fixed yet. Hi Andrew, Your work on this (and other bugs) is much appreciated. Everyone is just reacting to comment 63, ie, resetting the blocking flag. Reading that post clearly requests the exact input everyone is giving. And fwiw, I agree, this was painful, but it also appears that *something* has been fixed, because 3.0.3 seems to be better. To test: 1. Delete the local offline store for an account with custom user created folders. 2. Start changing the folder column view, beginning with the Inbox and working your way down the 'special folders'... 3. Note that once you have gotten to the user created folders, they all seem to have now inherited the changes made to the Inbox/special folders... So... what changed? Was this something you did? I still would very much like a way to do this in one place (ie, set a default view, then make individual changes to folders if desired), but it is at least livable now, even if you have hundreds of folders. So - anyone reading this... test this for yourself. Are you saying it doesn't work you as it is working for me?
The least painful workaround is in comment 60 ( based on comment 22). the Column specification for the list-pane are stored in the *.msf file in TB3. Delete the *.msf file (after shut-in down TB3) and TB3 takes the default from upper folder or inbox when it reconstructs the *.msf files. (it takes a while to reconstruct .msf but it works without problem. Many Thanks to Andrew for taking on the fix.
The least painful workaround is in comment 60 ( based on comment 22). the Column specification for the list-pane are stored in the *.msf file in TB3. Delete the *.msf file (after shut-in down TB3) and TB3 takes the default from upper folder or inbox when it reconstructs the *.msf files. (it takes a while to reconstruct .msf but it works without problem. Many Thanks to Andrew for taking on the fix.
My way doesn't take very long either - how long does it take change just 6 folders? Also, it doesn't take a long time to reconstruct the .msf files for large mailboxes, and probably is quicker too (no restart or manual deletion involved)... But either way will work...
(In reply to comment #63) I'll vote for; a) make the upgrade experience from TB2 very painful for a large number of users Very painful in that the current "default" columns waste too much space & I can't see what I need to see. I use larger fonts due to my poor eyesight so this is also an accessibility issue. Way too many mailboxes to change. Even trying to delet all the .msf files will be a chore.
Please do not delete your .msf files or advocate to other people that they delete their .msf files. While we try to avoid putting data in there that we cannot reconstruct, there are cases where deleting the .msf files will cause data loss. And in the cases where there is no data-loss, users may not enjoy having to re-download all of their IMAP messages to their offline stores (where relevant) or having the global database indexer want to re-index everything.
Well taken avoid deleting *.msf : I only did that on POP account and notIMAP Can you elaborate on cases where deleting .msf will cause data loss? or cases where it should be safe to do so.
OK, the pain here is clearly more severe than I had realized. After discussion with Bryan, adding this back to the blocker list. Leaving aimed at b2, as it's somewhat feature-y, so would be good to land before the feature-freeze. That said, we'd slip this to rc1 if we had to, because in many ways it's really just a bug fix.
blocking-thunderbird3.1: ? → beta2+
Whiteboard: [gs] → [gs] [would slip to rc1]
(In reply to comment #81) > Can you elaborate on cases where deleting .msf will cause data loss? > or cases where it should be safe to do so. See bug 533337 for example. Depending on your IMAP servers capabilities, tags may be stored in the *.msf file only.
Whiteboard: [gs] [would slip to rc1] → [gs]
Whiteboard: [gs] → [gs][queued up for after the message filter bar gets feature complete]
Could the widespread interest in this bug be seen as a result of the default columns needing improvement? (e.g., add "Size", remove "Read" columns)
Maybe it would prevent some percentage of users from noticing this bug. :-) Though, there are quite some reasons why you might want to customize your colums: If you use another spam filter, or for archive folders, you probably want to hide the spam column. Perhaps you dont use the thread column and want hide it. Or, for instance, everyone who uses the showinout AddOn will feel the need to add two custom columns to many of their folders, and hide a default column.
There are as many reasons and ways to customize as there are columns. Every unneeded column is a distraction that also takes up space from important ones. i.e. Some of us may need a very wide "Tag" column but don't need most of the other columns at all. I don't think any two users should be tied to some standard when in TB2 (and pretty much any old email client) it was easy to customize according to need.
Shredder just broke the Show InOut extension. That means I see, instead of the email author, just "1 KB" And, worse, I can't fix it! (Due to this bug.) I have 100+ folders, and I can't change all of them manually. Leaving me with a broken Thunderbird. Adding dogfood.
Keywords: dogfood
(In reply to comment #87) (Sorry for getting off-topic. - Ben, you mean your columns are now messed up because Show InOut was once not working and thus the columns have been reset? I am just asking because for me, I am very glad that with 3.0.1 - 3.0.3 Show InOut is working. I only had trouble with it on one PC where the admin had an older version installed than the users. Resolved this by having the admin re-install the addon.)
(In reply to comment #22) > > Non-brave ones stop reading now! > > Column headings settings for particular folders seem to be placed in particular > .msf files in your profile. So column headings can be changed as follows: > > 1. In TB3 set column headings for one of your folders. > 2. Quit TB3. > 3. In your profile find the folder's .msf file, edit it and copy the only > string ={"..."}} to the clipboard. > 4. Then in all .msf files replace all the strings ={"..."}} by the clipboard > copy. > I didn't want as much to propagate one column setting across all my folders (though that'd be nice) as much as I was losing the column settings for my main Inbox all the time (when switching back to it after viewing some other folder, or after TB shutdown and startup). So, I can't say I fixed my problem yet long-term but it seems to be working now and I at least have more info to share about the steps in (comment #22) : 1. When you go to the .msf file, it's true that you're looking for the only string that starts with ={ so just search for ={ and you'll find it. 2. I found that replacing ALL the instances of ={ ...whatever... } with the string ={"subjectCol":{"visible":true}} is a sure way to reset the column view. 3. Do that then startup TB and make your new column view settings (choose which ones are visible, the order, and width) then shutdown TB. 4. Start TB again, change folders, etc, and the new column view settings for that folder that was messed-up before are now staying the same.
> I was losing the column settings for my main Inbox all the time This is a different bug.
Whiteboard: [gs][queued up for after the message filter bar gets feature complete] → [has patch, needs mozmill tests][gs]
asuth, you put [has patch] in the status whiteboard, but I see no trace of it. Where can I find it?
It would be most intuitive if there were an option for setting current columns as default columns for all other folders. Thus the user could set the default as he sees fit, and override it for specific folders.
I see that Jim in Comment 24 mentioned exactly what I was thinking. That is the most intuitive solution.
(In reply to comment #0) > When upgrading from beta 2 to beta 3, my custom column list has been reset to > the default one. I wanted to revert this, but I found no way to do it for all > folders at once. I have to visit each folder one by one, and edit the column > list. This is painful. There should be a way to edit them globally. Highly annoying indeed. I register a bugzilla account only so that I can add my vote.
This patch didn't make it for the string freeze. Adding late-l10n keyword and informing Thunderbird localizers. Developers should be aware of the process that we have for this, which is detailed at https://developer.mozilla.org/en/Thunderbird_Localization#Breaking_the_string_freeze
Keywords: late-l10n
Whiteboard: [has patch, needs mozmill tests][gs] → [has patch, needs mozmill tests, eta Friday][gs]
Comment on attachment 441237 [details] [diff] [review] v1 column propagation stuff with unit tests As discussed on IRC, would be good to have the version that can apply to whole accounts, not just parent folders. I couldn't find anything scary, but I'd like to understand the delays (see below). on file: mail/base/content/threadPaneColumnPicker.xml line 20 > - Portions created by the Initial Developer are Copyright (C) 2009 2010 please on file: mail/base/content/threadPaneColumnPicker.xml line 44 > <bindings id="glodaFacetBindings" > xmlns="http://www.mozilla.org/xbl" > xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" > xmlns:html="http://www.w3.org/1999/xhtml" > xmlns:xbl="http://www.mozilla.org/xbl" > xmlns:svg="http://www.w3.org/2000/svg"> That looks wrong. It's not glodaFacetBindings, and I doubt you need svg in this file. on file: mail/base/content/threadPaneColumnPicker.xml line 103 > // We no longer cache the picker content, remove the old content. the "no longer cache" comment feels out of place, I don't know what its context is. Is it referring to a previous version of the code? If so, it doesn't seem to belong here. on file: mail/base/content/threadPaneColumnPicker.xml line 107 > var refChild = aPopup.firstChild; i can tell this is cut & paste due to the vars everywhere =). on file: mail/base/modules/MailUtils.js line 335 > INTER_FOLDER_PROCESSING_DELAY_MS: 100, I'm a bit puzzled about the need for the delay, and a bit worried about using 100msec. If I have 100 folders, that's 10 seconds total elapsed time? Feels huge. I'll try to understand the need for any real delay. Also, you don't actually seem to be setting this in 0 in unit tests, AFAICT. on file: mail/base/modules/MailUtils.js line 344 > * (panacea.dat) as well as the folder itself. Hopefully you want this; if > * you do not, keep in mind that the only way to avoid that is to retrieve It's not clear to me why one would not want this. on file: mail/locales/en-US/chrome/messenger/messenger.properties line 573 > threadPane.columnPicker.confirmFolder.noChildren.title=Apply columns to folder? Due to proximal duplication on OS X, maybe use something like "Apply Changes?" which is less duplicatively redundant?
Attachment #441237 - Flags: review?(david.ascher) → review+
(In reply to comment #97) > (From update of attachment 441237 [details] [diff] [review]) > > As discussed on IRC, would be good to have the version that can apply to whole > accounts, not just parent folders. Done. > on file: mail/base/modules/MailUtils.js line 335 > > INTER_FOLDER_PROCESSING_DELAY_MS: 100, > > I'm a bit puzzled about the need for the delay, and a bit worried about using > 100msec. If I have 100 folders, that's 10 seconds total elapsed time? Feels > huge. I'll try to understand the need for any real delay. > > Also, you don't actually seem to be setting this in 0 in unit tests, AFAICT. Per discussion on IRC the value has been reduced to 10ms. The unit tests have also been revised to completely turn off throttling. > on file: mail/base/modules/MailUtils.js line 344 > > * (panacea.dat) as well as the folder itself. Hopefully you want this; if > > * you do not, keep in mind that the only way to avoid that is to retrieve > > It's not clear to me why one would not want this. For posterity, from IRC: <asuth> davida: the reason you would not want to write stuff into panacea.dat might be if the data is large and is useless if you aren't in the folder <asuth> davida: for example, there is absolutely no benefit to our putting the column data in the folder cache > on file: mail/locales/en-US/chrome/messenger/messenger.properties line 573 > > threadPane.columnPicker.confirmFolder.noChildren.title=Apply columns to folder? > > Due to proximal duplication on OS X, maybe use something like "Apply Changes?" > which is less duplicatively redundant? I see what you did there. Done. pushed to comm-central: http://hg.mozilla.org/comm-central/rev/21911b10db84
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Since there is a lot of interest in this bug, I will provide the following handy dandy link to get at Thunderbird 3.1 nightly builds which will have this fix starting *tomorrow*: ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.2/ To use the new functionality, you will want to bring up the column picker. Our new menu tree basically looks like so in bullet point form: * Reset columns to default * Apply columns to... * Folder... * Folder and its children... "Reset columns to default" will reset the columns using the rules we apply when we enter the folder for the first time. This means we inherit from the inbox or what not. There are absolutely no new smarts in the inheritance logic, but the... "Apply columns to" options do just what they say. They are built on the same widget we use for the "move to" and "copy to" widget. It is not our favorite widget and honestly it can be a little bit awkward to use based on how menus frequently end up cascading. If you are finding the experience unpleasant, a new trick you can use is to right-click anywhere on the column headers; doing so brings up the column picker just like left-clicking on its little button all the way on the right. One potentially non-obvious aspect of the widget is that if you want to select a folder that has children, you need to select the top menu option (before the separator) in the menu that pops up. So if I want to select folder "Foo" that lives under the INBOX, has a sibling folder "Bar", and has three children "A, B, C", the menus might look like so, ASCII art style: INBOX ----- Foo > Foo Bar ----- A B C When using the "Folder and its children..." choice, the menus also have the choice to select an entire account. Same deal with selecting the identically named first entry. "Folder and its children..." aggressively walks all the folders and *immediately* applies the settings in the current folder to those folders. Because of limitations of how our folder databases work, we need to open the folders and this can lock up the UI for brief intervals related to how many messages are in the folder (or when the folder was last compacted). However, as it walks the folders, you can still use the UI, so if you have a lot of folders, be aware it could take a couple seconds for things to get sorted out. (Maximum propagation rate is 100 folders per second, but in reality it will be less than that.)
Comment on attachment 441237 [details] [diff] [review] v1 column propagation stuff with unit tests (that was implemented with clarkbw's guidance)
Attachment #441237 - Flags: ui-review+
Since this has new strings, I am marking it as ineligible for Thunderbird 3.0.x.
blocking-thunderbird3.0: needed → -
status-thunderbird3.0: --- → wontfix
status-thunderbird3.1: --- → beta2-fixed
Keywords: dogfood, regression
Whiteboard: [has patch, needs mozmill tests, eta Friday][gs] → [gs]
Target Milestone: --- → Thunderbird 3.1b2
Thanks a lot for fixing this! One important comment, thought: > INTER_FOLDER_PROCESSING_DELAY_MS: 10, This is fishy. I didn't see a comment which would say why this is *necessary* either. In general, these kinds of timeouts are basically bugs. If it doesn't work without timeout, then it's going to fail in some cases with timeout. *And* you waste time - in my case about 5 seconds (450 folders) for every change, just because of the timeout, not counting the time the action itself costs. That's significant.
(And bugs which are nightmar-ish to find.)
(In reply to comment #102) > One important comment, thought: > > INTER_FOLDER_PROCESSING_DELAY_MS: 10, > > This is fishy. I didn't see a comment which would say why this is *necessary* > either. Yes, the comment is well below my normal epic discussion. > In general, these kinds of timeouts are basically bugs. If it doesn't work > without timeout, then it's going to fail in some cases with timeout. *And* you > waste time - in my case about 5 seconds (450 folders) for every change, just > because of the timeout, not counting the time the action itself costs. That's > significant. It's not a bug-fix; it's to avoid locking up the UI for an extended period. Discussion from IRC: <davida> so, biggest question i have is about the 100msec delay between folders. <davida> that seems potentially problematic for peoplel with hundreds of folders, and unnecessarily long. <davida> how did you pick that #? <asuth> I arbitrarily picked that number <asuth> probably with the idea that the UI should be somewhat usable while active <asuth> I was a bit concerned about the processing rate too <asuth> which is to say, a maximum of 10 a second does seem potentially slow <davida> do we have any idea how long the operation actually takes? <asuth> the time cost is 1) synchronous parse of an msf file 2) fsync on the transaction that adds the new string property <asuth> the expectation is that #1 will generally dominate but #2 should not be entirely ignored either <davida> oh, wow. we have to parse each msf file? that's indeed potentially scary. <asuth> that was why my original proposal in the bug did not involve us having to do that <asuth> that strategy was to have a generation number for the inbox which would cause things to be re-propagated again on entry <asuth> but that requires that the inbox always be the authoritative source and would limit some people <davida> Still, I think it's a rare operation, and quite deliberate, so I think we should bias towards showing expected results soon, even if it appears to slow down the UI for a couple of seconds. <asuth> or require some other source of on-demand retrieval <davida> so my number would be more like 10 or 20 msec. <asuth> 10 sounds reasonable to me <davida> i'm worried about people thinking it's not working because it's slowly chugging through their potentially large set of folders. <davida> but mostly, I think it'll really help people w/ lots of folders, so that's really good for them. <asuth> hm, yeah, I don't think I zero it because I only wrote the tests today and forgot about that variable <asuth> davida: the reason you would not want to write stuff into panacea.dat might be if the data is large and is useless if you aren't in the folder <asuth> davida: for example, there is absolutely no benefit to our putting the column data in the folder cache <asuth> it's just wasted space
> It's not a bug-fix; it's to avoid locking up the UI for an extended period. Ah, OK, that makes mildly sense. For that, 0ms would have been sufficient, too, *I think*, because even that would allow the event queue to be processed. Maybe you can try that later, or I can (who else has 500 folders? :) ). Thanks a lot again for fixing this bug!
(In reply to comment #105) > > It's not a bug-fix; it's to avoid locking up the UI for an extended period. > > Ah, OK, that makes mildly sense. For that, 0ms would have been sufficient, too, > *I think*, because even that would allow the event queue to be processed. Maybe > you can try that later, or I can (who else has 500 folders? :) ). > Thanks a lot again for fixing this bug! I improved the comment and tried to include a bit of rationale as to why there is any wait (even before your response!), but it's still very arbitrary :) http://hg.mozilla.org/comm-central/rev/d98d6a3f9b09
Thanks for fixing this issue. I see that you are introducing delay in order to keep the UI responsive. Usually, in a deskop application you would use threads for this: the processing would not be done in the main UI thread, but in a different one. If I understand correctly, the Thunderbird UI is written in JavaScript. I was wondering why didn't you used web workers for this...
This is very helpful, thank you!
looks good. one thing i noticed thou: 1. reset the inbox columns 2. add the size column 3. propagate this settings through the whole account. 4. switch to sent folder 5. see that "Recipient:" is gone and "From:" has appeared. i, somehow, would expect this not to happen. a) it should either be *default* size for all folders (so sent would contain Recpient: instead of From:) or the b) sent-folder should always *replace* From: with Recipient. i hope i could clarify the small difference. a) takes the default columns and records the modifications, just like a "diff" b) stupidly replaces From: with Recipient: what do you think? Thanks, Raoul
(In reply to comment #109) > looks good. one thing i noticed thou: > > 1. reset the inbox columns > 2. add the size column > 3. propagate this settings through the whole account. > 4. switch to sent folder > 5. see that "Recipient:" is gone and "From:" has appeared. > > i, somehow, would expect this not to happen. a) it should either be *default* > size for all folders (so sent would contain Recpient: instead of From:) or the > b) sent-folder should always *replace* From: with Recipient. I agree that this behaviour is not desired. Please file a new bug, mark it as dependent on this bug, and cc me. Thanks.
Blocks: 562266
Created a doc bug so that the info in comment # 99 will be transferred to support.mozillamessging.com.
Keywords: relnote
I have not waded through all these comments. But I'm thinking (as I've just mentioned in another site) that being able to select which folders to make the changes makes more sense. You should be able to select which columns to show for the selection as well as the order of the column. There may be folders where some information is wanted that you don't need for another subset of email folders. The fix should not be only one folder or all folders.
Related bugs of interest (if you like, please vote for them using vote button) Bug 528044 - "Show/Open as list" global search results does not remember columns (should persist column visiblity in list view, e.g. for "location") Bug 570787 - Global Search: "Open as list" results should show location column by default [containing folder] Bug 522768 - Search Results: Missing full path in "Location" column (Faceted Search: Open as List, Saved Searches, Search Messages; Main 3-pane Window)
See Also: → 528044, 570787, 522768
Blocks: 574986
See Also: → 574985
I'm confused - is this fixed in TB 3.1 or not? I've just updated from 2.0 to 3.1 and column list (and order) has been changed to some 3.1 default.
I would say it IS fixed! You can now apply your favorite column settings to other folders and their subfolders, using thecontext menu in the "title" area above the scroll bar. This has not been possible in 3.0. BTW: THANKS to the mozilla developers for fixing this! :-)
Oh my gosh! I've been working with 3.1 since it's release and didn't know this! THANK YOU MOZILLA!!!!! You just made my life so much easier, and saved me from Outlook :D
(In reply to comment #116) > I would say it IS fixed! > You can now apply your favorite column settings to other folders and their > subfolders, using thecontext menu in the "title" area above the scroll bar. > This has not been possible in 3.0. > > BTW: THANKS to the mozilla developers for fixing this! :-) Sorry to create another post, I was so excited. Thanks also to Marciej for asking and especially to Philipp for explaining! If anyone else had announced it earlier I was too dumb to understand. This is really great news.
THX to the developers for fixing this!
I thought TB would preserve old settings when this is fixed, but this is nice too :-). Seem to work lightning fast on my home profile I'll check my job profile later. Having said that I found one related problem: Bug 576528 - Column list change is not applied to search folders
Whiteboard: [gs] → [gs][gssolved]
does not work for newsgroups
Apparently it does. I used it with the following 3 and newsgroups have the same columns as the others. 1) Apply columns to 2) Folder & it's children 3) Account name (which includes the newsgroups) Thanks to the developers who worked on this, life is much easier!! Miles
Did a bug ever get opened to request fixing the 'special' folders (Sent, Drafts, Templates and Trash), so that each got the appropriate column ('Recipient' or 'From')? If not I'll go open one now...
Those folders all changed along with the others by using the 3 steps mentioned above. WinXP TB3.1.7.
Blocks: TB2SM
Someone pls. re-open this bug because it is not resolved. Special folders like for example virtual folders (a.k.a search folders) don't accept a column format that is applied in the above way with the steps 1) through 3).
Depends on: 660211
(In reply to comment #124) > Those folders all changed along with the others by using the 3 steps > mentioned above. WinXP TB3.1.7. Miles - you are wrong... Doing that sets the same columns in ALL folders, even the 'Special' folders (Sent, Drafts, Templates and Trash)... These special folders should always use 'Recipient' instead of 'From' - and I'd argue that the 'Trash' folder should have BOTH (that's how I configure mine), since it contains both received and sent messages. This is why raoul opened bug 562266...
I have filed bug 660211 regarding comment #125 (column format is not applied to virtual folders).
Keywords: relnote
In reply to Thomas D. from comment #114) > Related bugs of interest (if you like, please vote for them using vote > button) > > Bug 528044 - "Show/Open as list" global search results does not remember > columns (should persist column visiblity in list view, e.g. for "location") > > Bug 570787 - Global Search: "Open as list" results should show location > column by default [containing folder] > > Bug 522768 - Search Results: Missing full path in "Location" column > (Faceted Search: Open as List, Saved Searches, Search Messages; Main 3-pane > Window) thx a lot for fixing this. i think these are still open relating problems
and this: Bug #774193
Blocks: 579888
Depends on: 873876
Depends on: 622181
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: