[turba] additional contact fields and activesync

[Simon Brereton]

> -----Original Message-----
> From: turba-bounces at lists.horde.org [mailto:turba-
> bounces at lists.horde.org] On Behalf Of Michael Rubinsky
> 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.

Stellar work Michael - thanks!

I have one more request - which probably belongs on the sync list (if at all, I'm sure it's a client issue and that it shouldn't be the job of the server to fix it, but I think I have more chance of a server fix), so let me know if I should make a feature request somewhere..

Essentially, I store all my contact numbers in the +1/+49/etc format.  Android, for reasons known only to itself likes to interpret only the US numbers and add dashes (so that +1347xxxxxxx on the server becomes +1-347-xxx-xxxx on the phone.  Then when the phone tries to do another sync it's duplicating the contacts in Turba.  I could just let it and delete all the contacts with the old format but this is untidy since numbers from other countries remain +49172xxxxxxx or +3462xxxxxx etc.  Would it be possible to have Turba (I guess) or Sync recognise that +1-347-xxx-xxxx is the same as 1347xxxxxxx and not duplicate the contact?

Thanks.

Simon