[horde] Extra ActiveSync attributes from iOS
Michael J Rubinsky
mrubinsk at horde.org
Wed Jul 20 14:01:51 UTC 2011
Quoting Simon Wilson <simon at simonandkate.net>:
> Now that I have ActiveSync working nicely, I'm in the process of
> switching my wife's huge set of contacts into Horde for ActiveSync.
> She has a very broad usage of contacts - many phone numbers,
> addresses, postal addresses, etc. Natively It's not going to work.
> Sooooo....
>
> When an iOS device connects contacts to Activesync it announces a
> set of capabilities (fields).
>
> From what I can see an Activesync field needs to be mapped in
> turba/lib/Driver.php to a valid and defined Turba attribute
> (turba/config/attributes.php). Turba then needs to have a defined
> place to put the data (e.g. an SQL database with a field defined in
> turba/config/backends.local.php).
>
> Am I correct so far?
Sounds right.
> From digging through I get the following default mappings:
>
> iOS Field => Turba attribute => mySQL
> -------------------------------------------------------------
> Anniversary => anniversary => NONE
> Birthday => birthday => object_bday
> Body => notes => object_notes
> WebPage => website => object_url
> BusinessCountry => workcountry => object_workcountry
> Department => department => NONE
> Email1Address => email => object_email
> Email2Address => homeEmail => NONE
> Email3Address => workEmail => NONE
> BusinessFaxNumber => fax => object_fax
> FileAs => name => array
> FirstName => firstname => object_firstname
> HomeCity => homeCity => object_homecity
> HomeCountry => homeCountry => object_homecountry
> HomeFaxNumber => NONE => NONE
> HomePhoneNumber => homePhone => object_homephone
> Home2PhoneNumber => NONE => NONE
> HomePostalCode => homePostalCode => object_homepostalcode
> HomeState => homeProvince => object_homeprovince
> HomeStreet => homeStreet => object_homestreet
> BusinessCity => workCity => object_workcity
> MiddleName => middlenames => object_middlenames
> MobilePhoneNumber => cellPhone => object_cellphone
> Suffix => nameSuffix => object_namesuffix
> CompanyName => company => object_company
> OtherCity => NONE => NONE
> OtherCountry => NONE => NONE
> CarPhoneNumber => NONE => NONE
> OtherPostalCode => NONE => NONE
> OtherState => NONE => NONE
> OtherStreet => NONE => NONE
> PagerNumber => pager => object_pager
> Picture => photo => object_photo
> Title => namePrefix => object_nameprefix
> BusinessPostalCode => workPostalCode => objectworkpostalcode
> AssistantName => assistant => NONE
> AssistnamePhoneNumber => NONE => NONE
> LastName => lastname => object_lastname
> Spouse => spouse => NONE This one is
> advertised by iOS, but there's nowhere to enter / view
> BusinessState => workProvince => object_workprovince
> BusinessStreet => workStreet => workstreet
> BusinessPhoneNumber => workPhone => object_workphone
> Business2PhoneNumber => NONE => NONE
> JobTitle => title => object_title
> YomiFirstName => NONE => NONE
> YomiLastName => NONE => NONE
> RadioPhoneNumber => NONE => NONE
> IMAddress => NONE => NONE
> IMAddress2 => NONE => NONE
> IMAddress3 => NONE => NONE
> ManagerName => NONE => NONE
> CompanyMainPhone => NONE => NONE
> NickName => should be alias => object_alias, but not mapped
> in Driver.php.
>
> Where there is a Turba attribute but no SQL mapping it's an easy
> fix, just create the field in SQL and go for it, but where it is not
> mapped in Driver.php it's a bit more complex.
>
> What I would like to do is add some support for some of the missing
> pieces into Driver.php, particularly the third address group
> (other), and some extra phone numbers. Is this just a case of adding
> both direction mappings to the ActiveSync Contact message sections
> of Driver.php (Convert contact to an AS contact message; and convert
> an AS contact message into a hash for import)? Or are there other
> places that will need work?
That should work, assuming you add the appropriate attribtues to
turba/config/attributes.php and have a field to store the values in.
Also, you should read through the mapping code in Turba_Driver::,
there are already some cases where the mappings don't neccessarily
work as you would expect, I don't have the code in front of me at the
moment, but IIRC, the email mappings are not a 1:1 mapping as you show
above. If the work/home email fields are presented, then *only* those
are used ... otherwise the "plain" email field is used.
Finally, I'd have to verify that all of those fields are supported by
the version of AS that is supported by Horde (some AS fields were
introduced in later versions). I assume they are since the device
should know what version it's using, but I'd have to check the wbxml
codepages to be sure.
> If I make those changes to Drivers.php I assume it's not a
> "Drivers.local.php" version, which means next upgrade will break my
> changes - is it worth me doing those and submitting a patch file
> back to Horde?
The bottom line is, if the changes you introduce do not conflict with
any existing mappings and make sense, then they can be included in
future releases.
Thanks!
--
mike
The Horde Project (www.horde.org)
mrubinsk at horde.org
More information about the horde
mailing list