feat: Allow user to control message view mode

[SebastianKrupinski]

Resolves: #5913

Summary

• Adds the ability for a user to control message viewing mode (Threaded View or Singleton View)
• Adds the ability for a administrator to preset default message viewing mode (Threaded View or Singleton View)
• Changes behavior of drag and dropping message(s) to folder depending on viewing mode (Threaded View or Singleton View)
• Changes behavior of Message List -> Message Actions menu (Move, Delete, Snooze) depending on viewing mode (Threaded View or Singleton View)

User Setting

Administrator Settings

[ChristophWurst]

If you receive two messages that form a thread, you will still only see one entry in your INBOX with the current approach, right?

[GretaD]

before

after

[GretaD]

it works as described

[ChristophWurst]

Tested and doesn't work. It's only possible to open the latest received message of a thread. I can not open earlier ones, because they are not shown in the message list. The list is still threaded.

[SebastianKrupinski]

Tested and doesn't work. It's only possible to open the latest received message of a thread. I can not open earlier ones, because they are not shown in the message list. The list is still threaded.

Correct! I was not aware we stacked messages in the list, I have already made the backed and front end changes, just need to updated some backend tests, will push the update soon.

[SebastianKrupinski]

Tested and doesn't work. It's only possible to open the latest received message of a thread. I can not open earlier ones, because they are not shown in the message list. The list is still threaded.

Corrected, message are no longer stacked in message list.

[ChristophWurst]

Looks sane

Are there any plans to skip building threads if the user doesn't use them anyway?

[ChristophWurst]

Inline the var and you have a smaller diff ✨

[SebastianKrupinski]

Done, Hopefully this is what you ment

[ChristophWurst]

Are there any plans to skip building threads if the user doesn't use them anyway?

@SebastianKrupinski?

[SebastianKrupinski]

Are there any plans to skip building threads if the user doesn't use them anyway?

@SebastianKrupinski?

Fixed, took some major head scratching to find the correct code.

[SebastianKrupinski]

Will fix lint errors on final approval

[ChristophWurst]

Apologies if my communication wasn't clear from the ticket and task description (#5913 (comment)). I should have communicated this more actively.

Do you see an issue with handling "dethreading" on the database level? With the latest changes we see lots of conditional logic for threaded vs non threaded views. When every message forms a thread of one, we don't need the conditional logic, do we?

Building threads needs a check to be skipped with any solution. With the current state they are still built:

...
[debug] Building threads for account 4634
[debug] Account 4634 has 30 messages with threading information
[debug] Threading 30 messages - build ID table took 0s. 15/16MB memory used
[debug] Threading 30 messages - build root container took 0s. 15/16MB memory used
[debug] Threading 30 messages - free ID table took 0s. 15/16MB memory used
[debug] Threading 30 messages - prune containers took 0s. 15/16MB memory used
[debug] Threading 30 messages - group by subject took 0s. 16/16MB memory used
[debug] Threading 30 messages took 0s
...

[SebastianKrupinski]

Do you see an issue with handling "dethreading" on the database level? With the latest changes we see lots of conditional logic for threaded vs non threaded views. When every message forms a thread of one, we don't need the conditional logic, do we?

Building threads needs a check to be skipped with any solution. With the current state they are still built:

I see what you mean on the building threads part, this should now be addressed.

As for the conditional logic on the front end, if I understand your comments properly, yes we do (but I might be missing something), can we discuss on Monday?

[ChristophWurst]

Okay