[Kolab-devel] Missing implementation for xcard properties

[Thomas Brüderli]

Christian Mollekopf wrote:
> On 2012-03-14 14:28, Christian Mollekopf wrote:
>> On 2012-03-14 12:36, Thomas Brüderli wrote:
>>> Hello Christian
>>>
>>> What's the development status of xcard helper structs like Related
>>> and Crypto? They both exist but don't still lack implementation.
>>>
>>> In order to successfully map all contact properties from the old
>>> format
>>> (and the Roundcube UI) I'd need them to be functional anytime soon.
>>>
>> Ok, on it.
>>
>>> And there are some more contact fields from the old format which
>>> don't yet
>>> have an equivalent in the new format: 'profession' and 'initials'
>>> Shall they be handled with a CustomProperty?
>>>
>> For the profession I suggest creating an affiliation with the name
>> "profession", and setting the role with the content of 'profession'.
>> This way the property remains in the same place for KAddressBook
>> (business tab, Profession field). On that note, I noticed that I need 
>> to update the affiliation section in the docs.
>> I will make the org property optional, and define a default 
>> affiliation
>> with the name "profession" for clients which support only one
>> affiliation. Such as KAddressBook.
> 
> I'm sorry, that didn't make sense. The name of the group is of course 
> fixed to "Affiliation".
> We need a default name for the org property instead, which is where I 
> suggest to put "business" (doesn't really matter what you put there 
> though).
> For full support of the format Roundcube will need to support multiple 
> affiliations with editable org-names.

Sorry but I guess I don't understand your suggestion. Doesn't the org
property contain the actual organization name? How does the profession
property fit into this affiliation block?

BTW: I forgot to mention the 'department' property from the old format
which also has to find it's place in the new format.

> 
>> I'm not quite sure about initials.
>> I think we could allow for several nicknames, and then just append 
>> the
>> initials as nickname.
>>  From the RFC: "It can also be used to specify a familiar form of a
>> proper name specified by the FN or N properties."
>> Otherwise we would need another x-property and I don't see that
>> justified here.

That sound's pretty hackish to me. The nickname solution could be good
enough for the migration from the old format, though. But then the client
should not display a dedicated field for initials. Otherwise the order of
nodes becomes important if we declare the first <nickname> to be the real
nickname and the second to contain the initials. And what if initials are
set but no nickname?

~Thomas