You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently SupportFlow archives messages once they're downloaded, rather than deleting them.
One benefit of this approach is that it's safer; if something goes wrong, or if the user's workflow/use case doesn't match our assumptions, then the messages are still available on the server.
One potential downside, though, is that their mailbox could fill up and then be unable to receive new emails. The SF admin would not know that until someone contacted them through an alternate channel to let them know.
One potential solution that wouldn't impact the current approach would be to have SupportFlow check the mailbox size, and warn admins when it reaches 80%, and let them know to clear out the archive folder if they want.
We should also consider whether we should delete messages by default, though. Either way, maybe we should have a filter to control archiving vs deleting.
The text was updated successfully, but these errors were encountered:
A lot of IMAP accounts are configured to namespace any mailboxes
with `INBOX.` and attempting to move to `ARCHIVE` or creating it
fails silently, causing the e-mails to be fetched over and over
again. With this filter, one is able to change the name of the
archive box.
This is a temporary solution until more user-friendly archive
mailbox picker is in place, and/or #245 is implemented.
Currently SupportFlow archives messages once they're downloaded, rather than deleting them.
One benefit of this approach is that it's safer; if something goes wrong, or if the user's workflow/use case doesn't match our assumptions, then the messages are still available on the server.
One potential downside, though, is that their mailbox could fill up and then be unable to receive new emails. The SF admin would not know that until someone contacted them through an alternate channel to let them know.
One potential solution that wouldn't impact the current approach would be to have SupportFlow check the mailbox size, and warn admins when it reaches 80%, and let them know to clear out the archive folder if they want.
We should also consider whether we should delete messages by default, though. Either way, maybe we should have a filter to control archiving vs deleting.
The text was updated successfully, but these errors were encountered: