Archive command on Local Folders Topic is solved

[Navigator]

I have discovered accidentally that using the Archive command on mail within Local Folders deletes the local message. This is not behavior that I want. Can I block Archive from operating within Local Folders, or control its behavior such as copying instead? If not I request the ability to do so.

[athenian200]

Well, to be honest I've never used that command, never looked at the code for it, and have no idea if that's a bug in Epyrus or how Mozilla intended it to work in the first place.

For now, I would recommend not using that command. The behavior you've described sounds bad enough that if I discover the archive feature is in fact broken, I may have to remove or disable it...

[Navigator]

I find it useful for classifying remote IMAP messages, automatically placing them by date within the IMAP Archive tree and triggering my Filters to copy to Local Folders. This way I do not copy bulk mail to Local. I hope you do not remove this aspect of the command.

[Moonchild]

The whole point of archiving mail is that you put the messages away in the archive. Removal of those messages from the mailbox you're archiving FROM is entirely by design.

[Navigator]

Mail in my Local Folders is already where I want it. I don't want to remove it if I accidentally bump the A key. If I bump Delete, which is a lot harder to do than a home-row key adjacent to Shift and Caps Lock, the message is moved to Trash within Local Folders. With Archive the message disappears from my Local Folders entirely, without further notice or a confirmation dialog.

[Moonchild]

And if you do it accidentally, you can undo it with the industry-standard Ctrl+Z (also found in the Edit menu).

[Navigator]

That assumes I notice in time, and that the message actually makes it to the server and back correctly. If I cannot disable this on Local Folders I at least need to change the key binding to something else.

[athenian200]

Well, I can definitely say I wouldn't have designed it to work this way if I were designing the feature from the ground up. Honestly, not sure why a dedicated archive feature exists that can accidentally be activated, when there are plenty of more intuitive ways to move messages between folders.

So is the main problem that it's a bit too easy to activate on accident, as in there is no confirmation dialog before the messages disappear. Something like "Do you really want to archive X number of messages from <Folder> to <Folder>?" It just does it, regardless of whether you fat fingered your keyboard or did it intentionally?

[athenian200]

Looking through my own mailbox, I can see that I have accidentally archived a few messages over the years without meaning to, starting around 2019... it's only around two or three a year. But still, I don't remember ever agreeing to create those folders on the remote server my e-mail is stored on, or getting any kind of indication of what was happening. One or two of the messages were ones I thought I had lost, but they were actually winding up in weird folders I never would have thought to check.

So, hypothetically, would you be happy with a dialog box like this?

Immagine.png

I would probably want to leave this warning off by default, since a lot of people are probably used to using the archive feature in their workflow and would get annoyed by this dialog box, but I kind of want to add this feature for myself and turn it on, since for me it's a footgun and nothing I would be likely to use intentionally, and I suspect that may be the case for you as well.

I get the impression that this functionality, when implemented, was never intended to be used with IMAP, and then when IMAP was implemented, it never became a big enough deal to change it, plus a lot of users got used to it working that way, so they couldn't really change it without a lot of complaints pouring in.

I really don't understand Mozilla's priorities... why would they ask me constantly if I wish to compact a folder, but not warn me if I am about to setup a series of folders for archiving on my mail server and potentially transfer stuff onto it that wasn't on there before? That probably shows you how little I have really tailored Epyrus to my own preferences so far.

[Potkeny]

I would probably want to leave this warning off by default, since a lot of people are probably used to using the archive feature in their workflow and would get annoyed by this dialog box

What about default on with a "never show this again" checkbox? Those who are using it will have a one-time annoyance while everyone else will now know what is happening if they do it by mistake.

[Moonchild]

What about default on with a "never show this again" checkbox? Those who are using it will have a one-time annoyance while everyone else will now know what is happening if they do it by mistake.

I think this is a good idea. I do use it regularly and don't want to have to confirm every single message I'm archiving.
You can just link it to a pref for the easiest way to make it stick. If people need to undo that they can just reset the pref in about:config

[athenian200]

Getting that dialog with a checkbox working was surprisingly difficult...

Code: Select all

 
 function MsgArchiveSelectedMessages(event)
 {
+  let confirmArchivePref = Services.prefs.getBoolPref("mail.confirmArchive", false);
+  if (!confirmArchivePref) {
+    let checkbox = {value:false};
+    var bundle = document.getElementById("bundle_messenger");
+    var titleMsg = bundle.getString("confirmArchiveTitle");
+    var dialogMsg = bundle.getString("confirmArchiveText");
+    var checkMsg = bundle.getString("confirmMsgDelete.dontAsk.label");
+    let okToProceed = Services.prompt.confirmCheck(window, titleMsg, dialogMsg, checkMsg, checkbox);
+
+    if (!okToProceed) {
+      return;
+    }
+
+    if (checkbox.value) {
+      Services.prefs.setBoolPref("mail.confirmArchive", true);
+    }
+  }
+
   let batchMover = new BatchMessageMover();
   batchMover.archiveMessages(gFolderDisplay.selectedMessages);
 }
 

