Michael Strey <mst...@strey.biz> 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