[turba] additional contact fields and activesync

[Michael J Rubinsky]

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).
>
>One more thing to consider is that a lot of phone OSs have the concept
>of a default number (equivalent to the "preferred email") - it would be
>nice to support this too.

It would be nice, but the AS protocol does not provide support for this.

--
Mike
Sent from mobile