When solving snap name disputes by means of a "snap ownership transfer", the dispute has to be resolved and removed for the disputing user to be able to get the name

Bug #1814934 reported by Natalia Bidart
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Snap Store Server
Fix Released
Undecided
Hasan Ammar

Bug Description

When a user X disputes a snap name "foo", we can resolve that dispute in different ways:

1- we may revoke the dispute request because the current owner of "foo" is the right one, or
2- we may revoke the existing snap "foo" and grant just the name to user X, or
3- current publisher and disputing user X may agree a snap ownership transfer, with all revisions.

For 3, we need to:

A- Resolve the snap name dispute from user X by "revoking it" (there is no other option right now).
B- Remove the PackageDeclaration bound to that revoked snap name dispute (completely, from the db via the admin).
C- Do the snap ownership transfer.

Step B is required because the same user can't have more than one PackageDeclaration for the same requested_snap_name, so if we leave it on Revoked, we can't transfer the existing one.

Step B has the bad consequence that we loose all audibility on the process of how the dispute was resolved, comments and conclusions.

This bug has a goal to describe the problem, and to have someone doing some research and feature spec to improve the situation.

A few options are:

* Have a new PackageDeclarationClosed model that would keep all those instances of snap name disputes that were "closed" due to "friendly" causes (since Revoked is not really appropriate when solving a dispute with a transfer.

* Have a new state for PackageDeclaration ('Closed') allowing a user to have multiple PackageDeclaration instances for the same requested_snap_name if the status is Closed (I do not like this option since it feels more complex and would have more consequences across sca codebase).

William Grant (wgrant)
tags: added: snap-registration
Revision history for this message
Hasan Ammar (hasanammar) wrote :

For option 1, I'm not sure how easy it would be to copy over the comments; a separate model for PackageDeclarationClosedComments?

Another potential option could be to add some automated comments + transfer the comment history to the original PackageDeclaration during ownership transfer. Something like:

1. Revoke the dispute.

2. Copy over comments:
* AUTOMATED COMMENT: Dispute started by new-owner
* comment 1..n on package-decl-with-dispute updated to point to original-package-decl
* AUTOMATED COMMENT: Dispute resolved; original owner = "..", new owner = ".." (this is probably not needed because PackageDeclarationHistory would have this info).

3. Delete disputed PackageDeclaration.

4. Do the transfer.

The 4-step-transfer could be done in an additional "confirm-friendly-transfer" step in ownership transfer from the admin. I may have missed some details that might prevent this from working, so curious to hear some thoughts.

Revision history for this message
Natalia Bidart (nataliabidart) wrote :

15:28 < nessita> hasanammar, what do you think of a slight variation of option 1, where the PackageDeclarationClosed model has "static" fields holding the frozen view of the declaration state to that point? in there, the comments do not need to be a separated model, but a list of strings saved for future auditing
15:28 <@ roadmr>| frozen! let it gooooo let it goooo
15:28 < hasanammar> nessita, yup, that would work as well
15:31 < hasanammar> nessita, the nice thing there is that the comments are essentially a transcript and not really comments (which can be added/removed)
15:32 <@ roadmr>| +1 on that, just a historical log is enough
15:36 < nessita> hasanammar, ok, great, will propose that in the bug as resolution

Hasan Ammar (hasanammar)
Changed in snapstore:
assignee: nobody → Hasan Ammar (hasanammar)
Hasan Ammar (hasanammar)
Changed in snapstore:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.