[Kolab-devel] Missing implementation for xcard properties
bruederli at kolabsys.com
Thu Mar 15 17:16:00 CET 2012
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
>>>>> (and the Roundcube UI) I'd need them to be functional anytime
>>>> 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
>>>> This way the property remains in the same place for KAddressBook
>>>> (business tab, Profession field). On that note, I noticed that I
>>>> to update the affiliation section in the docs.
>>>> I will make the org property optional, and define a default
>>>> 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
>>> fixed to "Affiliation".
>>> We need a default name for the org property instead, which is where
>>> suggest to put "business" (doesn't really matter what you put there
>>> For full support of the format Roundcube will need to support
>>> 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
>> 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
>> 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
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
>>>> 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
>> enough for the migration from the old format, though. But then the
>> should not display a dedicated field for initials. Otherwise the
>> order of
>> nodes becomes important if we declare the first<nickname> to be the
>> nickname and the second to contain the initials. And what if initials
>> 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.
More information about the devel