Re: [O] org-contacts development

[Daimrod]

Michael Strey <address@hidden> writes:

> Hi Daimrod,
>
> On 2014-05-29, Daimrod wrote:
>
>> Hmm, I kinda like this. It seems a bit verbose but it's better than
>> having multiple values per properties (IMHO).
>>
>> Though, if we adopt this scheme, we would need to add some helper
>> bindings/functions so that we don't have to fill this by hands.
>
> I'm using yasnippets and have snippets for organizations, job-related
> contacts and private contacts.
>
> I have attached them.

Thank you!

> C-c C-x p helps to fill in optional properties.
>
> I have all my contacts in one buffer with the following settings
>
>
> #+BEGIN_SRC org
> * Buffer settings
> #+STARTUP: overview
> #+STARTUP: hidestars
> #+STARTUP: indent
> #+TAGS: ADMIN(i) CHEF(f) EINKAUF(k) PRIVAT(t) SEKRETARIAT(s) 
> #+TAGS: AUTO(u) BROADCASTER(b) DAB(d) DVB(v) EMPFNGER(m) HOCHSCHULE(h) 
> NETZBETREIBER(n) SYSTEM(y) B2B B2C REG
> #+TAGS: MAIL(l) PRESSE(e) KUNDE COMPETITOR
> #+TAGS: ABI CI FAMILIE FREUNDE SCHULE TAICHI TURNEN
> #+SEQ_TODO: TODO(t) NEXT(n) WAITING(w) | DONE(d) CANCELLED(c)
> #+PROPERTY: Contact_Type_ALL individual organization
> #+PROPERTY: Language_ALL de en ru
> #+PROPERTY: Phone_1_Type_ALL Work Home Fax Mobile
> #+PROPERTY: Phone_2_Type_ALL Work Home Fax Mobile
> #+PROPERTY: Phone_3_Type_ALL Work Home Fax Mobile
> #+PROPERTY: Phone_4_Type_ALL Work Home Fax Mobile
> #+PROPERTY: Address_1_Type_ALL Work Home Post
> #+PROPERTY: Address_2_Type_ALL Work Home Post
> #+PROPERTY: Address_3_Type_ALL Work Home Post
> #+PROPERTY: Website_1_Type_ALL Work Home
> #+PROPERTY: Website_2_Type_ALL Work Home
> #+END_SRC
>
>
>
>>> Other user defined properties can be added and mapped to the appropriate
>>> user defined keys during export.
>>
>> I'm not sure to understand what you mean. Could you give more details
>> and maybe an example?
>
> Actually, my statement was trivial.  Orgmode allows to define and add
> every kind of additional properties.  What I wanted to say was that it
> is possible to export those additional properties to Google Contacts as
> well.

Ok.

> I have for instance the property :Language: that is not part of the
> Google API.  I use it to store the preferred language of correspondence
> for my job-related contacts for mailing actions.
>
> Google Contacts accepts such fields in the CSV file to import and
> creates user defined fields from them.
>
>
>>> Please note that org-collector tries to convert property values from
>>> strings into numbers if possible.  For postal codes with leading Zeros
>>> this can lead to unexpected results.  I did not find any other way to
>>> solve this problem than to add a national code like in the following
>>> example
>>>
>>> :Address_1_Code:  01169
>>> would lead to "1169" in the propview table.
>>>
>>> so I replaced it with
>>> :Address_1_Code:  DE-01169
>>
>> What is `org-collector' and when does it happen?
>
> From the Orgmode manual:
>
> "An alternative way to capture and process property values into a table
> is provided by Eric Schulte's org-collector.el which is a contributed
> package.  It provides a general API to collect properties from entries
> in a certain scope, and arbitrary Lisp expressions to process these
> values before inserting them into a table or a dynamic block."
>
> I'm using org-collector to create a table that can be exported to CSV
> for import into Google Contacts (and maybe other contact managers).

Ok, I wasn't aware of this.

>> I've done a quick test and the 0 appears in `org-contacts-db'.
>
> Yes, everything is fine with org-contacts.  The problem comes only from
> org-collector.  The reason is org-collector's feature to allow Lisp
> expressions to process property values.  Therefore it uses the function
> `org-babel-read' that detects Lisp expressions and converts strings into
> numbers.
>
> So this remark is only relevant for those who want to follow my track with the
> org-collector export.

I see.

Thanks for you detailed explanation, I'll look at it more carefully this
weekend (hopefully).

Best,

-- 
Daimrod/Greg