Retract suggested edit

[cellio]

https://meta.codidact.com/posts/287725 https://meta.codidact.com/posts/283569 (from https://github.com/codidact/qpixel/issues/693)

There is currently no way to retract your own suggested edit, which you might want to do either because you realized it's wrong or because you want to make a different or fuller edit. (There can only be one pending edit suggestion at a time.) This request is to allow retracting a suggested edit instead of waiting for someone to handle it or looking for someone to reject it for you.

One possibility would be to add a "retract" button on the suggested edit page, only for your own edits. Another would be to add a "retract" option to the post banner that says "Your suggested edit on this post is pending review" -- the system knows it's you and changes the text accordingly, so this shouldn't allow anyone else to retract your edit.

If we log rejected edits somewhere, we should log retractions in the same places (think of them as self-rejections).

[MoshiKoi]

Currently a suggested edit is controlled by two flags, active and accepted, with the following states.

	accepted	not accepted
active	n/a	pending
not active	accepted	rejected

There's no immediately obvious way to include a "retracted" state. I mean, there's that one cell that's not being used, but I don't think we want to use it for fairly obvious reasons lol.

Because of this, it means that we'd have to modify the database. The two ways I see to go about this are

• Add a retracted flag
• Change from a boolean accepted flag to a more granular enum/int column.
• Change everything to just rely on one enum/int column

The first option is the least intrusive, since the old flags will still work as normal without needing to change the logic there. It also doesn't require any changes to the database than adding the additional column; all the previous data is still valid. However, it ends up with more n/as in that table above, and more flags to take care of, which is definitely not going to be easy to keep track of.

The second and third options require changes to the database, since it would go from a boolean to an integer. Not really sure whether to prefer one over the other.

[trichoplax]

Ideas for working with what we have, in case these can avoid the need for changing the database structure

Retractions only

For a quick fix, would using the existing rejection mechanism work (have a link that says "retract" but in the database it is recorded as a rejection)? I guess that would also require adjusting the edit ability calculation to not count self-rejections, but avoids any database change.

Further considerations if we're going to change the database structure

If we're going to do a review of the database structure, is it worth considering two cases?

1. I want to retract my suggested edit (it goes away).
2. I want to amend my suggested edit (it remains in the pending edits queue, but now with a different wording).

The ability to amend might be more involved and might be best left for a later issue, but if we're changing the database it might be worth bearing in mind what we might need for that later issue so we don't end up having to undo database changes later.

In particular I'd want to know whether we need to keep a history for a suggested edit. For example, if I amend my suggested edit 3 times before it is approved, do we need a record of my first 3 wordings? If we don't keep a record, I could post something offensive and then amend it, leaving no evidence. Would this make disputes difficult for moderators to handle?

Retractions plus amendments plus history without a database change

If a history is required but will not be shown to general users (that is, the rejected edits in the "Decided" tab of the Suggested Edits page would not include self-rejections), it might be possible with the existing database structure. How does this sound?

• Retracting a suggested edit causes it to be marked as rejected in the database. It no longer shows to users, only to moderators on a dedicated history page.
• Amending a suggested edit causes it to be replaced with a new suggested edit, and the old one is marked as rejected in the database, again no longer showing to users, only on the moderator-only history page.

This should allow an arbitrary number of amendments to a suggested edit, optionally followed by a retraction, without losing any of the history. It wouldn't necessarily be clear which items in the moderator-only history page for a given post were amendments, and which were new suggested edits, but for dealing with disputes I would guess that knowing the date and time of each suggested edit would be sufficient in most cases. The only missing information seems irrelevant - whether I retracted a suggested edit and made a new one, or amended the original one, doesn't really matter.

The dedicated history page for moderators only could either be a new page, or there could be a moderator only checkbox on the edit history pages (post level and community level history pages) that includes self rejections in the existing edit history.

Potential problems?

The only problem I could think of was if someone makes a suggested edit, and then gains the edit ability, and goes and rejects their own suggested edit through the existing interface, then this will be indistinguishable in the database from a retraction. This seems a very rare event, and I'm not sure it causes any real problems.

Are there any other problems this approach could cause?

[cellio]

These are good ideas, thanks.

Retractions should definitely not count against your stats for the Edit ability. If a suggested edit record (wherever that's stored in the DB) includes both who suggested it and who rejected it, then if those are the same person we know it's a retraction. If the record doesn't have both of those pieces of information, it seems plausible to add a column (boolean) for isRetraction, without needing to adjust any existing data (only the schema for that table).

Amending an edit suggestion is an interesting idea. If it's more complex, that could be spun off into a separate issue. Under the covers, "append = retract + suggest (pre-populated)" sounds like a good approach to me in that no history is lost. Edits while things are "in flight" are confusing for moderators sometimes, so we do want to avoid creating mysteries. For example, right now a single reviewer can approve an edit, but consider a future in which two are required: an edit between the first and second review could cause havoc. Better for an edit to close out any pending reviews and start over.

(These approaches sound good to me, as someone who is not an expert on How Things Are Done In Rails -- I definitely defer to people more knowledgable.)

[trichoplax]

Without looking at the database to see which table, there's definitely a record somewhere of who rejected a suggested edit as it shows through the user interface in the "Decided" tab of the Suggested Edits page, so that's one less thing to worry about. Example rejected test edit of mine, showing who rejected it.

[trichoplax]

I agree that amending a suggested edit should discard any previous reviews and require the full number of reviewers again (if this is more than 1 in future). Yes I think that implementing amended suggested edits as rejection plus a new pre-populated suggested edit should give us this behaviour automatically.

(Likewise, I'm just presenting ideas for others to consider, in case it saves work - I have no idea if there's a Rails-specific obstacle to this approach.)

[hmltn-0]

duplicate? https://github.com/codidact/qpixel/issues/693 interested in this feature

[cellio]

Agreed. I'm going to mark the other as a dupe of this one because all the discussion is here.