The main thing that was a bit difficult, was even locating the fact that there was a confirmCheck dialog box... I was thinking at first I would have to use confirmEx to get that, which takes an int and not a bool. Thankfully I didn't have to work out confirmEx, but there were a lot of really minor issues that added up to make this take hours. Then, one of the strings I wanted to use for checkMsg was in the composer bundle, and there is apparently no way to get the JS parser to put that string where I wanted, so I had to search for another one that was defined in the messenger bundle (didn't want to create another copy of a generic string that's already defined). Finally, you can't use

Code: Select all

let checkbox = false;

I figured out through trial and error that it has to have that weird format that says

Code: Select all

{value:false}

that looks sort of like that ugly JSON stuff I sometimes see in various places (like in last_log.json when I open it in a text editor and have to ignore all the ugliness to get at the data I want).

I'm honestly starting to wonder how this is supposed to be easier than coding an interface in Win32 or GTK... I mean, maybe it's easier for web developers, but it definitely seems messier than writing a standard Windows application in C++ for sure.

[Moonchild]

I'm honestly starting to wonder how this is supposed to be easier than coding an interface in Win32 or GTK... I mean, maybe it's easier for web developers, but it definitely seems messier than writing a standard Windows application in C++ for sure.

it's not necessarily supposed to be "easier" if you want that, then use a rapid application builder tool
The point is (as you already hinted at actually) that it's easier to write the code once in a common language, and it can work on all interface back-ends. Coding an interface that's native in Win32 won't work on Gtk, and the other way around!
I do agree the format is a bit odd but you should keep in mind that you're directly manipulating elements there, so you need to indicate which attribute you want to change as well as what to change it to. just saying let checkbox=false will not tell the element parser what exactly of the checkbox control should be false.

[Navigator]

Looking through my own mailbox, I can see that I have accidentally archived a few messages over the years without meaning to, starting around 2019... it's only around two or three a year. But still, I don't remember ever agreeing to create those folders on the remote server my e-mail is stored on, or getting any kind of indication of what was happening. One or two of the messages were ones I thought I had lost, but they were actually winding up in weird folders I never would have thought to check.

So, hypothetically, would you be happy with a dialog box like this?

Sorry that I am late to reply. I appreciate the attention, but for me this dialog does not really help my workflow. I actually want to be able to Archive server-side messages with ease. My issue is that I want my Local Folders to be sacrosanct. I do not want any messages deleted from them without confirmation, like the two step process of Delete and then Empty Trash that already exists. The easy-to-accidentally-activate Archive command effectively bypasses this by MOVING messages to the server. I found a solution through Filters that I can live with, which is to create a Local Folders Filter applied on Archiving to All Messages that Moves to Local Folders/Archive. This way I get behavior similar to Delete, with /Archive instead of /Trash. Other, better solutions that would work for me are:

1. A way to disable Archiving behavior on messages within Local Folders entirely.

2. A confirmation dialog that appears only when used within Local Folders.

3. Ability to change the key binding of the Archive command to something like Shift+Alt+A that I will not accidentally activate.

[FranklinDM]

I think this might be more involved, but what if we provide the option to configure Message Archives for Local Folders in the account settings instead, similar to how it already works in the copies and folders pane of regular email accounts? Then if "Keep message archives in" is unchecked (for local folders), just make the archive button/shortcut action not do anything and display a message in the status bar that no emails were archived because of the configuration in the settings.

[athenian200]

I think this might be more involved, but what if we provide the option to configure Message Archives for Local Folders in the account settings instead, similar to how it already works in the copies and folders pane of regular email accounts? Then if "Keep message archives in" is unchecked (for local folders), just make the archive button/shortcut action not do anything and display a message in the status bar that no emails were archived because of the configuration in the settings.

Wait a minute, it looks we already have that feature? From looking at the code, it wasn't obvious that the location of the Archives was configurable, but maybe I wasn't looking in the right place.

If I uncheck that box, then the Archive message feature is disabled completely on the currently released Epyrus version! It disappears from the context menu, is greyed out and everything. And it looks you could even set it up so that it archives messages to a local folder instead of to your mailbox, which is another feature I was thinking I might implement in the future if I figure out how the darn thing actually works.

So, umm... what exactly is the proposed feature here? I'm thinking... you might have a better grasp of what the problem is than I do. I was thinking in a very one-dimensional way, as if the archive feature had no granularity and mindlessly archived all messages you threw at it to an IMAP folder with a pre-determined structure on your remote e-mail server, with no way to configure the behavior. But it looks like it actually has per-account settings. Which changes the context completely, and suggests the underlying problem is that it doesn't honor Local Folders as a separate "place" with its own preferences. I was thinking Navigator wanted me to implement a distinction the code currently doesn't make at all, but it looks it does make that distinction, just not for Local Folders?

