Bug 2079198

Summary: Editting of an existing contact creates another entry with empty content.
Product: [Fedora] Fedora Reporter: Lukas Ruzicka <lruzicka>
Component: gnome-contactsAssignee: Kalev Lember <klember>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 36CC: awilliam, bcotton, fedoraparked, gnome-sig, klember, kparal, ndegraef, nielsdegraef, robatino
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: AcceptedFreezeException RejectedBlocker
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-05-25 19:33:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1953786    
Attachments:
Description Flags
The video of the situation.
none
contacts with same email none

Description Lukas Ruzicka 2022-04-27 07:48:53 UTC
Created attachment 1875257 [details]
The video of the situation.

Description of problem:

When users want to edit an existing contact (add a record to it), the action creates a new (empty) contact with the same name, so it looks like there are suddenly two same contacts in the contact list, one is empty and the other is the original (now updated) contact.

Version-Release number of selected component (if applicable):
gnome-contacts-42.0-1.fc36.x86_64

How reproducible:
Always

Steps to Reproduce:
1. See the attached video.

Actual results:

An updated contant gets doubled.

Expected results:

The contact should be updated with no issues.

Comment 1 Fedora Blocker Bugs Application 2022-04-27 07:51:06 UTC
Proposed as a Blocker for 36-final by Fedora user lruzicka using the blocker tracking app because:

 I am proposing this as a blocker because it might violate the Basic functionality criteria.

Comment 2 Kamil Páral 2022-04-27 08:28:19 UTC
I can confirm this problem. However, it seems to happen only if you change the email, changing other fields doesn't trigger it. Also, after you restart the application, the duplicate contact is gone, and there's only one contact with the correct (updated) email.

Comment 3 Kamil Páral 2022-04-27 10:04:42 UTC
Created attachment 1875308 [details]
contacts with same email

The email handling is even more confusing. A probably-related issue: Instead of editing the email, if you instead create a new contact with the same email (intentionally or by accident), then you'll see the contact *description* (and not just name) duplicated. Each section is there twice, once normally and once under "Local Contact". The displayed name randomly switches between the first and the second contact name. If you delete the contact, one of two things randomly happen: a) both contacts are deleted b) only one contact is deleted, and the second one appears after a while in your address book with its original details.

I can split this into a separate bug if you want. But it might be caused by the same problem - broken email handling.

Comment 4 Ben Cotton 2022-04-27 15:50:18 UTC
I see what you mean. I'm inclined to say create a separate bug for this. It may be the same problem or it may not. In any case, I voted -1 for blocking on this based on comment 0, but I'm leaning toward +1 for a comment 3 bug. So at least for the purposes of the blocker process, it's probably better to split them.

Comment 5 Niels De Graef 2022-04-28 13:00:17 UTC
Hi, Contacts maintainer here (who didn't follow fedora BZs about it until now):

When you start up gnome-contacts, does it give you a warning (sometimes after a few seconds) from libfolks about some E-D-S store not being found?

After that, can you go to the "Change Addressbook" dialog and see if any addressbook is checked?

If any item is selected, I would suspect it's because the "local address book" is checked. Can you confirm?

Comment 6 Kamil Páral 2022-04-28 13:24:34 UTC
(In reply to Niels De Graef from comment #5)
> When you start up gnome-contacts, does it give you a warning (sometimes
> after a few seconds) from libfolks about some E-D-S store not being found?

I don't see any message in journal from gnome-contacts of libfolks, if I just start the app and wait.

> After that, can you go to the "Change Addressbook" dialog and see if any
> addressbook is checked?

Local Address Book is checked (no other is available). [1]

> If any item is selected, I would suspect it's because the "local address
> book" is checked. Can you confirm?

Yes.


[1] Please note that there's a little bug when starting gnome-contacts for the first time. It allows you to select address book, and local address book seems to be checked, but you can't continue, until you click on it at least once. I believe the item is not really checked, it just looks checked. The issue is even more visible if you add an online account before hand - if you click on the online address book in the initial dialog, you can see both items checked, local and online. But I don't think this affects anything, I think it's just a UI-related glitch.

Comment 7 Ben Cotton 2022-04-28 19:18:59 UTC
In today's Go/No-Go meeting, we agreed to reject this as a blocker and accept it as a freeze exception. This falls outside of "basic functionality", but is worth fixing if possible
https://meetbot.fedoraproject.org/fedora-meeting/2022-04-28/f36-final-go_no_go-meeting.2022-04-28-17.01.html

Comment 8 Niels De Graef 2022-09-03 08:14:33 UTC
This is normally fixed in the latest main branch upstream.

Comment 9 Adam Williamson 2022-09-28 19:06:16 UTC
Well, it doesn't fail exactly this way any more, but it still doesn't work right: https://bugzilla.redhat.com/show_bug.cgi?id=2130657

Note, this bug is filed against F36, so it can't be closed just because upstream behaviour changed in 43. There'd need to be a 42.1 release or the change would need to be backported downstream to close this bug.

Comment 10 Niels De Graef 2022-09-29 17:28:24 UTC
(In reply to Adam Williamson from comment #9)
> Well, it doesn't fail exactly this way any more, but it still doesn't work
> right: https://bugzilla.redhat.com/show_bug.cgi?id=2130657

Looking into it.

> Note, this bug is filed against F36, so it can't be closed just because
> upstream behaviour changed in 43. There'd need to be a 42.1 release or the
> change would need to be backported downstream to close this bug.

Just wanted to note that backporting that whole rewrite would basically mean the same as backporting the whole of 43, so from an upstream perspective that's not going to happen. (Fedora is free to backport what it wants though)

Comment 11 Ben Cotton 2023-04-25 18:26:29 UTC
This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 12 Ludek Smid 2023-05-25 19:33:09 UTC
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16.

Fedora Linux 36 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.