Anthony Parsons
Well-known member
Yep... confirmed, just tested it. Kicked one user and left myself, it deleted it from the DB.
S
Syndol
Guest
Does anyone require the ability to prevent certain user groups from receiving conversations?
Conversations from Admins and Moderators will still get through.
This will add a ‘Receive personal conversations’ user group permission.
I can see this being useful on a dating type site, but otherwise I'm not sure when you would use it.
How would you use such a permission?
Conversations from Admins and Moderators will still get through.
This will add a ‘Receive personal conversations’ user group permission.
I can see this being useful on a dating type site, but otherwise I'm not sure when you would use it.
How would you use such a permission?
taylor_smith
Well-known member
One way we might use it is to prevent VIP visitors from being inundated with messages. For instance, Richard Garriott is kind of a legend in the gaming industry, as on our forums. He also posts there. To prevent him from being overwhelmed with conversations, I think I've allowed only people that he follows to send him messages. But if I had the option to prevent him from receiving, but allow him to send messages freely, I suppose that'd be more ideal.
S
Syndol
Guest
It seems you want to prevent users from starting convos rather than receive them. That is already available.
S
Syndol
Guest
Thanks for the feedback. I guess the only real difference is that you will then be able to set the permission by user group rather than individually.
S
Syndol
Guest
Currently that is not possible, however, if enough people are interested in this feature I will look into it.
Keep in mind that conversation prefixes are personal in nature.
Keep in mind that conversation prefixes are personal in nature.
Recently we got notified that the info screen in conversations of 2 people sometimes mysteriously show "3" people under "Participants:".
We checked the xf_conversation_master table with the conversation id and really found a "3" in recipient_count.
xf_conversation_receipient holds only 2 peoples data. We also talked to the users and they swear that there were never more than 2 people in that particular conversation.
I know this may be a XenForo bug, but no one mentioned it until now. Since we use Conversation Essentials, this error may be caused by this addon.
Can you please check if there is any possibility (race condition, etc?) that the shown participients could be 3 in conversations of just 2 people? It seems to happen very often and our users are wondering if someone is taking part in their conversations secretly...
Thank you!
We checked the xf_conversation_master table with the conversation id and really found a "3" in recipient_count.
xf_conversation_receipient holds only 2 peoples data. We also talked to the users and they swear that there were never more than 2 people in that particular conversation.
I know this may be a XenForo bug, but no one mentioned it until now. Since we use Conversation Essentials, this error may be caused by this addon.
Can you please check if there is any possibility (race condition, etc?) that the shown participients could be 3 in conversations of just 2 people? It seems to happen very often and our users are wondering if someone is taking part in their conversations secretly...
Thank you!
S
Syndol
Guest
I have never seen this happen before.
Are you able to duplicate this participant count error?
Do you have any other add-ons installed that work with conversations?
Are you able to duplicate this participant count error?
Do you have any other add-ons installed that work with conversations?
I already posted it under "XenForo bugs".
If you have a live forum (with more than just a few conversations) you can check it with the following MySQL query:
Code:
SELECT
xf_conversation_master.conversation_id,
xf_conversation_master.recipient_count,
count(xf_conversation_recipient.user_id) as 'howmany'
FROM
xf_conversation_master, xf_conversation_recipient
WHERE
xf_conversation_recipient.conversation_id = xf_conversation_master.conversation_id
GROUP BY xf_conversation_recipient.conversation_idIf your forum has the same bug, you'll notice that in some lines of the output the second and the third number are sometimes different. Meaning that the real number of participants is different from recipient_count field of that conversation. Which is wrong.
Since the db field recipient_count is modified by core XF code only, it seems to be an XF bug or some weird mysteries in our database.
In our database 2% of all conversations have a wrong (= too high) recipients_count value.
S
Syndol
Guest
OK I have just noticed that when someone leaves a conversation and that conversation receives a reply, the the participant count in the conversation list is increased by 1 but when you enter the conversation the count is the same as always.
The count in the list is where it is wrong since those who leave a conversation still take up a slot in the total conversation recipients (and may even have posts in it).
This does seem to be a core issue and not this add-on but will have to test it on a clean install to confirm.
The count in the list is where it is wrong since those who leave a conversation still take up a slot in the total conversation recipients (and may even have posts in it).
This does seem to be a core issue and not this add-on but will have to test it on a clean install to confirm.
S
Syndol
Guest
I do believe it is a core XenForo issue:
Whenever a reply is inserted into a conversation that includes a user that has "left" the conversation, that user state is then reverted to "active" so that they may view the new response.
The problem is that in order to switch back the user state, the insertConversationRecipient() function is called in function addConversationReplyToRecipients()
insertConversationRecipient() is designed to update a conversation user if one already exists which is great, however, it also increases the xf_conversation_master recipient count by one which is where the problem lies.
Whenever a reply is inserted into a conversation that includes a user that has "left" the conversation, that user state is then reverted to "active" so that they may view the new response.
The problem is that in order to switch back the user state, the insertConversationRecipient() function is called in function addConversationReplyToRecipients()
insertConversationRecipient() is designed to update a conversation user if one already exists which is great, however, it also increases the xf_conversation_master recipient count by one which is where the problem lies.
Apt Irrelevance
Member
Not sure if this was caused by an update or one of the admins just messing with the templates, but we currently see this on the Start New Conversation page:
How would we go about fixing this? (We do have TMS installed.)
How would we go about fixing this? (We do have TMS installed.)
S
Syndol
Guest
It would seem you have both the manual edit as well as the TMS edit applied to template conversation_add
Try reverting the template or if it was customized then remove all code that starts with <!-- ConvEss --> (see the template in the folder Template Edits that came with the zip).
Try reverting the template or if it was customized then remove all code that starts with <!-- ConvEss --> (see the template in the folder Template Edits that came with the zip).
got a userreport, maybe anyone with lots of prefixes can confirm this?
not sure if this is a known issue or not, but when I set Conversation display options to display conversations by prefix, and there are more than fit on one page, when I navigate to the next page the display options are reset, and it displays all conversations
It seems to work ok when you set options to display only conversations sent or received by a user.
S
Syndol
Guest
Thanks for reporting. It is indeed the case.
I shall release an update to fix that.
I shall release an update to fix that.
