Bug 223757

Summary:	Define fields shared between different contacts
Product:	[Applications] kaddressbook	Reporter:	Dotan Cohen <kde-2011.08>
Component:	general	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED INTENTIONAL
Severity:	wishlist	CC:	tokoe, wstephenson
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	Unspecified
Latest Commit:		Version Fixed In:

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