As designed Merging with Poll

FredC

Well-known member
Dont know if its a bug or designed. But since i wasn't expecting these results when i merged a thread with a poll into a thread without a poll... The poll was removed and apparently the data in that poll was lost forever i assume? If this is designed i would suggest possibly some kind of warning dialog or possible options built in to deal with how to proceed with the poll..

To be clear (im sure its somewhat obvious but i digress) the thread with the poll was merged into the destination thread which had no poll before or after the merge..
 
If you want the poll to remain, you have to merge with that thread as the destination.
That's a workaround if I've ever heard one.

Honestly fixing this seems stupid easy, I'm surprised this behavior hasn't changed in 1.1, 1.2, or 1.3. Is there something more to it than changing some ids around and maybe rebuilding some cache items?
 
It is actually pretty trivial.

I created an add-on for it that allows you to add a new poll to any existing thread. It's literally a new controller action, with a load of code copy/pasted from the add-thread action, a copy and paste of parts of the create thread template, and that's about it. I added some permissions (add poll to own thread, add poll to any thread etc.).

In other words, all that is required is the thread discussion_type changes to 'poll' and the poll data is added to the appropriate poll tables in the database.
 
If you want the poll to remain, you have to merge with that thread as the destination.
Yeah I kinda got that now after the data was forever lost.. I can't believe this is being swept under the rug as designed.. Lame excuse for unexpected loss of any data.. I would have expected a prefix of future fix or won't fix however as designed is lame.
 
The poll will still be in the database. It should be quite a simple adjustment to get it showing.

What is the old thread ID, new thread ID and the poll ID?
 
The poll will still be in the database. It should be quite a simple adjustment to get it showing.

What is the old thread ID, new thread ID and the poll ID?
I have no idea, it's gone. Wasn't aware these were things I needed to keep logs of during a thread merge.. One would think a merge would merge all data not just some.. Especially without some type of warning dialog..

I get that this is likely one of those accidents one only makes once.. But as designed seems a bit of a stretch.
 
I'm trying to help you. The poll is likely still in the database but associated to the old thread.

Can you locate it in the xf_poll table? What is it's poll_id?
 
The poll will still be in the database. It should be quite a simple adjustment to get it showing.

What is the old thread ID, new thread ID and the poll ID?
I do appreciate the time you have taken to help me retrieve my lost poll data but fortunately in this case it was unimportant off topic content barely worth retrieving.
 
I was going to look into this anyway, but I was actually mistaken. The poll associated with the source thread is deleted when the merging happens.
 
"As Designed" ? What an absolute load of rubbish. No software should purge data without any warning or confirmation.. especially during an operation that should just unify the data.

I really can't imagine anyone finds that behavior acceptable.
 
"As Designed" ? What an absolute load of rubbish. No software should purge data without any warning or confirmation.. especially during an operation that should just unify the data.

I really can't imagine anyone finds that behavior acceptable.

What happens if multiple threads being merged have their own poll?

If I start a thread that does not have a poll, and you start a very similar topic later that has a poll, what right does a moderator have forcing a poll on to my thread when I clearly did not want one? Or should my thread be taken away because yours has a poll?

Simple solution:
Tell your moderators not to merge threads that contain a poll, unless the destination thread already contains a poll (and the other thread(s) do not). If they fail to comply, remove them from being a moderator.

Moderators are suppose to take the time to ensure they are taking proper action, and to understand the result of their actions. If they can not understand what the result of their actions may be, they should ask first. If they do not take the time to ask, remove their moderator rights.
 
What happens if multiple threads being merged have their own poll?

If I start a thread that does not have a poll, and you start a very similar topic later that has a poll, what right does a moderator have forcing a poll on to my thread when I clearly did not want one? Or should my thread be taken away because yours has a poll?

Simple solution:
Tell your moderators not to merge threads that contain a poll, unless the destination thread already contains a poll (and the other thread(s) do not). If they fail to comply, remove them from being a moderator.

Moderators are suppose to take the time to ensure they are taking proper action, and to understand the result of their actions. If they can not understand what the result of their actions may be, they should ask first. If they do not take the time to ask, remove their moderator rights.
This....
No software should purge data without any warning or confirmation..
 
What happens if multiple threads being merged have their own poll?

Then, and only then, should the destination poll be kept, and not without a big fat warning and confirmation that you're destroying data. Ideally the moderator should be able to select one to keep but I don't expect that to happen until poll management is expanded.

If I start a thread that does not have a poll, and you start a very similar topic later that has a poll, what right does a moderator have forcing a poll on to my thread when I clearly did not want one? Or should my thread be taken away because yours has a poll?

Just about every single right I can think of. That's like asking what right a moderator has to merge your thread with another in the first place. If the poll doesn't contribute to the purpose of your thread, they serve different purposes and shouldn't be merged. If it does then it shouldn't matter. How's that for moderators taking the time to ensure they're making the right decisions?

Simple solution:
Tell your moderators not to merge threads that contain a poll, unless the destination thread already contains a poll (and the other thread(s) do not). If they fail to comply, remove them from being a moderator

You're missing the point. Any software that completely removes data without so much as a single word about it is doing something fundamentally wrong. This has nothing to do with whether or not the issue can be worked around.

I don't know what perfect world you live in but people make mistakes and the software should account for that.
 
@Mike can you please confirm this is indeed intended behavior? I feel the prefix of as designed is short changing the devs and the software..
 
Whenever you have a 1:1 relationship and you try to combine information, there will be potential for data loss. This can be seen very simply with thread prefixes for example: the target thread wouldn't inherit a source prefix. This follows on to various other pieces of thread-level data like stickiness and thread state. "Discussion types" (which polls are) work like this as well. It's the same if you were to merge a resource thread as a source thread; it would lose the association with the resource. (This case is even trickier because the association is bidirectional so keeping the information isn't automatically trivial.)

So it is the expected behavior, yes. If you wish to petition for a change, please post a suggestion. (I suspect it may have been suggested already.)
 
I was going to say I think it was Brogan who suggested this, a very long time ago. ;)

I still think at the bare minimum there should be a warning on merge that says data loss may occur, and that the absence of one should be considered a bug.

What would really be nice at some point is a system to resolve such merge conflicts, so you can cherry pick what data to keep.
 
Back
Top Bottom