Add cancel publish/schedule/submit button to post list items

[malinajirka]

When the user clicks on "publish/schedule/submit" when offline, the post is added to the upload queue.

As per design in #9555 the post list item has for example "Post will be published next time your device is online" label.

Goal of this task is to add "Cancel" button which will change the post status back to draft, so the post doesn't get automatically published when the user's device is online again. (The cancel button should be also added to the SnackBar as per the design.)

Note: This task shouldn't be merged into develop until we start uploading changes automatically and #10207 is implemented.

[malinajirka]

I have been thinking about this. We can't currently differentiate between publishing a draft and publishing changes to an already published post - since we don't store the original/remote PostStatus.

Changing the status back to draft might not be the best idea (we can't do it if the user just wants to cancel publishing changes to an already published post).

We might want to consider simply resetting "publishedConfirmedAt" field (if we decide to introduce it) instead of changing the status of the post.

The user changes would still be uploaded (remote autosave) to the remote even after the user clicked on cancel. The cancel button would basically be "Cancel publishing" [which was probably the original intention].

SideNote: We'd ideally use the "publishedConfirmedAt" even for the "trash/restore" actions so we can have a single solution for the cancel action. (we'd need to pick a different name for "publishedConfirmedAt"). I realized the trash/restore actions are implemented differently than I thought. We don't change the status of the post to "Trashed" locally, but we invoke an endpoint which returns the updated post with "Trashed" status. So the solution for cancel action will depend on the solution for "offline trash/restore support".

@shiki Wdyt?

[shiki]

I have been thinking about this. We can't currently differentiate between publishing a draft and publishing changes to an already published post - since we don't store the original/remote PostStatus.

What if we do store the originalRemotePostStatus? This status sounds like it will free up some complications for us.

Changing the status back to draft might not be the best idea (we can't do it if the user just wants to cancel publishing changes to an already published post).

This is a very good point, Jirka. Here's how I think the Cancel should work for Published posts:

Status before Editing	After confirming to Publish	After canceling
Draft	Published	Draft
Published (i.e. exists in remote)	Published	Published (with local changes that needs confirmation)

I'd like to hear your opinion on this, @osullivanchris. 🙂

We don't change the status of the post to "Trashed" locally, but we invoke an endpoint which returns the updated post with "Trashed" status.

Thank you for doing the research, Jirka. That explains why we can't "upload" trashed local drafts. My uninformed rough idea for this would be:

originalRemotePostStatus (new field)	status	Action
TRASHED	TRASHED	Do nothing
PUBLISHED (and others)	TRASHED	Trash in remote

[shiki]

Changing the status back to draft might not be the best idea (we can't do it if the user just wants to cancel publishing changes to an already published post).

@malinajirka @osullivanchris Another thing we can do is we clear the publishConfirmedAt status to prevent auto-upload from happening until the user reconfirms.

[malinajirka]

Thanks @shiki !

Another thing we can do is we clear the publishConfirmedAt status to prevent auto-upload from happening until the user reconfirms.

I'm a bit confused here. Is this any different than We might want to consider simply resetting "publishedConfirmedAt" field (if we decide to introduce it) instead of changing the status of the post. ? If you just overlooked it, that's completely fine. I just want to make sure I'm not missing anything.

My uninformed rough idea for this would be:

originalRemotePostStatus (new field)	status	Action
TRASHED	TRASHED	Do nothing
PUBLISHED (and others)	TRASHED	Trash in remote

👍 This solution should work. I'd suggest leaving this topic for #10205

[shiki]

If you just overlooked it, that's completely fine.

Yes, I overlooked it. Or I forgot. My bad. 🤦‍♂

[malinajirka]

No worries at all ;).

In that case, it seems we agree that this solution should work. I'd suggest implementing this simple "clear publishedConfirmedAt" behavior in the first iteration and we can introduce originalRemotePostStatus and change it if necessary. Wdyt? (The amount of wasted work in case we decide to change it should be very low)

[shiki]

@malinajirka Sounds good! We can give that a try. 🙂