[turba] additional contact fields and activesync

[Michael Rubinsky]

Quoting Michael Rubinsky <mrubinsk at horde.org>:

> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>
>> imon Brereton <simon.brereton at dada.net> wrote:
>>
>>>> -----Original Message-----
>>>> From: turba-bounces at lists.horde.org [mailto:turba-
>>>> bounces at lists.horde.org] On Behalf Of lst_hoe02 at kwsoft.de
>>>> Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
>>>>
>>>>> Simon Brereton <simon.brereton at dada.net> wrote:
>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: turba-bounces at lists.horde.org [mailto:tuba-
>>>>>>> bounces at lists.horde.org] On Behalf Of Michael J Rubinsky Ulli
>>>>>>> <ulli_um at arcor.de> wrote:
>>>>>>>
>>>>>>> >I am trying to get more contact fields available in turba und
>>>> sync
>>>>>>> the
>>>>>>> >contact over activesync to my android smartphone.
>>>>>>> >
>>>>>>> >generally the sync works fine with the default turba config.
>>>>>>> >
>>>>>>> >I need more than one e-mail and cell phone field in my contact
>>>>>>> database
>>>>>>> >I found both additional fields(workCellPhone, homeCellPhone,
>>>>>>> >?workemail,
>>>>>>> >?homeemail) in the attributes.php file of turba....therefore I
>>>>>>> >added these fields to the "$cfgSources['localsql']"
>>>>>>> >array of the "backends.php" file of turba.
>>>>>>> >Afterwards I could save more information on each turba contact
>>>> to
>>>>>>> the
>>>>>>> >sql database.
>>>>>>> >
>>>>>>> >But these new fields were not be synced over activesync to the
>>>>>>> >smartphone?
>>>>>>> >
>>>>>>> >by the way, the smartphone does support this fields....
>>>>>>> >--
>>>>>>> >Turba mailing list
>>>>>>> >Frequently Asked Questions: http://horde.org/faq/ To
>>>> unsubscribe,
>>>>>>> mail:
>>>>>>> >turba-unsubscribe at lists.horde.org
>>>>>>>
>>>>>>> AS supports up to three email fields but they are not identified
>>>> by
>>>>>>> home or work. Only as email1 email2 and email3.  Horde currently
>>>>>>> only maps the email1 field.  I could easily add more mappings,
>>>> but
>>>>>>> we need to get a concensus as to which AS email fields are mapped
>>>> to
>>>>>>> which turba fields.
>>>>>>>
>>>>>>> Likewise, the two supported mobile phone fields are known as
>>>>>>> mobilePhone and carPhone (no idea why)...and this is how my
>>>> android
>>>>>>> client refers to them. I know horde maps only one of those,
>>>> though I
>>>>>>> don't recall which one off hand.
>>>>>>
>>>>>> Voting/consensus and open source don't really go hand in hand...
>>>>>
>>>>> I would disagree with you here in general, but that's another
>>>>> discussion ;)
>>>>
>>>>> What I mean in this case is that we should see what the majority of
>>>>> the clients out there treat/label these fields.
>>>>>
>>>>>> I propose:
>>>>>>
>>>>>> email1 = Home
>>>>>> email2 = Work
>>>>>> email3 = Spare
>>>>>
>>>>> What are these mappings based on, observed client behavior?
>>>>
>>>> Some time ago i made a patch for SyncML part to match the Outlookish
>>>> email1,2,3 to Turba and other clients. The problem is that the number
>>>> of supported addresses differ and the sematics also. For the SyncML
>>>> part we have choosen the following
>>>>
>>>> email2 = HOME
>>>> email3 = WORK
>>>>
>>>> email1 ist the default address for clients which don't support the
>>>> HOME/WORK semantics or only have one address per contact. It is also
>>>> used for addresses marked as PREFERED in vCard.
>>
>> I agree with this solution, as it deals with the major reason I  
>> didn't include this to begin with; Turba setups with only a single  
>> email field with making assumptions about the context of the contact.
>>
>> I'll add this when I get back.
>>
>>
>>>> As far as i remember this is close to what Funambol does.
>>>
>>> To answer Michael's question to me - yes.  But then my users are not
>>> particularly corporate by nature.  I imagine corporate installations
>>> would prefer 1 and 2 reversed (for the email anyway).
>>>
>>> However, I agree with Andreas.  I think his suggestion is better (and
>>> since he has a patch already, probably the time to implementation is
>>> shorter).
>>>
>
>
> Done.
>
> https://github.com/horde/horde/commit/f1c16e46c2d83345a4e17787cd9d4abb68434dbd

Missed the client->server mappings:
https://github.com/horde/horde/commit/335a976b494ed1c1631a245780ed6a079869282c


mike

The Horde Project (www.horde.org)
mrubinsk at horde.org