Hey, That seems like a reasonable solution. Would you mind opening a bug report about it and attaching a more fully-developed patch which documents the behaviour and adds a test case (using the dummy backend) please? https://bugzilla.gnome.org/enter_bug.cgi?product=folks For example, please consider how the ‘*’ anti-link gets added to a persona. It shouldn’t be added to new personas by default (as the auto-linking functionality in folks is there by design, and I believe it’s useful — the situations you described in your first e-mail are very rare, in my experience, and patches are always welcome to improve the heuristics to reduce their occurrence). The ‘*’ anti-link can’t be used with AntiLinkable.[add|remove]_anti_links() because that operates on Personas: some new utility methods would have to be added to AntiLinkable to make use of it: • AntiLinkable.add_wildcard_anti_link() • AntiLinkable.remove_wildcard_anti_link() The behaviour of AntiLinkable.remove_anti_links() with wildcard-anti-linked personas would have to be decided. For example, if I do (in pseudo-code): persona.add_wildcard_anti_link(); persona.remove_anti_links ({ "some-persona-uid" }); assert (persona.has_anti_link_with_persona ("some-persona-uid")); should I expect the assertion to succeed or fail? If the assertion succeeds, then AntiLinkable.remove_anti_links() needs to convert a wildcard anti-link into the complete set of persona UIDs before removing the requested anti-links. But the assertion failing is counter-intuitive. At the very least this needs documenting. I’ll review any patch as soon as I can once it’s on Bugzilla. Thanks! Philip On Sat, 2014-02-08 at 13:21 -0200, Renato Filho wrote:
I have this one line patch that solve my problem and help me to remove more than 200 lines of code from my application. diff --git a/folks/anti-linkable.vala b/folks/anti-linkable.vala index 93a82c7..cbff5aa 100644 --- a/folks/anti-linkable.vala +++ b/folks/anti-linkable.vala @@ -93,7 +93,8 @@ public interface Folks.AntiLinkable : Folks.Persona */ public bool has_anti_link_with_persona (Persona other_persona) { - return (other_persona.uid in this.anti_links); + return ("*" in this.anti_links) || + (other_persona.uid in this.anti_links); } /** On Fri, Feb 7, 2014 at 5:16 PM, Renato Filho <renato filho canonical com> wrote:Hi guys, I am working on ubuntu phone contact app, and we need a way to prevent folks to auto link personas. In the phone application the designers does not want that the contact get merged automatically because the user can have added the same e-mail by mistake or the personas are different but have the same phone number. And the auto merge can cause confusion for the user. My idea is keep using folks, but turn off the autolink, this way I can use folks to find the potential matches and link it if the user explicitly request that. The problem is that folks does not provide a way to do that today. I have some ideas that I would like to share with you guys and if possible I can implement it. 1) Create a property on persona store/backend/individual aggregator: Create a bool property on the aggregator where you can set if you want the auto-link on or off. 2) Create a anti link rule: After create the persona set a anti link rule that block the persona to get linked with any other. Eg: Persona.change_anti_links(['*']) These are my ideas, I would like to know what do you think about that, any other idea is welcome. I really need this functionality, because workaround it doing anti links after the persona get linked causes a lot of problem and complex code. Thanks Renato_______________________________________________ folks-list mailing list folks-list gnome org https://mail.gnome.org/mailman/listinfo/folks-list
Attachment:
signature.asc
Description: This is a digitally signed message part