[2.1?] "User xx has blocked your personal message."

Started by kat, June 11, 2012, 04:18:06 PM

Previous topic - Next topic

live627


IchBin™

Yeah but that doesn't keep you from manually typing in the name.
IchBin™        TinyPortal

Suki

#22
Theres gotta be a check right after you click send and before the pm is actually stored on the DB (in theory, right after you got the actual ID or IDs), its not that difficult to apply as there are a lot of checks before the actual pm goes green.

This thing and also adding a check to avoid sending pms yo you (only a warning, because many people do actually send pms to themselves)  are things I want to implement.


Oh, I just realized the whole point is to let the user know before actually write the pm... in that case there are some possibilities to know the actual ID before start writing, the most obvious one is the direct pm this user link, another one is the autosuggest and some JavaScript trickery to intercept the resulting values, as for manually inserting the name, theres no much we can do on it as if the user is manually inserting the name it means that for some reason this user cannot or don't want to run JavaScript on her/his computer.
Disclaimer: unless otherwise stated, all my posts are personal and does not represent any views or opinions held by Simple Machines.

Chas Large

This subject has just cropped up on my site, since we've grown a lot lately due to another site's closure. Quite a few folk are blocking each other then others complain they send a PM only to be told the recipient has blocked everyone.

Can I suggest the feature simply removes any method to send a PM to a user who has chosen to block PMs.

Remove all icons, remove their name from the message recipient check list.

If they want to block everyone then every method to send to them should be removed.

If someone would care to do a quick and dirty mod for me to employ temporarily that would be great ;)
My Modifications :)  My Forum

Please DO NOT PM me with support requests. Post the problem in the appropriate Support Board so everyone can benefit from the advice given.

Arantor


kat

Sometimes, though, you have to get a balance, Arantor.

Try sending Arantor a message, here. ;)

Arantor

*shrug* I make full use of the options I have at my disposal. The fact I prefer to do as much in public as possible should not be a problem, especially for an organisation that claims to be open and transparent ;)

dimspace

im all for it not saying anything at all, just pretending to send it and leaving you none the wiser.

An icon I woiuldnt want because it just draws attention to the fact that someone has blocked you. If two members have a dispute and one blocks the other, drawing attention to it is the last thing you need.

if SMF ever implement an icon that shows who has blocked you can someone write a mod that gets rid of it please? (or should i put a request for a modification that undoes a modification that doesnt yet exist in the random modifications request section)

Arantor

It isn't just a case of 'user xx has blocked your personal message'. There are other circumstances that prompt this message, e.g. the user is banned or the user has requested account deletion. Admins will still  be able to send in spite of these restrictions, however.

The problem with this, though, is that if the message is sent, there is a chance the recipient will never see it. If they are banned/account pending deletion, no notification will be sent of the message. Not even from the admin, in fact.

All these circumstances go through one code path, and two of the three were reported by me as a bug. Long story as to how I discovered this. K@ and some of the others might remember, though.

Changing the behaviour of one implies changing the paths to the others too.

Kindred

I was wondering about performance hits on for this request...  decided to leave it to someone who knew the system a little better.

the first thing that occrued to me was that - if each recipient has to be checked when the author is selecting them, that will actually a a LOT of hits directly into the database. - whereas, if (as now) the check is done when the system is alreayd writing the message to the target user's record in the database, it effect is minimal, because it's alreayd performing several db queries.

I *THINK* this is what Arantor is referring to...   and, honestly, as neat as it might be to do what Chas suggests, I can not see the performance hit (which would have to be done on EVERY PM attempt, whether the user is blocked or not) being worth the minor convenience.
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

Arantor

Actually, not so much. Tying it into the auto suggest is reasonably easy, though not as light as it could be (will require a separate handler in the suggester to specifically check the buddies list for each member that does match, amongst other things)

The real issue I was getting at is the more rigorous checking Chas was suggesting, which means checking every user's buddy list every post as well as checking their PM preferences every post.

EDIT: And their ignore list too.

Chas Large

I see the points and I don't know the full functionality so please forgive my lack of knowledge but I see it like this.

If someone starts to send a PM, the system has to check the recipients username does it not? I assume this is the suggester Arantor mentions, how else how would a deleted member be checked?

So for each topic list of posts the system has to check the user exists anyway and populates the post icons, could a check not be built in there to see if PM is blocked? Surely a call to the current PM checking function that tests for who to receive PMs from is needed which in turn could switch off the icons dependent on that result. Would that hit of 20 to 30 extra calls be so large?

I don't know what function is called to say, place the AIM/ICQ/YIM icons against a post but it must be done for each member for any topic page of posts, maybe adding into that function, the check for recipient of PM could be added? which would lessen the queries used?

My Modifications :)  My Forum

Please DO NOT PM me with support requests. Post the problem in the appropriate Support Board so everyone can benefit from the advice given.

Arantor

QuoteIf someone starts to send a PM, the system has to check the recipients username does it not? I assume this is the suggester Arantor mentions, how else how would a deleted member be checked?

That isn't what I said. There is a world of difference between a deleted member and a member whose account is *pending* deletion. The difference being that in the first case there's no account, and in the second, there *is*. But that also overlooks banned status.

QuoteSo for each topic list of posts the system has to check the user exists anyway and populates the post icons, could a check not be built in there to see if PM is blocked?

You mean the bit I specifically said hurts performance because there's no need to pull any of that normally in the list of posts?

