Mail: Grouping of message threads (threading/conversations) [$320]

[jancborchardt]

Similar as in Gmail, Apple Mail for iOS, or Facebook private messages or what have you. Read messages in that thread should be compressed & expandable (also like in Gmail and iOS Mail), and inside the thread the sorting should go recent messages on the bottom (because of reading direction, and that’s how comment threads work).

There should be no indentation or crap like that, just timestamp-based sorting. In the future every individual message in the thread could show a »Reply« button on hover to reply to that specific message. But for now I’d just keep it simple like a one-stream comment thread.

For reference:

• Jamie Zawinski's message threading algorithm
• Max Ogden's JS implementation of said algorithm
• https://tools.ietf.org/html/rfc5256

---

There is a $220 open bounty on this issue. Add to the bounty at Bountysource.

---

There is a $220 open bounty on this issue. Add to the bounty at Bountysource.

[sim6]

Firstly thanks for your work.

Any thread/conversation support is essential to me. I prefer see all related mails on the same page.

[jancborchardt]

@sim6 cool you enjoy the app! :) Since you are a developer, would you be interested in contributing a bit? We are an open project and anyone is welcome!

[adsworth]

I would love if this thread/conversation view includes all mail regardless of the folder in which it is saved. Outlook (yes I know) does this and I find it really helps me when I get replies in my INBOX. The thread shows all the mails of the conversation regardless of the folder I saved the previous mails to.
The list should also show a link/label of the folder in which the individual mails are.

[jancborchardt]

@adsworth yup, agree. Want to contribute to the bounty on this issue? ;) https://www.bountysource.com/issues/37463009-grouping-of-message-threads-threading-conversations cc @sim6 as well.

[ChristophWurst]

Just in case anybody wants to work on this: please first write down how you'd implement this. There are many aspects to consider for this feature to work properly. Thanks.

[nsrosenqvist]

Any action on this?

[ChristophWurst]

No

[jancborchardt]

@nsrosenqvist so you are very welcome to contribute! :)

[PanderMusubi]

You can add this line at the top of the issue description, it will update itself

![badge](https://api.bountysource.com/badge/issue?issue_id=37463009)

and it looks like

[alexanderdd]

can this be added to the "next" milestone please? It says here https://github.com/nextcloud/mail/blob/master/README.md that it is planned for future versions.

(Yes I am aware that this issue is in the "feature parity" project)

[jancborchardt]

@alexanderdd the planning is done according to @ChristophWurst’s availability and he’ll plan accordingly. :) Any contribution is always appreciated, be it from yourself, or telling other developers that they can contribute to this, or also donating to make this feature happen: https://www.bountysource.com/issues/37463009-grouping-of-message-threads-threading-conversations

[thomas-mc-work]

ChristophWurst added this to the 0.20.0 milestone

The CHANGELOG.md tells me it wasn't part of version 0.20. Was that assignment to this milestone a mistake?

Also, the next milestone doesn't contain any issues.

[ChristophWurst]

Hey Thomas! Please don't take these milestones too serious. I use the mostly to tag things that definitely go into a release, so I don't forget when releasing. At the time I assigned this ticket I thought 0.18 would be the next version, then 0.19 can ship #2064 and 0.20 can ship #2125. But things have turned out to be a bit more complex. We're about to integrate #2064, though, and you're very welcome to test the previews at your own risk. With good feedback we can move forward faster. Any help is appreciated :pray:.

Once #2064 is done we can look into #2125 again. Depending on how complex it is, this feature could land in the next few months. Again, the more people we have for testing and development, the faster it goes :v:.

The next milestone has nothing assigned as I don't do much long-term planning of specific releases. I'm an advocate of RERO and therefore release frequently. Moving things around constantly is a waste of time.

[ChristophWurst]

We're about to integrate #2064, though, and you're very welcome to test the previews at your own risk.

Please see https://help.nextcloud.com/t/call-for-testers-mail-v1-3/75825. We'd appreciate if you could help us test the upcoming release :v:

The sooner we get the next release done, the more time we have to continue threading :pray:

[ChristophWurst]

Hey there,

I'd just like to let you know that due to the ongoing issue with Bountysource we're discussing ways to move to a different platform. As it looks right now, Bountysource might claim some of the money that was contributed by the community. We will try our best to prevent that. Historically we – the Nextcloud GmbH employees – simply put the claimed bounties back to other tickets until one was solved by a community member. So the money was always from the community and for the community. We'll therefore move to a better platform and currently don't post any new bounties until this situation is resolved. The current goal is to move/donate the money to Nextcloud include but details will follow in the forum post.

Hope this makes sense. If you have any questions please ask them on the forum. This comment will be copy-pasted to all open issues with bounties.

Christoph and the Mail team

[HLFH]

Besides forum post, see main GitHub discussion about BS here: https://github.com/nextcloud/mail/issues/44#issuecomment-645487878.

[ChristophWurst]

Since this is a complex feature, I would like to split it a bit so we can cope with the complexity.

Update: Converted into a project https://github.com/nextcloud/mail/projects/11

0) Change front-end so an opened message is identified by its database ID (and not accountId, folderId, UID)
1) Change database schema so mail_messages also have a parent_message_id and a parent_id and try to populate both on insert. Also try to find any dangling parent_message_ids and update those rows.
2) Change front-end so for each opened message you also see the previous message. But do not de-duplicate inside the message list because this is complex and deserves a step of its own.
3) Only show each thread once per message list.

[ChristophWurst]

Note: I would, for the first implementation, ignore any threading algorithm but the one based on References and In-Reply-To, simply because that one will cover most cases. We can look into the subject algorithm later, but it won't be as easy. As a step in between we could already populate the database with the base subject.

[ChristophWurst]

:bookmark: http://kb.mozillazine.org/Stop_threading_by_subject

Messages can be grouped into threads based on common Subjects, and/or by information stored in the References/In-Reply-To headers. There are many e-mail clients that do not add In-Reply-To and References headers to messages, which is the typical way to determine a thread. Threading based on the subject can be annoying when you get unrelated messages with common subjects such as "Hi!" or "Report!". By default Thunderbird tries to groups messages into threads in the following order:

Common reference in the References header
Common reference in the In-Reply-To header
Same Subject, and the Subject contains Re:
Same Subject
Check if the message is an ancestor of an already-threaded message.

There are several settings that manage threading that can be changed using the Config Editor at Tools -> Options -> Advanced -> General.

mail.thread_without_re will thread based on the subject even if there is no Re: in the subject. It defaults to false starting with Thunderbird 3.0.
mail.strict_threading disables threading based on the Subject and only uses the References/In-Reply-To headers headers to determine threads. It defaults to true starting with Thunderbird 3.0.
mail.correct_threading will thread messages correctly using the References/In-Reply-To headers regardless of the order the messages were added to the folder. It defaults to true starting with Thunderbird 3.0.
mailnews.localizedRe defines a comma-delimited list of alternative prefixes to "Re:"

If you want to stop all threading by Subject set mail.strict_threading true.

[szaimen]

🎉

[ChristophWurst]

Wait it's mostly just the backe-end changes. I did no intend to close this ticket yet :P

[ChristophWurst]

We have the full conversation-style view now. The last piece of the puzzle is the collapsing of message of the same thread in the message list and that will be worked on as https://github.com/nextcloud/mail/issues/3652. Hence I'm closing this as (mostly) done :)