On Tue, 2002-12-17 at 19:57, gilbert fang wrote: > 1) If our ldap server has some different attribute name for one > attribute, for example "familyphone" which has the same meaning with > homephone. > How can I make evolution know this attribute and show it in ldap > addressbook? > Do we have to hack the source code?
yes. i've been trying to find time to add in a more extensible scheme for a while now (since before 1.2), but never have enough time. > 2)If we want to extent evolution ldap mapping to multiple mapping, > that is one evo cards attribute <--> two or more attributes of one > ldap entry. > I think at least we have to consider two issues. > 2.1)To make two or more ldap entry attributes mapping to one card > attribute. It seems not difficult. well, that's problematic. I'll use your example (this isn't the best example because you can't have an empty cn attribute, but still). You have cn=gilbert and commonname=gilbert, and you want both to map to Full Name. having to choose between two ldap attributes for 1 field implies an importance weighting, so you decide "cn will be used first, and if it's empty we use commonname." If you bring up the contact editor you'll see "gilbert" in the Full Name field... say you wanted to delete that, so you backspace over gilbert and commit the changed card back to the ldap server (if the string is empty evolution attempts to delete the property iirc). You would expect (since you just deleted the Full Name), that the Full Name field would be empty, but it's not. It now contains gilbert again, even though you just deleted it. > 2.2)To construct the search filter considering conjunct two or more > attributes name for one card attribute. eg. cn=gilert and > commonname=gilbert for card's name. > It seems not easy, and may bring some performance issues. yup. we already have this issue when doing a file_as search, since for ldap servers that don't support it we try to use sn. There are numerous bugs filed because of the way the query for this needs to be generated. It ends up being: (|(fileAs=%s*)(&(!(fileAs=*))(sn=%s*))) Of course, that's not a simple conjunction, but given that some ldap servers already choke on the queries we generate, I don't think making them larger would be a good thing. > Is there any plan for this functions? Could we join and help ? I'm not sure I ever want to support multiple ldap attributes mapping to the same e-card field (because of the bizarre user experience listed above).. But allowing the user to choose which ecard fields map to which ldap attributes, which objectclasses to use, etc.. is still something I plan to do. But no, there's no set plan for implementing them. There's some UI work that Anna did back for 1.2 in ldap-config.glade, but absolutely no code has been written. > 3) By the way, does evolution will support ldap v3? if so, could you > tell me what is the plan? Err, what is evolution doing that's not ldapv3? Chris _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
