[Kolab-devel] Missing implementation for xcard properties

[Christian Mollekopf]

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".
I'm open for better suggestions =)

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.

>>
>>> 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.

Cheers,
Christian

> ~Thomas
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://www.intevation.de/mailman/listinfo/kolab-devel