6.0.0-beta1
7/9/25

[#11692] Kolab backend: Handling of 'country' field
Summary Kolab backend: Handling of 'country' field
Queue Turba
Queue Version Git master
Type Enhancement
State Resolved
Priority 1. Low
Owners jan (at) horde (dot) org
Requester thomas.jarosch (at) intra2net (dot) com
Created 11/12/2012 (4622 days ago)
Due
Updated 11/27/2012 (4607 days ago)
Assigned 11/23/2012 (4611 days ago)
Resolved 11/23/2012 (4611 days ago)
Milestone
Patch No

History
11/27/2012 04:44:25 PM Thomas Jarosch Comment #7 Reply to this comment
Works great!

11/23/2012 02:22:03 PM Jan Schneider Assigned to Jan Schneider
State ⇒ Resolved
 
11/23/2012 02:21:38 PM Git Commit Comment #6 Reply to this comment
Changes have been made in Git (master):

commit 68e153f2b46789025d71db8f538d9f4d2d1ee37c
Author: Jan Schneider <jan@horde.org>
Date:   Fri Nov 23 15:21:26 2012 +0100

     [jan] Add free-text country attributes and use them in default 
Kolab backend (Request #11692).

  turba/config/attributes.php |   24 ++++++++++++++++++++++++
  turba/config/backends.php   |    8 ++++----
  turba/docs/CHANGES          |    2 ++
  turba/package.xml           |    2 ++
  4 files changed, 32 insertions(+), 4 deletions(-)

http://git.horde.org/horde-git/-/commit/68e153f2b46789025d71db8f538d9f4d2d1ee37c
11/23/2012 02:21:38 PM Jan Schneider Priority ⇒ 1. Low
State ⇒ Assigned
Type ⇒ Enhancement
 
11/20/2012 08:42:37 AM Gunnar Wrobel Comment #5 Reply to this comment
Change 'country' to 'text' in attributes.php:

$attributes['homeCountry'] = array(
     'label' => _("Home Country"),
     'type' => 'text',
     'required' => false,
     'params' => array('prompt' => true)
);

In the long run the Kolab format would need to move this field to a 
reasonable standard. As Jan mentioned: everything else is a mess.
11/15/2012 09:20:53 AM Jan Schneider Comment #4 Reply to this comment

[Show Quoted Text - 10 lines]
Not possible, because the country field is an enum. We may try harder 
to map to Turba values, if that's needed, but the output would always 
be what Turba know. This could be the country name, translated or not. 
The point is that this field is a technical field, not for direct 
human consumption, so using a translated country name makes absolutely 
no sense.
11/15/2012 08:52:47 AM Thomas Jarosch Comment #3 Reply to this comment
DE is at least a standard. Country names aren't. That aside, do the 
other clients at least always use the English country name?
On my German Outlook installation, it uses German country names. Would 
be a bit strange to send a letter from Germany to f.e. Austria with an 
English country name on the envelope.

My primary goal is that horde doesn't trash user data if possible. So 
it would be nice to keep the free text somehow, may be prefixed with 
"Custom: "?

11/14/2012 06:19:30 PM Jan Schneider Comment #2
State ⇒ Feedback
Reply to this comment
DE is at least a standard. Country names aren't. That aside, do the 
other clients at least always use the English country name?
11/12/2012 04:23:28 PM Thomas Jarosch Comment #1
State ⇒ Unconfirmed
Patch ⇒ No
Milestone ⇒
Queue ⇒ Turba
Summary ⇒ Kolab backend: Handling of 'country' field
Type ⇒ Bug
Priority ⇒ 1. Low
Reply to this comment
Hi,

I'm currently testing the interoperability between Horde's Kolab 
implementation and other Kolab clients.

Kolab defines the "country" field just as a text field. Other clients 
(like Outlook) write out the full country name. Horde expects a 
country code, so it will hide/lose the country information.

Two ideas to solve this:
1. Do a country name lookup and try to match it to Horde's convention.
     "Germany" -> "DE".

2. Allow custom strings as with the "category" tag:
     Unknown categories from foreign Kolab clients just get imported.


Problem with the first idea is that another client won't be able read 
back Horde's country code.
So essentially, if the contact gets edited in Horde, the country 
information would change.
-> Probably only idea number two makes sense in the long run.

Thoughts?

Cheers,
Thomas

Saved Queries