feature request: per-account offline status
Categories
(Thunderbird :: Account Manager, enhancement)
Tracking
(Not tracked)
People
(Reporter: alanjstein, Unassigned)
References
(Depends on 1 open bug, Blocks 2 open bugs, )
Details
(Keywords: design-needed, triaged)
Comment 1•20 years ago
|
||
Comment 4•17 years ago
|
||
Updated•17 years ago
|
Comment 7•15 years ago
|
||
Comment 8•15 years ago
|
||
Comment 9•15 years ago
|
||
Comment 12•13 years ago
|
||
Updated•13 years ago
|
Comment 16•12 years ago
|
||
Comment 17•12 years ago
|
||
Comment 18•12 years ago
|
||
Comment 19•11 years ago
•
|
||
Comment 20•11 years ago
|
||
Comment 21•11 years ago
|
||
Comment 23•10 years ago
|
||
Comment 24•9 years ago
|
||
Comment 25•8 years ago
|
||
Comment 26•8 years ago
|
||
| important | ||
Comment 28•8 years ago
|
||
Comment 29•7 years ago
|
||
Comment 30•6 years ago
|
||
(In reply to Suyash Agarwal (:sshagarwal) from comment #26)
What if...
Are you offering to implement? :)
Comment 32•6 years ago
|
||
This has been going on for 14 years now - surely someone can implement this without a lot of work? seems like a fairly simple idea, just skip the account when checking email.
What is holding this up? Is it a complex problem? or is it that developers are not interested? Can someone shed some light on this?
If it does get implemented please make it a feature for ANY email account in TB not just IMAP.
Comment 33•6 years ago
|
||
I would like to work on this. Please assign this to me. I would definitely complete this ASAP and push the PR. This is my first contribution to Mozilla and would be delighted to work on this.
Comment 34•6 years ago
|
||
Somu - glad to hear you're interested in helping. This bug is fairly involved, and not easy to tackle as a first contribution.
That said, if you want to go ahead and submit a patch for it, go ahead, and I'll assign it to you then.
Comment 35•6 years ago
|
||
Somu - I was wondering if you could post a status on your attempt to address this issue? Is there anything I can do to help? My expertise is in C with not too much c++ but if I can help I'm willing to do so.
Comment 36•6 years ago
|
||
This should be closed as 'developers not interested'
Comment 37•6 years ago
|
||
Eric, Somu seems to be gone. Are you willing to work on it?
Comment 26 lists some of the key items.
Comment 38•6 years ago
|
||
I would do it in a heartbeat if i had the skills. My expertise is in plain old C. There are 3 or 4 things I'd love to add to TB but the programming language is the barrier
Comment 39•6 years ago
|
||
Eric, we'd love to have you help out. Let me know if there's something you need help with to get started. Going from C to JavaScript may be easier than you think too.
Comment 40•6 years ago
|
||
I'll take a look at it, I cant promise anything but I'll certainly take a peek and see if its doable for me.
Is there an official git repo or someplace I should download the source from? Any pre-req's I need to make the unaltered source compile properly?
Comment 41•6 years ago
|
||
The best place to start is https://developer.thunderbird.net/the-basics/getting-started which should have all info you need.
Comment 42•6 years ago
|
||
I ran into a problem I cant figure out how to solve.
:25.84 config/external/icu/common
0:25.86 error: failed to run custom build command for baldrdash v0.1.0 (source/js/src/wasm/cranelift)
0:25.86 Caused by:
0:25.86 process didn't exit successfully: source/obj-x86_64-pc-linux-gnu/debug/build/baldrdash-48a5573b3680cb59/build-script-build (exit code: 101)
0:25.86 --- stdout
0:25.86 cargo:rerun-if-changed=baldrapi.h
0:25.86 cargo:rerun-if-changed=source/obj-x86_64-pc-linux-gnu/js/src/rust/extra-bindgen-flags
0:25.86 --- stderr
0:25.86 thread 'main' panicked at 'Unable to find libclang: "couldn't find any valid shared libraries matching: ['libclang.so', 'libclang-.so', 'libclang.so.'], set the LIBCLANG_PATH environment variable to a path where one of these files can be found (invalid: [])"', src/libcore/result.rs:999:5
libclang is installed:
/usr/lib/libclang.so.6
/usr/lib/libclang.so.6.0
/usr/lib/libclang.so.7
/usr/lib/libclang.so.8
/usr/lib64/libclang.so.6
/usr/lib64/libclang.so.6.0
/usr/lib64/libclang.so.7
/usr/lib64/libclang.so.8
Any ideas as to what might be going on there?
I tried ./machclobber followed by ./mach bootstrap and it appears tere is an issue with my OS:
NotImplementedError: Bootstrap support for this Linux distro not yet available: openSUSE Tumbleweed
Could this be the root cause of my errors?
Comment 43•6 years ago
|
||
Ha! Posting errors always causes me to find a fix! I dug around and found a patch for './mach bootstrap' , now it seems to be building, its well past the failure point from before. I don't know why the patch wasn't already in there but it wasn't.
Comment 44•6 years ago
|
||
I was having a look at this, but it is not exactly clear to me what behaviour we want to get. In particular the way this relates to the current binary offline/online option:
- Should this option be removed? (Clear behaviour, but you have to turn every account on/off manually to switch.)
- Should this option be kept as a shorthand to set all accounts to online/offline easily? (The option would then become tristate and we'd need a new icon for the case that some accounts are offline, and others online.)
- Should this option be kept in addition to the new per-account options? I.e., if we are globally offline, nothing is synced, and if we are globally online, only those accounts that are online are synced. (This seems the most powerful, but at the same time it's hard to communicate the current status clearly in the UI. And there would be no easy way to set everything online.)
I also had a look at the implementation. This is my first time working on thunderbird (but I have fiddled around in SpiderMonkey before), so I could use some pointers to where things should be implemented, if anybody has time to help out.
I found the MailOfflineMgr in mail-offline.js, which will need to be adapted regardless of how the global offline/online option is changed. But this class hooks into Services to disable all network traffic, it seems to me. This approach is not possible when we selectively set accounts offline: some connections must be closed, others must remain open. So where should this be done, and via which API?
Also, comment #29 talked about a property in a *.idl file; which file is this?
Many thanks for your time.
Comment 45•6 years ago
|
||
Maybe I have a simple view of things, but to me the solution is quite straight forward:
When creating an account, the account settings page would have a check box (at the top of the page) to disable the account, it would, by default, be unchecked. All the check box would do is set a flag in memory (e.g a class bool variable), when checking accounts for mail, if the flag is set for the account, skip it. You probably should also include some sort of visual indicator that the account is disabled, either put the name in orange or add a 'x' next to it in the accounts list on the left sidebar or some such thing. The checkbox state would also need to be saved in the rc file or wherever TB stores those things it wants to remember at next startup.
This at least would get things rolling and more involved changes could be addressed later on
Comment 46•6 years ago
|
||
(In reply to Eric Benton from comment #45)
Have you looked at the implementation of the current global offline/online setting? It may be a bit more complicated than you think. See my previous comment. Also, in my view, it is better to get the relation to the current global setting right at the first time as this is a user-facing change. The UI on which you write is the least of my concerns.
Comment 47•6 years ago
|
||
Note - this is a much requested feature in support forums (not reflected in the votes of this bug of course)
Comment 48•6 years ago
|
||
Thanks for offering to look at this.
Possible duplicates / related bugs in https://mzl.la/2Olj1x4 - to cite a few :
- Bug 546553 - default setting for do Not check for new emails at startup does not work
- Bug 636174 - Need ability to disable contacting server (TB presents "Add security exception" dialogue for inactive account)
- Bug 689067 - Ability to disable an IMAP account without losing e-mail. (currently cited as a blocker to this bug)
- Bug 563334 - Implement pref and UI to exclude account from "Get All New Messages" poll: Cannot disable checking of obsolete account
Comment 49•6 years ago
|
||
(In reply to Camil Staps from comment #44)
Thanks for considering looking a this bug. It is likely hard to take one as a first bug however.
The current online/offline needs to remain. The per account could be either a third state (applying just to a particular account), or maybe it could make more sense to have it called something different.
Comment 50•6 years ago
|
||
(In reply to Camil Staps from comment #46)
(In reply to Eric Benton from comment #45)
Have you looked at the implementation of the current global offline/online setting? It may be a bit more complicated than you think. See my previous comment. Also, in my view, it is better to get the relation to the current global setting right at the first time as this is a user-facing change. The UI on which you write is the least of my concerns.
If the account is disabled its not going to be able to send or receive mail. Whatever happens in global offline will (or should not) have any effect on a disabled account. A disabled account can neither send nor receive nor compose mail (but reading mail ought to be allowed) regardless of the Global Offline setting, when an account is disabled you just cant ask it to check mail or compose mail, it wont do anything if you do because its disabled. I suppose one would also need to prohibit composing mail for a disabled account because its disabled.
What "disable account" does for people is to save them from having to delete an account just to have it stop getting mail, they want to temporarily disable it for whatever reason but not lose the accounts emails.
This idea has been over thought or just ignored for a decade and a half! and still has no implementation. If you are capable of programing something up then please do, perfection is the enemy of good enough. I looked at the code but one thing i cant figure out is how to create a checkbox and respond to the check/uncheck events. How do you define a function to be called when the checkbox changes state? that sort of thing i just couuldnt determine while reviewing the code. I would also change the font color on the account name to show its disabled
Comment 51•6 years ago
|
||
(In reply to Eric Benton from comment #50)
If you look at the use cases described above and in the linked bugs, people want to be able to compose mail and send it when re-enabling the account. What you describe is but one use case.
Also, again, the UI is the least of my concerns at this point.
(In reply to Magnus Melin from comment #49)
Thank you for the clarification. I realise this bug is quite involved - to hopefully give you some trust that I might be capable of it: I did tackle this long-standing issue https://gitlab.com/gitlab-org/gitlab-foss/issues/20137, which was in a code base and a language I hadn't worked with before. Nevertheless, I could use some help with the architecture. If you/others don't have the time for that, I completely understand, but then I unfortunately won't be able to look into this.
Ideally I could use some pointers as to which files I should touch and where this functionality should be implemented. If you know of a similar feature in terms of which code paths it affects, that would be very helpful too, as I could then trace that feature through the source to better understand which files to work on (but I already looked at this myself from a user's perspective and could not really identify such a feature).
Comment 52•6 years ago
|
||
Great! Show us what you've got :)
It will require some research exactly where code need to be added/adjusted. Probably in a few different places - I imagine you'll start to find more once you've handled these: see nsIMsgIncomingServer.idl - nsIMsgIncomingServer.getNewMessages: https://searchfox.org/comm-central/search?q=getNewMessages&case=false®exp=false&path=.cpp
Potentially some of it can be traced down to places that check for offline, especially in IMAP code. Maybe this will be relevant: https://searchfox.org/comm-central/search?q=MsgOfflineManager&case=false®exp=false&path=
Sorry for the vague references, it's really not that clear exactly where such checks should be. You'll have to experiment a bit.
Comment 55•5 years ago
|
||
If you are just preserving accounts that have been deleted from the server changing the server name to localhost makes this a little bit less annoying. Instead of the modal window that I was previously getting that I had to manually dismiss i not just get a notification that the connection was refused.
This won't help people who want an easy way to flip an account on/off. But if you like me don't expect the account to be able to connect again this change helps a little bit.
Also this conversation would also fit so well on this thread - https://i.redd.it/g42qmpnunya51.jpg
| Comment hidden (metoo) |
Comment 58•5 years ago
|
||
this isn't a mozilla run project - https://www.thunderbird.net/en-US/about/
Focus on other things combined with lesser user interest in this type of capability compared to other requests. No can't predict when the priority may change.
| Comment hidden (offtopic) |
| Comment hidden (off-topic) |
Comment 61•5 years ago
|
||
To me, it seems is those simple/obvious features aren't implemented, then more people get fed up and move away from TB, and then less people ask for those particular features (especially when they never get addressed) then inevitably those features won't get asked for as much and then TB falls into a overall spiral of downward adoption.
Each year and evolution of TB that goes by, I see various "new" so-called methods of useabity added that somehow break, corrupt and limit my well-established UX workflows. Sometimes I wonder why I'm still with TB. I still like it for configurability, but for each so-called visual or streamlining 'advance' TB makes, it takes me a lot of effort to tweak TB back into functionality.
As a user of quite a few email accounts where I often have to set up additional ones for various client workflow and testing purposes, it is a real pain that I can't just simply deactivate some and instead have to resort to completely removing them from an otherwise well-honed TB config for each and every email account. A nice little checkbox somewhere in the account settings to pause or archive an account would be so wonderful and it seems it would be such an easy thing to add surely?
Comment 62•5 years ago
|
||
(In reply to mrartist from comment #61)
A nice little checkbox somewhere in the account settings to pause or archive an account would be so wonderful and it seems it would be such an easy thing to add surely?
It can not be implemented at all until bug 689067 is fixed. Without a full understanding of what is required it is always simple to ask for "just a little box asking". This is actually a reasonably complex issue and while it would be nice may still be aways off. Personally, I have a lot of things I think are more important to Thunderbird like operating system integration, Reliable MAPI compliance, profile import and export, address book import and export in a native file format and much much better error reporting. So I understand where you are coming from, but it will not be hastened by evangelising.
| Comment hidden (metoo) |
| Comment hidden (metoo) |
Updated•5 years ago
|
Updated•3 years ago
|
Updated•2 years ago
|
| Comment hidden (advocacy) |
Comment 73•1 year ago
|
||
| workaround | ||
From bug 1647632 comment 6:
A user at Fosdem asked for this ability.
There's a workaround that can be achieved in a few steps in the Account Settings:
Uncheck all Server settings "Check for new messages..." options.
In Synchronization & Storage uncheck the Message Synchronization option.
That should theoretically prevent any active server syncing and message downloading, but still keep the account active without being deleted.
As we're not gonna focus on the Account Settings this year, this is an option we want to implement next year during the rebuild of the settings.
Note however, the workaround is not 100% solid in practice, because accounts can still get polled by various get new message in the unified toolbar which act on all accounts, and perhaps other functions. This is documented in other bug reports.
Description
•