Bug 180564 - Inconsistant contact fields in eGroupware/KDE kresource
Summary: Inconsistant contact fields in eGroupware/KDE kresource
Status: RESOLVED WORKSFORME
Alias: None
Product: kresources
Classification: Miscellaneous
Component: egroupware (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Tobias Koenig
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-13 16:26 UTC by Nikolai Försterling
Modified: 2023-01-25 05:06 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 Nikolai Försterling 2009-01-13 16:26:19 UTC
Version:           EGW 1.4 (using KDE 3.5.9)
OS:                Linux
Installed from:    Debian testing/unstable Packages

The most annoying thing to me is the extra-fields' not being consistent in the contacts.
Important (only to me?) are the field definitions and their ability to be the same in EGW and KDE:

"contact image": Would be VERY useful if there'd be a solution to sync or at least having them stored independantly in both, without the need to have a local kaddressbook file just for the pictures ...
Ok, may be hard to do and would blow up everything when syncing, thus making it neglectable compared to the other fields.

"anniversary": Would help to remind wedding days' of my friends if it would work
(ok, field is not present in EGW 1.4)

"partners' name": I often can't remember his/her name ;-)

"job/title": This is inconsistent; "title" in KDE but "job" in EGW and WM5/6 while "job" in KDE stays empty
If i save them in the appropriate (job) field in kaddressbook via xmlrpc, they're shown a while (until next connect), but never really stored in EGW.

contact sort order (with grades):
Even if i manually store the name to be displayed as "common/short name", it is never being stored.
Very annoying. I'd like to have my contacts being stored with their grade, but don't want to search/sort "John Doe" under "M.Sc. John Doe"

IM/ICQ address: offered in both kaddressbook and egroupware cannot be stored; EGW doesn't accept kaddressbook's entry and vice versa.

Contact categories: i assume that WM6's contact application may trash some portion of that, but EGW and KDE are not consistent too.
When selecting categories "friend","business" and "birthday" this is being stored as new category "friend,business,birthday", which i obviously don't want to have.
Very confusing...

Others that are not in sync are "function", "room", and "division" though present in both KDE and EGW.

I don't know whether this all is an issue/task of eGroupware and/or the kresource connector, but i'd really like to have that solved soon ;-)
Comment 1 Nikolai Försterling 2009-01-13 16:32:03 UTC
First i thought about participating on bug #100746, but that one is much too different.
Comment 2 Nikolai Försterling 2009-01-13 16:49:17 UTC
I just comfirmed that these issues are also present in KDE4.1's
Kontact/Kaddressbook/Kresource
Comment 3 Nikolai Försterling 2009-01-15 02:06:29 UTC
Additional:
I'm pretty sure it's a bug, because the fields mentioned are present in EGW thus also via xmlrpc, aren't it?
Comment 4 Ralf Becker 2009-05-10 10:46:51 UTC
Some of the fields mentioned in report exist in newer EGroupware releases (1.4+). But the xmlrpc interface is'nt actively developed since some time (in favor or GroupDAV) and the fields did not exist in EGW by the time the xmlrpc ressource was developed. 
When I developed EGW's new addressbook I created only the mappings for the fields existing before. You can add further fields to the mapping in http://svn.egroupware.org/egroupware/trunk/addressbook/inc/class.boaddressbook.inc.php look at method set_mapping_for_user_agent().
I'm willing to commit these additions to EGW, if someone confirms they are working.
Ralf
Comment 5 at 2011-09-26 19:14:09 UTC
don't know if syncEvolution can act as a workaround: https://bugs.kde.org/show_bug.cgi?id=107681#c6
Comment 6 Andrew Crouthamel 2018-11-06 15:16:12 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 7 Andrew Crouthamel 2018-11-18 03:27:58 UTC
Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand.

Thank you for helping us make KDE software even better for everyone!
Comment 8 Justin Zobel 2022-12-20 22:51:41 UTC
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 9 Nikolai Försterling 2022-12-26 18:42:21 UTC
(In reply to Justin Zobel from comment #8)
> Thank you for reporting this issue in KDE software. As it has been a while
> since this issue was reported, can we please ask you to see if you can
> reproduce the issue with a recent software version?
> 
> If you can reproduce the issue, please change the status to "REPORTED" when
> replying. Thank you!

Sorry for not having replied in 2018.
Around 2011 i decided to no longer use EGW as i found it too elaborate to maintain my contact data there.
And fiddling around with data inconsistencies and partial data loss in combination with SyncML and Akonadi and several clients almost froze my efforts to gain a reliable contact backend.
Now for around 6 years i'm using CardDAV and CalDAV which work ok-ish for my needs, after some reformatting/cleanup and renounced info fields, it is finally ok for me on all my different clients and client programs.

So this may be closed, even if unresolved. 
If it is important enough for other people, they may open own bugs, unfortunately i haven't got enough time to install/setup/test/verify that

Nevertheless: thanks for supporting!
Comment 10 Bug Janitor Service 2023-01-10 05:16:14 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 11 Bug Janitor Service 2023-01-25 05:06:43 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!