[Request]: Delete and redraft

[xplosionmind]

Describe the request

It would be great to have a “Delete and redraft” button alongside the “Delete” one, so that the content of the post that is being deleted is automatically pasted in a new draft.

Implementation Details

• This follows the GNOME HIG.

[GeopJr]

Internally, Tuba supports this, but I have to ask, is there a reason you'd want that over editing?

I never bothered to enable it because I added editing when I first forked tootle. I know some backends don't support editing, but most should. Maybe I can add a special case for them instead if that's the reason?

To me, editing feels like a Delete & Redraft replacement (which, as long time fedi users might remember, was the only way to 'edit' posts prior to editing becoming a thing)

[GeopJr]

How about a checkbox or an additional button on the delete dialog?

---

  Delete Post?
   ✅ Redraft
[Cancel] [Delete]

---

Delete Post?
  [Delete]
  [Redraft]
  [Cancel]

---

I think the latter better matches the hig

[xplosionmind]

is there a reason you'd want that over editing?

Since an edited post is labelled as “edited”, if there is just a typo in a post that has been just published, I usually prefer to delete and re-draft it.

Maybe I can add a special case for them instead if that's the reason?

Not really… it’s more to give users the choice of the option they prefer. Since most mobile clients have this feature, I got used to taking advantage of it.

[xplosionmind]

I think the latter better matches the hig

I totally agree! One less click.

[GeopJr]

I know the name is Delete & Redraft, but I was hoping I could Redraft & Delete instead as it's less 'dangerous'. However that doesn't seem to be the case.

If the old post exists then stuff like changing alt text won't work because the attachment ID it belongs to already exists.

So our options are either Delete first and Redraft afterwards or hack it together and only apply alt texts and similar when the user clicks redraft by deleting the post before actually redrafting it.

I don't like either to be honest :(

The first one would require us to have 2 red (dangerous) buttons which I believe goes against hig. So we probably have to scrap this design and go with the first from #1310 (comment) (the checkbox one)

This is what it looks like rn:

And the second one is too hacky and I can already sense the race conditions with the instance :/

[xplosionmind]

Thank you for experimenting with this, @GeopJr! Unfortunately, I don’t think I can help with these specific technicalities, especially because I am not too familiar with the best hig and UI/UX practices.