GNOME Bugzilla – Bug 618787
Allow to block specific contacts
Last modified: 2011-03-17 01:17:44 UTC
Karmic/Lucid Empathy does not provide a function to block contacts in my address book with servers (protocols) accepting blocking. e.g. MSN accepts blocking, Yahoo accepts blocking, Google (jabber) accepts blocking, Facebook (jabber) accepts blocking, Jabber.org (jabber), I guess, does not accept blocking. It is a high privacy concern. E.g. on the weekend I want to chat with my personal contacts with Empathy but I want to block my working contacts. On the weekend, I want to be available for my working contacts, but I don't want to be available for my personal contacts. Other patterns can apply. Ubuntu-Linux Karmic/Empathy 2.28.x Ubuntu-Linux Lucide/Empathy 2.30.x
What does this has to do with blocking messages? You want to be invisible instead to certain groups it seems. Different issue.
How do you call when a contact in your contacts list cannot see you and contact you? Blocking? Invisible? I have used blocking because (as far as I can remember) that was the option available on msn messenger in the contacts list i.e. allow/block per contact. Your comment says "invisible to certain group", but it more on a per contact basis. Thanks
I think we should elevate this bug. There aren't any more info that the reporter can give. Empathy does not have the "block" feature. This means that you cannot block a person in your contact list from seeing when you are online and talking to you. It's a feature provides by all major messaging clients. I also think that it is a very important feature. It provides the user with privacy control among the people in his contact list. Can anyone please change the status of this bug to NEW and its importance to HIGH (I would say its PRIORITY=HIGH and SEVERITY=HIGH).
the problem--if I am correct--is blocking is a server side feature, not a client feature. Some protocols allow blocking a contact in your contact list (you are invisible to them) e.g. msn, yahoo. But some protocols do not, e.g. jabber. It would be nice if Empathy was providing a "block this contact" menu option for the protocol supporting this feature.
Well I guess it'd be smart to raise this on the empathy mailing list. Anyway, reopening for now as I think the feature request is clear. A maintainer has to set to NEW if it's a bug worth fixing. Or set to WONTFIX if it isn't.
Let's be clear: - bug #618787 is about blocking a specific contact (using https://bugs.freedesktop.org/show_bug.cgi?id=28423) - bug #551911 is about adding a "Block contacts not in my contact list" option
Created attachment 180261 [details] [review] contact blocking support http://git.collabora.co.uk/?p=user/danni/empathy.git;a=shortlog;h=refs/heads/contact-blocking This is an implementation of contact blocking using the old 'deny' channels (since the new interface hasn't yet been merged). It should be simple enough to port this to the new interface in the future.
In addition to the dialog, we need to add a Block button to the subscription dialog, and a Remove and Block button to the remove dialog. I have a patch for the first one, it just needs testing. However the second one seems tricky, how do we handle metacontacts where not all of the individual Connections support contact blocking?
Review of attachment 180261 [details] [review]: Ideally I'd like to have some tp-glib API for this but I guess this is blocked by https://bugs.freedesktop.org/show_bug.cgi?id=26205 "make check" doesn't pass. You should update POTFILES.in ::: libempathy-gtk/empathy-contact-blocking-dialog.c @@ +35,3 @@ +#include <libempathy/empathy-debug.h> + +#define GET_PRIVATE(o) (EMPATHY_CONTACT_BLOCKING_DIALOG (o)->priv) We don't use a PRIV macro any more with the new pattern; just use self->priv->badger directly. @@ +37,3 @@ +#define GET_PRIVATE(o) (EMPATHY_CONTACT_BLOCKING_DIALOG (o)->priv) +#define DECLARE_CALLBACK(func) \ + static void func (GObject *, GAsyncResult *, gpointer); This will ignore any error from _finish functions. I usually prefer logging those. @@ +44,3 @@ +struct _EmpathyContactBlockingDialogPrivate +{ + GHashTable *channels; /* TpConnection* -> TpChannel* */ Please specify that both objects are owned. Also, explaining the semantic of this hash table would be nice. @@ +60,3 @@ +get_pretty_conn_name (TpConnection *conn) +{ + return tp_proxy_get_object_path (conn) + strlen (TP_CONN_OBJECT_PATH_BASE); Maybe that's something we could add to tp-glib? @@ +149,3 @@ + g_hash_table_remove (self->priv->channels, conn); + + /* set the filter again to refilter the account list */ This look like something that should be done automatically by the account chooser. @@ +184,3 @@ + + /* we only care about changes to the selected connection */ + /* FIXME: can we compare proxy pointers directly? */ tp-glib doesn't guarantee proxy uniqueness atm, so no. @@ +235,3 @@ + } + + accounts = tp_account_manager_get_valid_accounts (TP_ACCOUNT_MANAGER (am)); Those accounts have already TP_ACCOUNT_FEATURE_CORE prepared; see TP_ACCOUNT_MANAGER_FEATURE_CORE doc.
For some reason all my accounts were greyed in the accounts chooser, so none was selected. I tried to add a contact and got this crash: tp-glib-CRITICAL **: tp_cli_connection_call_request_handles: assertion `TP_IS_CONNECTION (proxy)' failed aborting... Program received signal SIGTRAP, Trace/breakpoint trap. 0x00007fffee341440 in g_logv (log_domain=0x7ffff2d8650a "tp-glib", log_level=G_LOG_LEVEL_CRITICAL, format=0x7fffee3bcb38 "%s: assertion `%s' failed", args1=0x7fffffffcf40) at gmessages.c:553 553 G_BREAKPOINT (); (gdb) bt
+ Trace 225871
Ideally we should be able to block a contact directly from the UI: - When receiving a subscription request. - Maybe in the chat window? It would also be nice to see in the contact info (dialog and tooltip) if a contact is blocked.
(In reply to comment #9) > ::: libempathy-gtk/empathy-contact-blocking-dialog.c > @@ +35,3 @@ > +#include <libempathy/empathy-debug.h> > + > +#define GET_PRIVATE(o) (EMPATHY_CONTACT_BLOCKING_DIALOG (o)->priv) > > We don't use a PRIV macro any more with the new pattern; just use > self->priv->badger directly. This is just a macro to set up the cast for me when @self is the wrong type. > @@ +37,3 @@ > +#define GET_PRIVATE(o) (EMPATHY_CONTACT_BLOCKING_DIALOG (o)->priv) > +#define DECLARE_CALLBACK(func) \ > + static void func (GObject *, GAsyncResult *, gpointer); > > This will ignore any error from _finish functions. I usually prefer logging > those. I don't understand what you mean. > This look like something that should be done automatically by the account > chooser. I don't see how. We could have a refilter() method though.
(In reply to comment #11) > Ideally we should be able to block a contact directly from the UI: > - When receiving a subscription request. See comment #8 > - Maybe in the chat window? Yeah, that's a good idea. > It would also be nice to see in the contact info (dialog and tooltip) if a > contact is blocked. Which tooltip? They will no longer be in the contact list.
(In reply to comment #12) > > We don't use a PRIV macro any more with the new pattern; just use > > self->priv->badger directly. > > This is just a macro to set up the cast for me when @self is the wrong type. fair enough. > > @@ +37,3 @@ > > +#define GET_PRIVATE(o) (EMPATHY_CONTACT_BLOCKING_DIALOG (o)->priv) > > +#define DECLARE_CALLBACK(func) \ > > + static void func (GObject *, GAsyncResult *, gpointer); > > > > This will ignore any error from _finish functions. I usually prefer logging > > those. > > I don't understand what you mean. Ignore me, I read it too quickly and thought it was a macro defining the function, not just declaring it. > > This look like something that should be done automatically by the account > > chooser. > > I don't see how. We could have a refilter() method though. Most (all?) the filters of the accounts chooser are checking connection features, so I thint it would make sense to always update in that case. > > It would also be nice to see in the contact info (dialog and tooltip) if a > > contact is blocked. > > Which tooltip? They will no longer be in the contact list. We can't have a contact in our contact list while him being blocked? I think the official MSN client does that. (In reply to comment #8) > In addition to the dialog, we need to add a Block button to the subscription > dialog, and a Remove and Block button to the remove dialog. > > I have a patch for the first one, it just needs testing. > > However the second one seems tricky, how do we handle metacontacts where not > all of the individual Connections support contact blocking? Humm, display a tooltip saying we can just block the contact on some of the connection and accept user if he wants to block anyway?
(In reply to comment #14) > > > It would also be nice to see in the contact info (dialog and tooltip) if a > > > contact is blocked. > > > > Which tooltip? They will no longer be in the contact list. > > We can't have a contact in our contact list while him being blocked? I think > the official MSN client does that. I suppose we could, but I wouldn't have thought it was wanted. Why do you want to look at the names of people you've blocked? The one CM I tested it with looks like it removes blocked contacts from publish/subscribe (it's possible this is because blocking a contact is a subscription state, I didn't check why it was happening).
I think it is desirable. For example is my contact list i have my job colleagues and my boss. When i'm not at work i wish to block them and unblock them the next time i am at work.
Created attachment 180366 [details] [review] updated patch Fixes the review issues from the first patch. A second branch will be coming which adds blocking to other places in the user interface.
Review of attachment 180366 [details] [review]: There are still 3 FIXME; what about those?
Created attachment 180554 [details] [review] 3rd patch http://git.collabora.co.uk/?p=user/danni/empathy.git;a=shortlog;h=refs/heads/contact-blocking-2 This further branch resolves those 3 FIXMEs (it's actually the last commit), plus adds block buttons to the subscription dialog, remove dialog and empathy-chat-window's contact menu. [Everything up to danni/contact-blocking is the code already reviewed from the last patch.]
Review of attachment 180554 [details] [review]: Looks pretty good. Feel free to merge once you have fixed the leak. master and gnome-2.34 please. ::: libempathy-gtk/empathy-contact-menu.c @@ +259,3 @@ + + manager = empathy_contact_manager_dup_singleton (); +empathy_contact_block_menu_item_toggled (GtkCheckMenuItem *item, manager is leaked.
(In reply to comment #20) > ::: libempathy-gtk/empathy-contact-menu.c > @@ +259,3 @@ > + > + manager = empathy_contact_manager_dup_singleton (); > +empathy_contact_block_menu_item_toggled (GtkCheckMenuItem *item, > > manager is leaked. I don't think it is... finally: g_object_unref (manager);
Created attachment 180636 [details] [review] part 2 http://git.collabora.co.uk/?p=user/danni/empathy.git;a=shortlog;h=refs/heads/contact-blocking-3 Following on from UI discussion with Sjoerd, here is 4 more commits so that Empathy always asks you to confirm blocking. The confirmation dialogs also include the ability to ask if you want to mark a contact as abusive. There is currently no backend support for this, because we haven't got any spec/CM support yet, but we will need it, so we may as well get the translatable strings in now.
This has been merged to gnome-2-34. master has diverged a bunch, merging it will be actual work which I'm not doing on Friday night.
Created attachment 180797 [details] [review] part 3 http://git.collabora.co.uk/?p=user/danni/empathy.git;a=shortlog;h=refs/heads/report-abuse This 3rd part uses the new Conn.I.ContactBlocking draft to report abusive contacts. Since the interface is still in draft, it only tries to use it for abuse reporting, hence this is not a complete port to Conn.I.ContactBlocking. This branch bases on a branch called 'conference' which is a backporting of the switch to the real Chan.I.Conference, that I noticed was lacking from Empathy 2.34.
Review of attachment 180797 [details] [review]: Looks good!
Thanks :) Now someone just needs to find the time/energy to forward port this to master.
Chandni has begun porting this to master in her branch glassrose/contact-blocking-rebase. Review so far: --- a/libempathy/empathy-individual-manager.h +++ b/libempathy/empathy-individual-manager.h @@ -36,6 +36,17 @@ G_BEGIN_DECLS #define EMPATHY_IS_INDIVIDUAL_MANAGER_CLASS(k) (G_TYPE_CHECK_CLASS_TYPE ((k), #define EMPATHY_INDIVIDUAL_MANAGER_GET_CLASS(o) (G_TYPE_INSTANCE_GET_CLASS ((o) +typedef enum +{ + EMPATHY_INDIVIDUAL_MANAGER_NO_FLAGS = 0, + EMPATHY_INDIVIDUAL_MANAGER_CAN_ADD = 1 << 0, + EMPATHY_INDIVIDUAL_MANAGER_CAN_REMOVE = 1 << 1, + EMPATHY_INDIVIDUAL_MANAGER_CAN_ALIAS = 1 << 2, + EMPATHY_INDIVIDUAL_MANAGER_CAN_GROUP = 1 << 3, + EMPATHY_INDIVIDUAL_MANAGER_CAN_BLOCK = 1 << 4, + EMPATHY_INDIVIDUAL_MANAGER_CAN_REPORT_ABUSIVE = 1 << 5, +} EmpathyIndividualManagerFlags; This typedef accidentally got dragged back in. It should be removed. ~ We should wait for her to rebase danni/report-abuse on top of this branch before merging the whole thing.
Branches rebased and ready for final review in http://gitorious.org/glassrose-gnome/empathy/commits/contact-blocking-rebase and http://gitorious.org/glassrose-gnome/empathy/commits/report-abuse
This looks good. We're currently in string freeze, so merging this requires an exception* from the release time or waiting until we branch for empathy-3.2. * if we do ask for an exception, we should also include the contact blocking parts of [1] which also needs review for gnome-2-34. [1] http://git.collabora.co.uk/?p=user/danni/empathy.git;a=shortlog;h=refs/heads/dialog-tweaks
There are also two patches in Chandni's branch that should be backported to gnome-2-34. I'll take care of that.
(In reply to comment #30) > There are also two patches in Chandni's branch that should be backported to > gnome-2-34. I'll take care of that. Actually scratch that. They're not required on gnome-2-34.
Ok, here are the two useful commits out of dialog-tweaks rebased onto chandni's branch: http://git.collabora.co.uk/?p=user/danni/empathy.git;a=shortlog;h=refs/heads/glassrose-contact-blocking-rebase
I requested a freeze exception.
Granted and merged :) \o/