QuoteSurely a call to the current PM checking function that tests for who to receive PMs from is needed which in turn could switch off the icons dependent on that result. Would that hit of 20 to 30 extra calls be so large?

20 calls every topic? Um, yes, it probably would, that's the point.

QuoteI don't know what function is called to say, place the AIM/ICQ/YIM icons against a post but it must be done for each member for any topic page of posts, maybe adding into that function, the check for recipient of PM could be added? which would lessen the queries used?

Um, how does 'no, because I already explained this would be a non trivial performance hit' sound?

Fetching the icon list is easy, it requires almost zero work if you're already fetching the member entry which is already two queries in its own right in a topic view.

Fetching both the ignore list and the buddy list for each person in the topic view, plus the PM preferences is not the same, however. The only question is whether it requires an extra query or two extra queries, plus the attendant processing for EVERY PAGE OF EVERY TOPIC, unless everyone is a guest.

emanuele

All of the things you mention are already known the moment SMF gets the info about a user because they are stored in the members table.

Enable or disable the PM icon on each member in "display" (i.e. topic view) is a pita because:
1) it depends on the settings of the "other" user,
2) it depends on "another table",
3) it may be different for each and every user.

So, to be sure, you have to:
1) check the settings of each user that posted in a topic,
1a) if that user has "allow PM from everybody" you are lucky,
1b) if the user has "no PMs" that's easy too,
1c) if the has "allow PMs only from buddies" SMF has to query *his* buddy list and see if *you* are there
1d) if the user has "don't allow from deny" SMF has to query *his* deny list to see if *you* are these
2) repeat 1 (including either 1a or b or c or d) for each poster in a topic on each and every page load.

Arantor was faster, but I already wrote it, so I posted... :P


Take a peek at what I'm doing! ;D




Hai bisogno di supporto in Italiano?

Aiutateci ad aiutarvi: spiegate bene il vostro problema: no, "non funziona" non è una spiegazione!!
1) Cosa fai,
2) cosa ti aspetti,
3) cosa ottieni.

Chas Large

Obviously "Please please my lack of knowledge" means little and my post was not a criticism but you've obviously taken it that way. I'll bow out now.
My Modifications :)  My Forum

Please DO NOT PM me with support requests. Post the problem in the appropriate Support Board so everyone can benefit from the advice given.

emanuele



Take a peek at what I'm doing! ;D




Hai bisogno di supporto in Italiano?

Aiutateci ad aiutarvi: spiegate bene il vostro problema: no, "non funziona" non è una spiegazione!!
1) Cosa fai,
2) cosa ti aspetti,
3) cosa ottieni.

Arantor

QuoteObviously "Please please my lack of knowledge" means little and my post was not a criticism but you've obviously taken it that way. I'll bow out now.

What I object to is the fact that I'd already implied all this anyway and you're essentially saying 'I don't know much but you might be wrong because <some other stuff>'

Angelina Belle

Arantor, many rather helpful support specialists really don't understand what you imply when you say "Yay for hurting performance!".  The more in-depth explanations you and emanuele gave was really helpful in providing some relative idea of how many additional queries a feature like that would add.

It would take at least 100 hours of study for any one of us to follow the code well enough to begin to ferret out for ourselves what you and emanuele explained.

Speaking for myself, I really appreciate the explanations you two offered.  You two have made it clear that
* "Don't even offer to let me PM someone who has blocked all or blocked me" is NEVER going to be an SMF feature
* There are some other, more reasonable possibilities for checking whether the other member can receive my PM BEFORE I write it, which could be implemented as mods before being considered, in the usual way, for inclusion in some future SMF version.

Thanks
Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

kat

When I made my original post, I assumed, somewhat naively, that the same stuff would have to be queried, whether the thing did it before, or after the message was typed. Using that line of thinking, any performance hit would've occurred, whichever way it's done.

I won't pretend to understand more than a couple of words of what Arantor and Mannykins have said, by way of explanation, though. :)

I might just send a pre-emptive message, in future, simply saying "Testing to see if this is gonna get blocked", before typing a whole message out in another one. ;)

Arantor

QuoteArantor, many rather helpful support specialists really don't understand what you imply when you say "Yay for hurting performance!".  The more in-depth explanations you and emanuele gave was really helpful in providing some relative idea of how many additional queries a feature like that would add.

And more detailed information was provided in a follow-up to that, before we get to it being questioned.

QuoteIt would take at least 100 hours of study for any one of us to follow the code well enough to begin to ferret out for ourselves what you and emanuele explained.

And that's cool. We enjoy this stuff, which is why we do what we do. We do not enjoy having to explain why something is so in minute detail. I had hoped that reply #30 would have sufficed as to the problems inherent in doing this, followed up with "I admit I don't know much but I think you might be wrong because <some other stuff>"

I mean, I could waste even more of my time finding exactly where this stuff is stored (because none of it's documented anywhere, yup, that's right, there is precisely zero documentation on what the database does), to prove my point, but that just wastes even more of my time.

The thing is, pretty much everything that's been said today about how complicated this is was already covered in the page-and-a-half that was already here. All the salient points had already been made already.

Though, let's round it off. Oh, and admins shouldn't be able to be blocked but admins can block in return as far as I remember.

Oh and all this is before you realise that the entire PM code is a complex rat's nest and that changing it is fundamentally nasty.

Advertisement: