[Kolab-devel] Missing implementation for xcard properties

[Christian Mollekopf]

On Thursday 15 March 2012 17.16:00 Thomas Brüderli wrote:
> 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.
> 

It's role. As CCITT.X520.1988 states for Business Category (which is what the 
vcard role is based on):

"The Business Category attribute type specifies information concerning the 
occupation of some common objects, e.g. people."

The title is the specific position within the organization, not the more 
general profession.

I'll specify that more clearly in KEP 17.

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

Indeed. I'll change it to 
setOrganisation(std::string org, vector<std::string> departments)
to be a bit more explicit.

Cheers,
Christian

> >>>> 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
> 
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://www.intevation.de/mailman/listinfo/kolab-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20120316/4c7b067e/attachment.sig>