Rejoining a conversation you have left

lazy llama

Well-known member
Is there any way to rejoin a conversation which you have left and selected the "no responses" option?

Some of our users use conversations as an informal private thread, but want to stop receiving responses when they are away on holiday etc. If they leave, as far as I can see, there's no way back in, other than by me changing their status directly in the database.

I guess they should just turn their notifications off while they're away but I wouldn't have thought being able to rejoin a conversation would be a completely unusual thing.
 
That isn't available to my knowledge. There's the '[tLk] ReadPC' addon and then there's the way that Jake Bunce mentions, where you login to your server and just mass-delete all PM's to start over - as far as I know about ;-)
 
Rather old thread, but it just greatly helped to confirm what I needed to do when trying to shoehorn one of our mods back into a PM he had left.

I can sort-of see why the system doesn't entirely delete the user from the conv info (basically it's about privacy regarding the fact that the user has left it) but it's really unfortunate that - at least in XF 1.5.x - there seems to be NO way for a user who actually wants to rejoin a conv to do so without direct database manipulation.
Is this still the case in XF 2?

I would have thought that a fresh invitation ought to work (especially if issued by an admin), but it doesn't. I haven't entirely worked out which bit of code the invitation calls, but it seems likely that the "deleted_ignored" state gets noticed and this aborts the insertion process.

For the record, I had to update the recipient_state to 'active' in xf_conversation_recipient, and then (the bit that eluded me at first!) also insert an entry for him in xf_conversation_user. (Having read the code, I now wonder if it might have been enough to change the state from "deleted_ignored" to "deleted" and then issue a new invitation, but I didn't try that.)

Incidentally, I'm really puzzled about the apparent redundancy of most of the information in the xf_conversation_user table. The first three fields and the last one clearly need to be there, but all of the other columns (that's reply_count, last_message_date, last_message_id, last_message_user_id, last_message_username) appear to be identical for every recipient of the conv. I assume I must be missing the point here somehow?
 
Top Bottom