Remove or provide an option to disable the 'Delete all messages' confirmation dialog.

[brammeleman]

Background: When I'm debugging mail templates, a test iteration looks like:

• Edit my software
• In mailpit: Hit "Delete all"
• Confirm yes
• Run my software
• Open the newest mail in mailpit
• [repeat]

It would be nice to have an option like "tail -f" but then for email messages. Not quite sure what it should look like.
Maybe it's possible to have all mails expand by default. Like a Gmail conversation, but then just all incoming mails sort of concatenated.

One other step to make the test-iteration shorter is to get rid of the delete all confirmation dialog.

I'm curious whether others share this need and what you think about it.

/Bram

[axllent]

Thanks for the feedback @brammeleman. I'm really not sure how a "tail" UX could work, considering one may very easily get multiple messages coming in at once ¯_(ツ)_/¯ . I think that trying to implement functionality like this may cause more issues than it solves, and it would really just to save one click.

I do however get your point about the confirmation modals. The reason they exist when doing a "delete all" or "mark all as read" is to prevent the mistake of accidentally deleting all your messages (or marking them as read), especially when you have hundreds or thousands of emails in there for instance (I have 135k messages in mine). What if I added some additional logic where doing either action with <= 25 messages does so without confirmation, otherwise the modal is displayed?

What do you think?

[brammeleman]

Hi @axllent! I'm usually just interested in the last mail(s) sent to mailpit. I agree "tail" kind of functionality is a bit of a stretch UI/UX wise.
Maybe a toggle button that clicks the 'new message'-notification popup for you?
Or a setting that disables the confirmation?

135k messages... wow! for bulk mail testing? archive?

[axllent]

I'll give the "tail" a bit more thought in the next couple of days, however I'll be honest and say it's it's not looking very likely at this stage. There are factors like what to do about the new mail popup and favicon counters, and of course the performance issues if multiple emails are received at once. Mailpit also has different views (UI controllers) which also complicate matters. All decisions I make regarding new features need to consider "the wider audience" (ie: other Mailpit users), as well as performance, upfront effort to develop something, and of course ongoing Mailpit maintenance overheads. I just can't please everyone unfortunately. Sometimes there are small "wins" (like the confirmation modal logic I described earlier) which potentially benefit everyone, and other times I can spend many hours working on something which saves one person just a few seconds. As I said, I'll get back to you on this.

The 135k is an archive (copy) of my personal email, as well as a testing ground. It runs on a fairly low-end machine which makes it ideal for performance testing as bottlenecks are easier to detect that way ;-)

[brammeleman]

I completely understand!
Do you mind if I change the issue description with something like

Remove or provide an option to disable the 'Delete all messages' confirmation dialog.

[axllent]

That sounds good. Thanks 👍

[gitgrub]

Just an idea for the "delete all" task without interaction: what about using the API with curl? Depending on how you run your software, this would be the first step.