Version: 0.7.1 (using KDE 3.1.3) Installed from: compiled sources Compiler: gcc version 3.2.2 OS: Linux (i686) release 2.6.0-test4 When given the alternative to view or ignore a contact messaging you that's not on your list, it would be nice to have a 'block' option for people like messenger@microsoft.com, sexywebcom52353, etc. This would alleviate the need to add keep the user for a time and then block them in a second step.
anyway, in CVS, you do not receive messages from messenger@microsoft.com and you have an option to automaticaly block all contact who are not in your MSN contactlist *** This bug has been marked as a duplicate of 57234 ***
Wrong, this bug is NOT a duplicate of that bug. That bug requests a way to block everyone not on your contact list, which is a feature possible in AIM that I *hate*, and not what I want. I want merely a way to block a *sender* at the point in time that they send me the very first message that creates the balloon-tip with the other two buttons on it.
In MSN you can simply block it. And the bug 57234 include also the bug 58276 and all theses duplicated bugs are about to request a plugin who filtre messages
Okay, so this wishlist item depends on bug 58276 (basic contact-blocking capability), but this item is specifically for an ignore button on the balloon-popup, and is not a duplicate of either other report.
> In MSN you can simply block it. And would you care to explain this? I keep getting the message from Microsoft every time I fire up Kopete. If I could block it, that would be great.
Hehe, because microsoft don't allow you to block microsoft ;-) Update to kopete 0.7.2 and you will not receive anymore theses messages
Again, this item is specifically for an ignore button on the balloon-popup, and is not a duplicate of either other report. Reopening.
There is *already* an ignore button on the balloon popup. Anyway, you will nto receive anymore messages from microsoft staff so you can block msn people. and you can block msn people not in your contactlist all in one (CVS) So i don't think this is an issue.
This bug report has nothing to do with Microsoft. I was just using it as an example because that's what was annoying me at the time. I also get a lot of random messages from nicks like 'sexygirl536' etc. There is a button to ignore just that message, but there is not a button to block the sender of the message from sending any further messages.
do you want this balloon to take all your screen? how many button do you want here? does sexygirl536 send you so many messages? generaly with spam, it's only once.
> do you want this balloon to take all your screen? Is that what I asked for? No. I asked for one more small button. > how many button do you want here? Three. > generaly with spam, it's only once. I don't know what sort of spam you've been getting, but apparently it's a world different from my spam. Not only that, but old contacts might message you, or people you recognize pestering you from some new account, etc. There's all sorts of reasons people want to block messages. Anyways...when I think more on it, all I really want is an easier way to block unwanted people with the minimum effort required. Right now it's painfully difficult. Click View, up pops a new window/tab - Click Chat, click Contacts, click the Contact name, click Block - close Window. That's six steps :\. If there could be a toolbar icon in single-user chats for Block, that would cut the number of steps in half, which would be a huge improvement. Not quite as convenient as a single-step, but perhaps single-step doesn't really make sense for this option, since it would be too easy to click by mistake instead of View, and I'm not sure how one goes about unblocking people.
ever thought about clicking on the contact list entry? block is in the contacts context-menu if the protocol supports blocking.
> ever thought about clicking on the contact list entry? block is in the > contacts context-menu if the protocol supports blocking. Yes, I did, before I found the obfuscated block option in the chat window. But it seems *really* rediculous to have to add a contact to my list before I can block them. That's quite a number more steps. Sure they show up for a moment as "not in list" but they disappear when I click Ignore, and I shouldn't have to click View to bring up a window just so I can close it just so I can have the user temporarily in the contact list so that I can delete them that way. It's just messy.
What about a per-protocol / per-single|group chat toolbar extension, since all of the protocols might support different things that should be conveniently accessible? GAIM has a nice obvious Block button in any given chat dialogue, which appears for protocols that support it in single-user mode. So does the official AIM, and a few other messagers I've used. When you want to block somebody, you don't want to spend 5 minutes hunting for where the feature is. I found it, but it took a couple minutes. It's certainly less intuitive for less persistant users.
*** Bug 90756 has been marked as a duplicate of this bug. ***
I don't understand why blacklist is implemented protocol specific? Why should not it be implemented in kopetelib? Moreover, this way the block is done per contact. In kopetelib it could be done per metacontact. This makes more sense, as if I would like to block someone, I would block all the contacts he posesses. What do you think, gentlemen? BTW at the moment I elegantly ignore the problem of blocking users not in list without adding them.
On October 5, 2004 05:20 pm, Roie Kerstein wrote: > 22:20 ------- I don't understand why blacklist is implemented protocol > specific? Why should not it be implemented in kopetelib? It needs ot be protocol specific because some protocols, like MSN, ICQ, support server-side ignore, whil eothers do not. What should be done is, there is a b"blacklisting interface", with a defaul timplementation in libkopete that just uses a list of some osrt. Then the protocols can re-impliment it if they desire for their own server-side methods.
I know that, but I don't take this as a reason. In my opinion, when we get a spam message, kopete can quietly discard it, and let the spammer bang his head in the wall (does not sound so good in english :(). No spammer will ever send so many messages, in a manner that can effect the performance of kopete or the network bandwidth. Therefore, ignoring them will do no harm from the point of view of our kopete user, in which we have interest. I will implement the blacklist of metacontacts in libkopete. I will not touch the protocol-specific blocking, as these may co-exist. Any objections?
CVS commit by lilachaze: Added section about a blacklisting interface, and my comments on it, after a quote from Jason. CCMAIL: 63839@bugs.kde.org M +15 -0 API-TODO 1.16 --- kdenetwork/kopete/libkopete/API-TODO #1.15:1.16 @@ -238,2 +238,17 @@ contactable contact; the invitaiton is transported to Kopete. - in Kopete, in the chat window, an "tools" menu, with all possible actions. + + + + Blacklist support: +==================== + +<brunes> What should be done is, there is a "blacklisting interface", with a + default implementation in libkopete that just uses a list of some + sort. Then the protocols can re-implement it if they desire for their + own server-side methods. + +<lilachaze> Implementation: I'm thinking of a class Blacklister, and a function + Blacklister &KopeteAccount::blacklister(). Seems cleaner than having + the default implementation in KopeteAccount, which would smell of + Refused Bequest.
See also bugs 64163 and 81510. Note that IRC really needs more than just blacklisting at the contact level (I forgot about this).
On October 6, 2004 06:32 pm, Richard Smith wrote: > Note that IRC really needs more than > just blacklisting at the contact level (I forgot about this). What did you mean by this Richard? I don't see how IRC is different than any others in this respect. Unless you mean it needs the ability to also do ignores on host-based wildcards like other clients. I would purport that this would already fit into the existing proposed APIs that take a QString contactId - a QString that could just as easily contain *@foo.com. It would be up to the implimenting class - aka IRC account - to interpret this string, so it would work fine.
so, where IS this blacklisting thing? it's been 14 months since the last comment on this bug.
Been ASSIGNED for too long.
*** Bug 64163 has been marked as a duplicate of this bug. ***
*** Bug 121043 has been marked as a duplicate of this bug. ***
*** Bug 121365 has been marked as a duplicate of this bug. ***
Is this issue about a non-protocol-specific blacklisting feature, or about the sorely missed "block" option in chat boxes ?
both, it seems; as well as about a "block messages from people not in contact list by default" feature...
On Tuesday, 11 בApril 2006 08:43, Mathias Homann wrote: > ------- both, it seems; Is anyone working on any of these features ? > as well as about a "block messages from > people not in contact list by default" feature... I thought this is already implemented ?
if this has been implemented by now, it has been hidden very well...
I don't see any blocking function for ICQ in teh menus... and I get lots of spam from automated spam bots using the ICQ protocol... they use a bunch of ICQ accounts, but always the same ones... this is annoying, can someone please implement a proper blocking feature for ICQ? I'm using version 0.11.2 (Debian unstable), btw...
Blocking function for ICQ is implemented in version 0.12
then when will 0.12 be released? with kde4? and will this icq blocking also help me with blocking anyone that is not on my contact list? because, i'm getting 5-10 icq spams from unknown and constantly changing senders, which makes it rather useless to block one specific uin.
Turn off your web presence (universal messaging center or something) option in the icq prefs. It's off by default afaik. When you set it properly you won't be able to see your online presence on the web, and the spam magically disappears.
in yahoo i keep getting stupid spam from bots - why can't we have a simple "block/ignore" button in a chat window? now if i want to block a contact i first have to add this contact to my friednlist- but why do I have to have bots in my friend list only to block them?
thats why i keep saying a "block non-contacts by default" option is needed...
No ,You misunderstood me. I want people that are not on my contact list to be able to message me but as soon as i find out that they're NOT my old forgotten friends or some new friends i want to be able to block them without adding them to my contactlist
if anyone would actually be willing to look into this, instead of holding pseudo-religious discussions about it, we could even have both: 1. a global config option "block people not on my contact list" 2. a "block this sender" button on the message popup (which obviously would work only with 1. turned off).
SVN commit 577924 by duffeck: Import Privacy Plugin into svn. This plugin allows flexible filtering of messages by sender and/or by content. FEATURE: 63839 M +1 -0 CMakeLists.txt A privacy (directory) AM privacy/CMakeLists.txt AM privacy/kopete_privacy.desktop AM privacy/kopete_privacy_config.desktop AM privacy/privacyconfig.kcfg AM privacy/privacyconfig.kcfgc AM privacy/privacydialog.ui AM privacy/privacymessagehandler.cpp [License: LGPL (v2+)] AM privacy/privacymessagehandler.h [License: LGPL (v2+)] AM privacy/privacyplugin.cpp [License: GPL (v2+)] AM privacy/privacyplugin.h [License: GPL (v2+)] AM privacy/privacypreferences.cpp [License: GPL (v2+)] AM privacy/privacypreferences.h [License: GPL (v2+)] --- trunk/KDE/kdenetwork/kopete/plugins/CMakeLists.txt #577923:577924 @@ -14,6 +14,7 @@ add_subdirectory( alias ) add_subdirectory( addbookmarks ) #add_subdirectory( statistics ) +add_subdirectory( privacy ) if( LIBXML2_FOUND AND LIBXSLT_FOUND ) add_subdirectory( webpresence ) ** trunk/KDE/kdenetwork/kopete/plugins/privacy/CMakeLists.txt #property svn:executable + * ** trunk/KDE/kdenetwork/kopete/plugins/privacy/kopete_privacy.desktop #property svn:executable + * ** trunk/KDE/kdenetwork/kopete/plugins/privacy/kopete_privacy_config.desktop #property svn:executable + * ** trunk/KDE/kdenetwork/kopete/plugins/privacy/privacyconfig.kcfg #property svn:executable + * ** trunk/KDE/kdenetwork/kopete/plugins/privacy/privacyconfig.kcfgc #property svn:executable + * ** trunk/KDE/kdenetwork/kopete/plugins/privacy/privacydialog.ui #property svn:executable + * ** trunk/KDE/kdenetwork/kopete/plugins/privacy/privacymessagehandler.cpp #property svn:executable + * ** trunk/KDE/kdenetwork/kopete/plugins/privacy/privacymessagehandler.h #property svn:executable + * ** trunk/KDE/kdenetwork/kopete/plugins/privacy/privacyplugin.cpp #property svn:executable + * ** trunk/KDE/kdenetwork/kopete/plugins/privacy/privacyplugin.h #property svn:executable + * ** trunk/KDE/kdenetwork/kopete/plugins/privacy/privacypreferences.cpp #property svn:executable + * ** trunk/KDE/kdenetwork/kopete/plugins/privacy/privacypreferences.h #property svn:executable + *
lemmy@gildor:/usr/src/packages/SOURCES> LANG="" svn co svn://anonsvn.kde.org/home/kde/branches/kopete/0.12 svn: URL 'svn://anonsvn.kde.org/home/kde/branches/kopete/0.12' doesn't exist
> ------- Additional Comments From admin eregion de 2006-08-28 13:08 ------- > lemmy gildor:/usr/src/packages/SOURCES> LANG="" svn co svn://anonsvn.kde.org/home/kde/branches/kopete/0.12 > svn: URL 'svn://anonsvn.kde.org/home/kde/branches/kopete/0.12' doesn't exist\ 0.12 is back in kde, just check it out from the same place as kdenetwork. http://kopete.kde.org/svnaccess.php
This code will not be in KDE 3.5. It's KDE 4 only.