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

[kat]

Bloody silly that you're told that AFTER you've typed it and not before, doncha think?

[IchBin™]

How does it know who you're sending it to until you hit send?

[LiroyvH]

It could perhaps use something ajax'ey to check if the username you have in the receivers list has ****** blocked.
Probably a bad idea though.... speaking of overhead.

[emanuele]

Why this is in site stuff and not feature requests?

[Oldiesmann]

At least it tells you... It could always just silently drop the message altogether while still acting like it was sent...

[kat]

How does it know who you're sending it to until you hit send?

If you click "Send a message" from their profile, it could check, no?

If you click "Reply", it could check, no?

If you type the name in, it might be a tad more difficult, I guess.

[IchBin™]

How does it know who you're sending it to until you hit send?

If you click "Send a message" from their profile, it could check, no?

If you click "Reply", it could check, no?

If you type the name in, it might be a tad more difficult, I guess.

Better yet don't even show a send message link if someone has blocked you.

[kat]

That'd work!

[Angelina Belle]

That would be confusing, though, wouldn't it?
"Where'd the Personal Message icon go?".

Perhaps better to show an icon with a circle/slash through it and an alt text of"User XX has blocked your personal Message".
Same sort of thing when viewing a profile -- "Send personal message" could not be allowed to disappear, but would be greyed out and have the comment "User has blocked your personal message" appended.
There would be some additional overhead associated with that, as this is currently not checked on every single Display.php and every single profile.php

Then, in the suggestions (for To and BCC alike), you'd need a way to "gray out" names that have blocked you, rather than making them disappear completely.

If you make things disappear completely, you will confuse the users.

[LiroyvH]

Perhaps better that if you click it it runs a quick check.
That will save running queries each time a profile is loaded as well, no? Only runs a extra query when you click the button.

[Angelina Belle]

Perhaps better that if you click it it runs a quick check.
That will save running queries each time a profile is loaded as well, no? Only runs a extra query when you click the button.

Probably.
As for the suggest list -- probably the same.  Adding a field (which would require 2 extra joins, I think) to the big query, vs. doing a quick check each time a name is clicked.

The question is -- which is more important.  The server's time and effort or the users' time and effort. Strangely, the answer might depend on how close the forum owner is to monthly limits...

[Suki]

You still need to check on the actual page since the button isn't the only way to send a pm.

Loading the extra info on every users (Load.php) and do a quick check should be fine.

[kat]

which is more important.  The server's time and effort or the users' time and effort. Strangely, the answer might depend on how close the forum owner is to monthly limits...

If you type a long message, it kinda makes you want to kick something, with things the way they are.

[emanuele]

The icon would solve just part of the issue.

Apart from the fact I don't remember how blocking PMs works, the original idea could be good: since we are already querying the database for the autosuggest function, it wouldn't be too difficult to find out if the user is ignoring you or not at that step and then show a warning.

May I move this to feature requests?

[kat]

Yeah, 'course!

I was only thinking of having it here, really. But, thinking about it, it ought to be a standard thing.

[Angelina Belle]

Agree.  Because the site team very rarely approves mods and other customizations not available in standard SMF.

[ApplianceJunk]

which is more important.  The server's time and effort or the users' time and effort. Strangely, the answer might depend on how close the forum owner is to monthly limits...

If you type a long message, it kinda makes you want to kick something, with things the way they are.

Keep your PM's short and to the point.
Maybe people won't want to block them then.

j/k

[Suki]

Is not only for private messages, that is just a side effect of ignoring the user or one of the consequences of setting your pm settings to admin's pms only.

[kat]

Keep your PM's short and to the point.

I'm English.

We waffle a lot.

[Akyhne]

Bloody silly that you're told that AFTER you've typed it and not before, doncha think?

I know that member XX, he has blocked my PM's too

[live627]

How does it know who you're sending it to until you hit send?

autosuggest

[IchBin™]

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

[Suki]

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.

[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

[Arantor]

Yay for hurting performance!

[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.

[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?

[Arantor]

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?

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.

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?

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?

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?

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

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?

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...

[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.

[emanuele]

You asked for clarifications.

[Arantor]

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.

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

[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]

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.

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

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.

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.

[SMiFFER]

How does it know who you're sending it to until you hit send?

Simple! When you enter the name in "To/CC/BCC" !!!!!
(Even an autocomplete is there, why not such check?)

[Kindred]

It could perhaps use something ajax'ey to check if the username you have in the receivers list has ****** blocked.
Probably a bad idea though.... speaking of overhead.

[SMiFFER]

Better yet don't even show a send message link if someone has blocked you.

That is the BEST and only logic idea! Well thought!!!

[Bigguy]

Why not instead of a send message link there is a you've been blocked message. Or just blocked text.

[Kindred]

It could perhaps use something ajax'ey to check if the username you have in the receivers list has ****** blocked.
Probably a bad idea though.... speaking of overhead.

[Irisado]

Raising this topic once to post very little in the way of content was just about okay, but twice is pushing the envelope too far, so I'm locking it.