Now what I'm wondering is... if you have more than one e-mail account setup with Epyrus, does it ever archive messages from one account to another, or is this only an issue with Local Folders? I'm noticing that if I try "Archive" from Blogs and News Feeds, it sends it to a local folder under that account, and if I try the same thing on messages from a Newsgroup account, it actually creates an Archive hierarchy under Local Folders and puts it there...

So, if I try running the "Archive command" again, on a message within the Archive folders on Local Folders (as gets created for the Newsgroup account)... the message gets moved again, to the IMAP server associated with my e-mail account. But this doesn't happen when I try to archive something that's already in the Archive folders of the Blogs and Newsfeeds account, and seemingly counts it as something separate. There's definitely something not right going on here. You wouldn't expect previously archived messages from a different account to archive again to a remote server. And the other thought I have is... how does it even know which e-mail account to "archive" messages from the Local Folders hierarchy to, if I have more than one? It looks like it just picks the first e-mail account it finds, or the last one I had active before Local Folders? It looks like we may be dealing with undefined behavior of the Archive feature if it's called from within a hierarchy of Local Folders. The feature we have is just assuming that we are operating within the context of an account, and doesn't have any kind of fallback for a situation where that's not true, like within Local Folders.

[Moonchild]

Simple solution: default the archive feature to OFF for local folders?

[athenian200]

https://repo.palemoon.org/athenian200/e ... y.js#L1668

So, apparently this was the key. I tried turning this piece of code off, and sure if I do that, the RSS account starts exhibiting the same "bad behavior" as the Local Folders do... just archiving stuff to my e-mail account.

And conversely, if I change this test to server.type == "none" then trying to archive things within Local Folders creates a self-managed hierarchy of Archive folders, which cannot be further archived into the archive folders of other account identities.

So if I understand correctly, the problem is that Local Folders have no identity associated with them, and are prone to a bug that was probably worked around at some point for RSS feeds, but went unnoticed for plain local folders.

[Navigator]

I think this might be more involved, but what if we provide the option to configure Message Archives for Local Folders in the account settings instead, similar to how it already works in the copies and folders pane of regular email accounts?

I thought of this, actually I looked for it in the Account Editor, but I figured that was too much work. It would nevertheless solve this "problem" most robustly.

So, umm... what exactly is the proposed feature here? ... But it looks like it actually has per-account settings. Which changes the context completely, and suggests the underlying problem is that it doesn't honor Local Folders as a separate "place" with its own preferences. I was thinking Navigator wanted me to implement a distinction the code currently doesn't make at all, but it looks it does make that distinction, just not for Local Folders?

Yes! For the sake of Archive, making Local Folders act like other Accounts with its own configuration would be great, but I assume that's a lot more work than just allowing remapping of Archive to Alt+Shift+A or whatever.

There's definitely something not right going on here. You wouldn't expect previously archived messages from a different account to archive again to a remote server. And the other thought I have is... how does it even know which e-mail account to "archive" messages from the Local Folders hierarchy to, if I have more than one? It looks like it just picks the first e-mail account it finds, or the last one I had active before Local Folders? It looks like we may be dealing with undefined behavior of the Archive feature if it's called from within a hierarchy of Local Folders. The feature we have is just assuming that we are operating within the context of an account, and doesn't have any kind of fallback for a situation where that's not true, like within Local Folders.

You're right. I just tried Archive on an imported message from an email account that no longer exists. It moved the message to the completely-unrelated IMAP account that is listed first in Epyrus Account Settings. This is another problem that needs solving IMHO. Now I really think there needs to be a way to disable Archive behavior on Local Folders messages.

And conversely, if I change this test to server.type == "none" then trying to archive things within Local Folders creates a self-managed hierarchy of Archive folders, which cannot be further archived into the archive folders of other account identities.

You posted this while I was composing the above. When you say "a self-managed hierarchy of Archive folders" you mean within Local Folders? If so that is also a solution.

[athenian200]

You posted this while I was composing the above. When you say "a self-managed hierarchy of Archive folders" you mean within Local Folders? If so that is also a solution.

Correct, the same fix seems to have been used for the RSS Feed accounts which lack their own identity. It ties archiving on/off to the pref mail.identity.default.archive_enabled. Without the fix I highlighted, RSS feeds exhibit the same behavior, archiving to the first e-mail account's IMAP folder. If I just add one more field to this test, telling it to also check if server.type is "none" (which is only the case in Local Folders), then trying to Archive mail in Local Folders... just results in an Archive folder being created in Local Folders and the mail being moved there. And correctly does nothing if the mail is already in Archives in Local Folders.

To keep things simple though, I could probably just tell the code to stop there and assume archiving is disabled if we're in Local Folders, but if there's already a "default identity" like this, I see no reason not to use it for Local Folders...

The problem isn't that archiving is disabled or enabled for Local Folders, it's that the code makes assumptions about how archiving should work based on the current "identity," which, if not explicitly set here to a reasonable default, will default to whatever the first valid identity it can find is, often the first e-mail account listed in Epyrus, whether that has any relationship to the folder you're working with or not.