#783 [gnome-contacts] Contact deletion is unreliable | rhbz#2079274
Closed 3 months ago by blockerbot. Opened 4 months ago by blockerbot.

Bug details: https://bugzilla.redhat.com/show_bug.cgi?id=2079274
Information from BlockerBugs App:
2079274

Current vote summary

Commented but haven't voted yet: coremodule

The votes have been last counted at 2022-05-02 18:29 UTC and the last processed comment was #comment-795434

To learn how to vote, see:
https://pagure.io/fedora-qa/blocker-review
A quick example: BetaBlocker +1 (where the tracker name is one of BetaBlocker/FinalBlocker/BetaFE/FinalFE/0Day/PreviousRelease and the vote is one of +1/0/-1)


Deleting contacts from the Contacts app is a fundamental operation. There's no reason to keep the app open afterwards, so you close it. But the contact was not deleted.

FinalBlocker +1

I agree that the contact should be deleted. However, if the time needed to keep the application open after you delete a contact is not very long - say 15 seconds, I could imagine we just warn in CommonBugs and not block.

But I really do not have a strong opinion about this.

FinalBlocker 0

FinalBlocker +1

Given the fact that this isn't a data loss situation and there's a workaround, I'll be inclined to waive this bug if it comes down to it.

FinalBlocker -1
I'm most for CommonBugs on that one.

It would be an annoying bug, but at least there is no data loss.

I too have no stance on this.

FinalBlocker 0

It sure seems like basic functionality failure.

FinalBlocker +1

I agree this is basic functionality, but based on the change to the notification text, and the fact it apparently has worked like this for at least one release, I'm inclined to believe it's just annoying application functionality and not so much broken.

FinalBlocker -1

Okay, poked around at this some. Contact deletion doesn't start until the toast has been dismissed (either by user interaction, or timeout). This comment leads me to believe it is a design decision. I'm pretty sure closing the app does not count as a dismissal.

I don't think it's acting correctly when multiple delete operations are queued, but that doesn't feel very blockery to me.

This comment leads me to believe it is a design decision.

This is the same design decision as in numerous other apps. But in those apps, closing the window counts as confirmation of your action and the 'pending actions' queue is flushed. In gnome-contacts it isn't, and I don't believe that's intentional.

However, I'm willing to soften up and give this
FinalBlocker 0
because of the "Deleting 1 contact" phrase, instead of "Deleted 1 contact". It's a terrible UX and it will not help users in any way (they'll have the same assumption I had), but a terrible UX isn't a blocker and provides at least some excuse for the source code bug.

I'll change my vote too:

FinalBlocker -1

AGREED RejectedFinalBlocker

Discussed during the 2022-05-02 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker (Final)" was made as deletion does work after a delay, and the notification's grammar does technically convey this, therefore we have decided that this doesn't quite meet the bar of a "basic functionality" failure.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-05-02/f36-blocker-review.2022-05-02-16.00.txt

The following votes have been closed:

Metadata Update from @blockerbot:
- Issue status updated to: Closed (was: Open)

3 months ago

Release F36 is no longer tracked by BlockerBugs, closing this ticket.

Login to comment on this ticket.

Metadata