Committed to gnome-2-12.
Thanks,
Carsten
Sushma Rai wrote:
mail is not a mandatory attribute, and also
it is not a mandatory field for Evolution
contacts. "mail=*" will not fetch entries
like GroupOfNames or user objects without e-mail ids.
So having a default filter with "mail=*" can not
be done.
Not having "objectclass=person" will return non user
entries also in search operation. It is not a problem
in case of autocompletion, as autocompletion
shows entries having mail ids only.
So, 2 options we have are not having, "objectclass=person" or having
"(objectclass=person)||(mail=*)"
Since there is no support for contact groups
in Evolution 2.4.x, commit the fix with
"(objectclass=person)||(mail=*)" to gnome-2-12 branch
ONLY.
In the head, search filter is now configurable,
so user can set any specific value to it.
Thanks,
Sushma.
"Carsten Guenther" <Carsten Guenther scalix com> 10/25/05 10:33 AM
When picking recipients for a message you are of course only
interested in entries that have a mail attribute set, hence the
"mail=*" filter I suggested in my first patch.
Can someone please make a decision here?
Thanks,
Carsten
On Oct 20, 2005, at 5:18 AM, Sushma Rai wrote:
Hi,
Just having mail=* or as I said (|(objectclass=person)(mail=*) is not
good I feel. For next release (2.5.x) if we plan to support contact
lists, where the objectclass will be groupofnames (for openldap) or
group (for Exchange), etc. will fail again, as they don't (need not)
have mail attribute. And also if we make search filter configurable,
then it can be set as needed.
I am not sure why we need to have "objectclass=person" at all.
I have attached the patch, where I have removed this form the search
filter. With this group objects associated with the e-mail id will
show up with autocompletion.
Please review.
Thanks,
Sushma.
On Mon, 2005-10-10 at 14:12 -0700, Carsten Guenther wrote:
Sure it does, that's the whole point :-)
Maybe we are talking about two different things here. I am talking
about
mailing-lists that are resolved on the server (and that are
maintained
by the server administrator) and where the list itself has an email
address. For example at Scalix we have eng scalix com with alle the
engineers being members, but the email address eng scalix com is
all you
need to write to all the members.
So, obviously the query "objectclass=person" does not cut it because
mailing-lists have objectclass "distributionList" or something
different, depending of the product. But by using "mail=*" you get
every
entry that is adressable, mailing-lists included. BTW, that's how
most
other clients (Thunderbird for exmaple) do it as well.
I am aware that this does not entirely fix the issue "Evolution
does not
deal with LDAP groups", but it is a one-line fix that fixes some
of the
issues and one that can be applied to 2.4 as well (that's what we
actually need).
Carsten
Chris Toshok wrote:
Meaning that when sent the mail doesn't go to all the members of the
ldap mailing list. Or does it?
On Mon, 2005-10-10 at 12:53 -0700, Carsten Guenther wrote:
What do you mean? Changing the search filter to "(mail=*)"
allows me
to search and autocomplete mailing-lists. Autocompletion was the
main
problem for us.
Chris Toshok wrote:
Not really.. what happens when you autocomplete against them?
The
point is just adding (mail=*) to the query doesn't fix the actual
problem, which is that evo doesn't deal with mailing lists on ldap
servers.
On Mon, 2005-10-10 at 12:40 -0700, Carsten Guenther wrote:
With my patch they would show up in addressbook searches. Only
the lists
email address will be displayed though, no membership
information, but
that is fine.
Chris Toshok wrote:
are mailing lists from ldap reflected as contact lists in the
UI. Seems
like you'd want that as well.
On Mon, 2005-10-10 at 12:12 -0700, Carsten Guenther wrote:
Can I commit this?
--
Attached patch fixes 318227. The LDAP search filter used was
limited to
entries with objectclass "person" which prevented searching for
mailing-lists, a problem many people have. The patch changes
the search
filter such that it looks for everything that has the
attribute "mail"
set ("mail=*"). That's basically what Thunderbird and other
clients do
as well.
I think bug 311884 still is valid but can be fixed t a later
point.
Please review for commit to gnome-2-12 and head.
Thanks,
Carsten
_______________________________________________
Evolution-patches mailing list
Evolution-patches gnome org
http://mail.gnome.org/mailman/listinfo/evolution-patches
_______________________________________________
Evolution-patches mailing list
Evolution-patches gnome org
http://mail.gnome.org/mailman/listinfo/evolution-patches
_______________________________________________
Evolution-patches mailing list
Evolution-patches gnome org
http://mail.gnome.org/mailman/listinfo/evolution-patches
Index: addressbook/backends/ldap/e-book-backend-ldap.c
===================================================================
RCS file: /cvs/gnome/evolution-data-server/addressbook/backends/
ldap/e-book-backend-ldap.c,v
retrieving revision 1.50
diff -u -p -r1.50 e-book-backend-ldap.c
--- addressbook/backends/ldap/e-book-backend-ldap.c 4 Oct 2005
07:00:16 -0000 1.50
+++ addressbook/backends/ldap/e-book-backend-ldap.c 20 Oct 2005
11:59:04 -0000
@@ -3216,7 +3216,6 @@ e_book_backend_ldap_build_query (EBookBa
gchar *retval;
EBookBackendLDAPSExpData data;
int i;
- char **strings;
data.list = NULL;
data.bl = bl;
@@ -3248,15 +3247,7 @@ e_book_backend_ldap_build_query (EBookBa
g_list_foreach (data.list, (GFunc)g_free, NULL);
}
else {
- strings = g_new0(char*, 5);
- strings[0] = g_strdup ("(&");
- strings[1] = g_strdup ("(objectclass=person)");
- strings[2] = data.list->data;
- strings[3] = g_strdup (")");
- retval = g_strjoinv (" ", strings);
- for (i = 0 ; i < 4; i ++)
- g_free (strings[i]);
- g_free (strings);
+ retval = g_strdup (data.list->data);
}
}
else {
|
