Bug 223757 - Define fields shared between different contacts
Summary: Define fields shared between different contacts
Status: RESOLVED INTENTIONAL
Alias: None
Product: kaddressbook
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-22 09:25 UTC by Dotan Cohen
Modified: 2010-06-20 13:31 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dotan Cohen 2010-01-22 09:25:53 UTC
Version:            (using Devel)
Installed from:    Compiled sources

Please add an option to let the user define a field's value in terms of a soft link to the value of the same field of a different contact. Often two contacts have the same personal information. For instance, a married couple would have the same anniversary date, and likely the same home phone number and home address as well. When this is the case (when there is a soft link between contacts' fields), updating one contact's info should update the other's.
Comment 1 Dotan Cohen 2010-01-22 09:26:02 UTC
An additional benefit of this would be to prevent duplicate anniversary notifications in Korganizer.
Comment 2 Dotan Cohen 2010-01-22 09:33:31 UTC
Note that this feature request is in response to Tobias' order to refile feature requests from the old Kaddressbook against the new Kaddressbook. Here are the relevant bugs that were closed in the old Kaddressbook:

https://bugs.kde.org/show_bug.cgi?id=199997
Comment 3 Will Stephenson 2010-03-03 21:06:03 UTC
'Interesting' to implement, because the shared information becomes a property not of the individual contacts but of the relation, for example the marriage of two individuals or the address of a shared workplace.  This could be realised by making more use of Nepomuk semantic relations as the objects operated on in by KAddressbook, and other apps, but that's a long way off.  The first uses will be to link existing contacts that represent the same person.
Comment 4 Tobias Koenig 2010-06-20 13:31:45 UTC
Hej,

our internal data structure is not designed to allow sharing of fields and properly will never be, because it causes more problems (conflict handling on changes, synchronization, import/export) then it actually solves.
A PIM solution that is based on a database and is an isolated application might work, however Akonadi is highly integrated in various PIM systems so we have to make compromises.

Ciao,
Tobias