It's missing an update to the topics table with their new date/time/subject etc of the new latest post in the topic.

Both with merged topics and merged posts.

I just ran into this bug when trying to merge a post and its replies to another topic.

In threaded mode, the thread structure looks fine but in flat mode, the order is out of whack.

blaaskaak, do you have a manual fix for this?

No...

When you merge topics, in flatmode the order that the topic is shown is in the original posting order.

It's not that topic A is appended to topic B, they are merged, as in mixed together if both topics ran simultaniously.

The bug repored is about when you merge topic A to topic B, topic B's last post date/time/subject is not updated to reflect the latest topic in that topic.

Hmm, maybe I'm reporting a different bug then?

Here's what happened with me. I had two topics, say topic A and topic B.

Topic A had 6 replies:

A.0, A.1, A.2, A.3, A.4, A.5

Topic B had 0 replies (i.e. just the single post):

B.0

I merged Topic A to Topic B, and when viewing the end result in Flat Mode, I got the following:

A.0, B.0, A.1, A.2, A.3, A.4, A.5

What I expected to see was:

B.0, A.0, A.1, A.2, A.3, A.4, A.5

Looking in showflat.php, I notice that the main query just sorts by the Post ID, which is effectively sorting chronologically:



But this doesn't guarantee that the main parent post of a topic gets displayed first! As shown in my example above.

So I changed it such that the main parent post will always appear first, and then the remaining posts are in chronological order:



So, I still think I have found a bug in that the parent post (where POST_IS_TOPIC=1) isn't gauranteed to display first in Flat Mode.

Don't know if you can consider it a bug. Merging is merging, 2 seperate topics become one. The only difference in merging topic A to B or B to A is the one that might get "This topic has merged" topic.

In flatmode, the normal vieworder is chronologically, so I think it works as designed.

What could be doable is an extra option called "Append topics", where a topic is appended to the target topic.

In normal day life, this isn't so much of a bother to use. We mainly use merge when somebody opens a new topic when there is already an older one about the same subject. You just merge them, and no troubles there (well, except bug #1 in this topic).

Consider this then:

• You're viewing the post list in the Changelog forum
• You click on the topic titled "Current Changelog" started by Rick
• The next thing you see is Rick's post, as expected. But it appears half-way down the page.
• When you scroll up you see there are other posts before Rick's.

Bug or not a bug?

Who started the topic?

p.s. assume there are no new posts in the thread, and the posts appearing before Rick were not posted by him.

My situation

Topic 1
Topic 2
Topic 3
Topic 4
Topic 5
Topic 7
Topic 8
Topic 9

Merge topic 2 into topic 8... result:

Topic 1
Topic 3
Topic 4
Topic 5
Topic 7
Topic 8
Topic 9

Topic 8 should be on the spot where topic 2 used to be.

Yeah, what I think we're going to have to do is actually create an entirely new topic out of the merged topics. Right now we're just changing the topic id of the posts, and it's leading to some inconsistencies with how the merged topics are displayed.

Rick, I actually think I might have fixed this in 7.3. We just needed to run rebuild_topic_data($topic_id) for the topic that was merged into.

Ah cool, thanks Ian

actually I'm not as sure now. I know it recalculates the last poster info, but it might not recalculate the topic starter info.

from what i've tested, we still have a wee bit of work to do. and we need to do it in two places, since inline moderation has it's own body of code.

meh, still calls rebuild_topic_data, so we'd probably either modify that function or give it a helper function.

Merge for me works like expected. 2 topics get merged together. Appending topic A to B would be a different function.

i'm ok with that. makes a lot of sense to use one routine or routine + helper for both.

what i really would want at some point is to join the bodies themselves as much as can be. prime example is PMing a user on topic move/merge. right now one body does it, but the other doesn't and if we keep adding ancilliary stuff to them, it would be wise to get as much in common as possible to begin with.

I still maintain that "merge to" implies some kind of parent and child relationship.

In other words, I would expect merge topic A to topic B to yield a different result to merging topic B to topic A. The main difference being that the topic being merged "to" is the parent.

But from what you're saying, you expect the result to be the same.

My only issue is that the parent, or very first post, of the topic you're merging "to" isn't upheld if one of the merged posts happens to be newer.

Just a note ive noticed a bug within a hidden forum set up
ive posted it here. Click Me