Bug 3085

Summary:

folder_item_scan_full() does stupid things with ignored thread marks

Product:

Claws Mail (GTK 2)

Reporter:

Jason <aidenn0>

Component:

UI/Message List

Assignee:

users

Status:

NEW ---

Severity:

minor

Priority:

Version:

3.10.0

Hardware:

OS:

Linux

Attachments:

Description	Flags
Fixes propagation of ignored/watched threads in presence of thread_by_subject	none
Fixes propagation of ignored/watched threads in presence of thread_by_subject (2)	none

Description Jason 2014-02-07 18:21:56 UTC

subject_hastable_lookup and subject_table_lookup are both used, but behave differently.

Personally, I prefer that messages that are identical in subject be threaded together, but either way, it should probably be consistent.

Changing the "if (prefix_length <= 0)" to "if (prefix_length < 0)" in subject_hashtable_lookup gets the behavior that I expected, but I understand if that's not the intended behavior of the feature.

To reproduce, you can have a mailbox with 2 messages with identical subjects, but none of the threading related headers; they will not show up as threaded in the thread view, but they will both be marked as ignored if you select "ignore thread" on one of them.

I noticed also that the code for handling moved messagese uses subject_table_lookup but I'm not sure if any odd behavior happens due to that.

Comment 1 Jason 2014-02-07 19:19:59 UTC

I spoke with paul on IRC about this.

It is intentional that children need to have some sort of prefix in the subject indicating a reply.

However, it is bizzare how folder_item_scan_full tries to propagate ignored thread marks (but not e.g. watched thread marks) and does so only by subject (so not by in-reply-to). And will do so both up and down the thread tree (so if you ignored a sub-thread, congratulations, the whole thread is now ignored -- but only e-mails from people on the thread didn't use in-reply-to.

The correct fix is to rip out that messed up logic, and if it is desired to propagate these marks in scan_full then use the logic for building up threads correctly that is from the threaded view in the summary, then walk the tree and propagte to children.

I can submit a patch that does the "Right Thing" or just rip out the broken ignore-thread code, depending on whether or not people think that unmarked children of {watched|ignored} threads should be marked likewise

Comment 2 Jason 2014-02-21 20:28:59 UTC

Created attachment 1333 [details]
Fixes propagation of ignored/watched threads in presence of thread_by_subject

Comment 3 Jason 2014-02-21 20:48:29 UTC

Ignore my first patch; it propagates even to already existing, unchanged threads.  It's a simple fix to do it to just changed threads, so I'll make that change and add a new patch.

Comment 4 Jason 2014-02-21 21:19:48 UTC

Created attachment 1334 [details]
Fixes propagation of ignored/watched threads in presence of thread_by_subject (2)