Lack of interest Unmerge

This suggestion has been closed automatically because it did not receive enough votes over an extended period of time. If you wish to see this, please search for an open suggestion and, if you don't find any, post a new one.
This suggestion has been closed. Votes are no longer accepted.
hoping to get some traction on it
Suggestions that gain traction generally have a clear and exact explanation of what the functionality would do and why it is useful to have.

I agree that this would be useful to have. Merging content is very destructive if done incorrectly. I once had one of my moderator accounts hacked and the attacker merged all threads in a subforum into one massive thread. There was no way to recover those source threads from the target thread.

Mistakes happen and it would be nice to be able undo those. I think such function should have a time limit of x days. There is no point in tracking what the source thread is for posts that were merged into a target thread years ago. And it would bloat the DB with unnecessary data. So a cleanup of data would be needed after X days.
 
It’s worse than that: if you merge A into B and B into C, to recover A you must undo the B/C merge then the A/B merge, and keep all that history to do so.

And if any of the threads along the way are deleted it might not be recoverable at all unless you keep enough metadata to reconstitute the original thread(s)
 
And if any of the threads along the way are deleted it might not be recoverable at all unless you keep enough metadata to reconstitute the original thread(s)
What if they were deleted permanently or if any of the affected posts were splited by copying them to other threads and editing out disjunct parts or if posts where merged and edited afterwards, or ...

So in theory this is a nice idea but I fear it's just way too complicated with too little to gain.
 
Workaround: after finding the original post and splitting it into a new thread, I loaded a backup and copied thread_id, position from the backup's xf_post table over to the existing database, where post_id = post_id and thread_id = x, and updated the thread_id to the new thread_id.

I rebuilt threads (with positions checked) and all seems well.
 
What if they were deleted permanently or if any of the affected posts were splited by copying them to other threads and editing out disjunct parts or if posts where merged and edited afterwards, or ...

So in theory this is a nice idea but I fear it's just way too complicated with too little to gain.
Exactly. I didn't go into the level of detail you're getting at because I think it gets massively too complicated even before you start peering too deeply into the abyss, but that's exactly what I was getting at.
 
The only way I can see it working is if there were some sort of history being recorded, maybe like a database table which kept track of the original thread numbers. And even then, it would work only on threads merged after the feature was added.

Part of the problem is the merge itself--some staffers don't realize that threads are merged with the post order sorted by date, so it totally upsets conversational flow. The only time I tell staffers to merge threads is if 1) a current thread is merged with an inactive thread, or 2) single posts are merged into an ongoing thread (such as an R.I.P. thread) where there is no flow of conversation. A warning overlay before merging, warning of the dangers, could help. Threads are merged so seldom in any of my forums that it's easy for staff to forget the consequences.
 
Top Bottom