[Kolab-devel] Missing implementation for xcard properties

[Thomas Brüderli]

Christian Mollekopf wrote:
> On 2012-03-14 17:26, Thomas Brüderli wrote:
>> 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?
>>
>
> Well, the approach would be to create a dummy affiliation to be able to
> set the profession somewhere.
> It's not like you can only have one profession per person, so that
> makes sense to me. Maybe don't call the organization "profession" then
> (a bit strange indeed), but something like "Private".

And which property of the affiliation block would then contain the 
profession? Role? Title? None of the existing ones seems appropriate to me.

> I'm open for better suggestions =)

Kontact seems to use X-KADDRESSBOOK-X-Profession in vcards. Would a 
custom property be the equivalent to that in xcard?
>
> It would also be possible to add a role field outside of the
> affiliation, but that would seem a bit strange as well.
>
>> BTW: I forgot to mention the 'department' property from the old
>> format
>> which also has to find it's place in the new format.
>>
>
> Department is part of org. The first text value denotes the
> organization, further values the organizational units within that
> organization.

In that case we need to change Affiliation::setOrganisation() to accept 
a vector<std::string> instead of only a single string.
>
>>>> 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?
>>
>
> Yes, that certainly only meant for the migration. Not as field we
> actually maintain.
> Kontact doesn't have initials, and I don't think initials are important
> enough to do anything special about them.
> I'd like to drop initials and have nickname only.

That's fine with me.

~Thomas