Skip to content

Conversation

@malinajirka
Copy link
Contributor

@malinajirka malinajirka commented Aug 1, 2019

Fixes #10174

This PR changes more than I initially planned. I think it'd be worth considering doing a pair/triple-review with me so I can explain the changes. Please let me know if that's what you prefer to do;).

Main changes

  1. PostModel.changesConfirmedContentHashcode is a field which we use to mark that the current set of changes has been explicitly confirmed by the user. Whenever the user explicitly confirms the chagnes - clicks on Publish/Update/Schedule/Submit/Save/Sync/... button, we calculate a hashcode of the content of the post and save its value into the changesConfirmedContentHashcode field. When we are about to upload the post we calculate the hashcode again and if it matches the value stored in changesConfirmedContentHashcode we are sure the post hasn't been changed since the user confirmed the changes and we can safely upload it.

  2. PostUploadHandler is the place where we decide whether the post will be uploaded, uploaded as draft or remote auto saved.

  • Uploaded are posts with changes which have been explicitly confirmed by the user -> the user clicked on Publish/Update/Schedule/Submit/Save/Sync... buttons.

  • Uploaded as drafts are local drafts (PostModel.isLocalDraft == true) with changes which haven't been confirmed by the user. We can't remote auto save them as they don't exist in the remote.

  • Remote-auto-saved are all other changes. This feature isn't supported on self-hosted sites, therefore we don't sync the changes with the remote on self-hosted sites unless the user explicitly confirms them.

  1. UploadStarter now automatically syncs all changes with the remote - PostUploadHandler decides whether the changes should be uploaded, uploaded as draft or remote auto saved. This PR also adds several safe-guards so we don't automatically upload something we didn't want to upload.

To test:
This PR touches

  • manual publishing/saving/updating/...
  • automatic publishing/saving/updating/...
  • remote previews
  • both posts and pages

We decided we'll test these changes when we implement #10207

Update release notes:

  • [ x ] If there are user facing changes, I have added an item to RELEASE-NOTES.txt.

Notes:

  • This PR should be reviewed by more than one person since the changes are touching auto-uploading, remote-auto-saving and even uploading initiated by the user.
  • I haven't tested Pages at all yet
  • This PR targets master-auto-upload which was created from master-remote-preview.

…-changes-confirmed-at

# Conflicts:
#	WordPress/src/main/java/org/wordpress/android/ui/posts/EditPostActivity.java
#	WordPress/src/main/java/org/wordpress/android/ui/posts/PostListMainViewModel.kt
#	build.gradle
…pdate-changes-confirmed-at

# Conflicts:
#	WordPress/src/main/java/org/wordpress/android/ui/posts/EditPostActivity.java
#	WordPress/src/main/java/org/wordpress/android/ui/posts/PostListMainViewModel.kt
#	build.gradle
…-changes-confirmed-at

# Conflicts:
#	WordPress/src/main/java/org/wordpress/android/ui/posts/PageAndPostListPreviewStateHelper.kt
…firmed-at

# Conflicts:
#	WordPress/src/main/java/org/wordpress/android/ui/uploads/UploadStarter.kt
#	WordPress/src/main/java/org/wordpress/android/ui/uploads/UploadUtils.java
#	build.gradle
@malinajirka malinajirka changed the title Issue/10174 update changes confirmed at Auto-upload/save all posts/pages with local changes Aug 1, 2019
@peril-wordpress-mobile
Copy link

Warnings
⚠️ PR has more than 500 lines of code changing. Consider splitting into smaller PRs if possible.

Generated by 🚫 dangerJS

Copy link
Contributor

@shiki shiki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked at this today. I have some comments and this question:

Prevent auto-uploading posts which are in conflict with remote

Why?

@shiki
Copy link
Contributor

shiki commented Aug 2, 2019

This PR targets master-auto-upload which was created from master-remote-preview.

Which one should be merged first?

Copy link
Contributor

@maxme maxme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have to make sure things work well for self hosted sites before merging this.

PS: The "local draft" and "local changes" status on auto-saved draft/post/page feels a bit weird to me (I'm not expecting changes being available on the server when I see this label), it's not a big deal though.

…mote-auto-save-when-leaving-editor

Invoke remote-auto-save when exiting the editor
@shiki
Copy link
Contributor

shiki commented Aug 8, 2019

I wouldn't worry about it now. We can test the migration before we merge master-auto-upload.

Sounds good!

malinajirka and others added 2 commits August 8, 2019 15:02
…hout-changes-remote-auto-saved

Don't save post when it wasn't edited during the current session
Copy link
Contributor

@shiki shiki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is going well. Almost there! I tested this with a self-hosted site today and found these.

  • Reverting a Published Post into a Draft
  • Preview error in the editor
  • Extra labels for canceled drafts

Reverting a Published Post into a Draft

There does not seem to be a way to revert a published post into a draft. Using develop (870511b), I can do this and it works:

  1. Edit the published post.
  2. Navigate to Post Settings. Change the Status to Draft.
  3. Exit the editor by pressing the back button.
  4. The post will be automatically uploaded and reverted into a draft.

With this change, I get a “Draft is uploading” but it always ends up in the Post List saying these in sequence:

  • Couldn't perform operation
  • Local changes

Here is a video showing this.

Preview error in the editor

I'm not sure if this is because of this PR or because of the preview changes.

  1. Go offline.
  2. Create a draft. Do not leave the editor.
  3. Turn on the internet connection.

An upload will start in the background and an error related to previewing will be shown.

Extra labels for canceled drafts

This could probably use a design input. When canceling Private or Pending review local drafts, their status is still appended after the “Local draft” label.

  1. Go offline.
  2. Create a draft and set it to Private or Pending review.
  3. Exit the editor.
  4. In the Post List, press the Cancel button.

Please let me know if some of these should be out of scope.

Copy link
Contributor

@shiki shiki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Failed media uploads and publishing

I just wanted to confirm if this is expected. I believe you mentioned this a bit during the call. Currently, if a post has a failed media upload, it will always be uploaded as a draft even if the user confirmed publishing it. This video shows what I mean. Here are the steps:

  1. Go offline.
  2. Create a post and add an image. The media should fail to upload.
  3. Press the Publish button. The error shown will not be the usual “Post will be published...” error.
  4. Go online. The image will be uploaded and the post will be uploaded as a draft, not automatically published.
  • RFC on Failed media uploads and publishing

@malinajirka
Copy link
Contributor Author

malinajirka commented Aug 9, 2019

Thank you @shiki!

Reverting a Published Post into a Draft

Hmm, I don't see the "Couldn't perform operation" error. Just the "Local changes" label and it seems like an expected behavior. The user hasn't confirmed the changes, they need to manually click on "SAVE" (in the overflow menu).
I guess we could show "Save" button instead of "Publish" button on the Post List in these cases. Or another option would be to introduce a completely new label.

Preview error in the editor
An upload will start in the background

I'm not able to reproduce this one. I checked the places where we show this specific message and it shouldn't be shown unless the app thinks it's in "preparing" for preview state. @maxme Do you have any tips what might be causing this issue?

This could probably use a design input. When canceling Private or Pending review local drafts, their status is still appended after the “Local draft” label.

I'm not sure I follow what is the issue here. Are you suggesting we should hide the "Private/Pending review" labels if the post is still a local draft -> since when the connection returns we'll upload it as draft and clear the "Private/Pending review" status? If this is what you meant I'm not sure it's a good idea as if the user clicks on Publish again (after canceling the auto-upload) the post will be published as Private/Pending Review - so the label is imho still valid. Wdyt?

Btw I found another bug

  1. Create a private draft in offline and publish it
  2. Cancel the auto-upload
  3. Click on publish on the post list
  4. Enable internet connection
  5. Notice the post gets published not published as private post
    Private draft gets published as public post #10365

Currently, if a post has a failed media upload, it will always be uploaded as a draft even if the user confirmed publishing it.

I've fixed this issue in fe9e162. It's in the cancel button PR.

@maxme
Copy link
Contributor

maxme commented Aug 9, 2019

Preview error in the editor

I'm not sure if this is because of this PR or because of the preview changes.

1. Go offline.

2. Create a draft. Do not leave the editor.

3. Turn on the internet connection.

An upload will start in the background and an error related to previewing will be shown.

That's weird, I just tried this and the draft was uploaded while I was in the editor (I think you got an error, sometimes we get the "network status" event, but the network is not yet ready to do any request).

The message is confusing, I wonder if we're in a wrong state in EditPostActivity. I'm not sure what triggers this auto-upload, I'll check that first.

Note: I just noticed we should update the method name handleRemoteAutoSave to handleRemoteAutoSaveForPreview

private void handleRemoteAutoSave(boolean isError, PostModel post) {

@maxme
Copy link
Contributor

maxme commented Aug 9, 2019

The message is confusing, I wonder if we're in a wrong state in EditPostActivity. I'm not sure what triggers this auto-upload, I'll check that first.

Auto-upload is triggered by the UploadStarter, after the post is pushed, I get the mPostLoadingState == NONE and thus get the correct "draft uploaded" snackbar.

I tried to track how mPostLoadingState could be different from NONE in a non-preview operation and couldn't find any clue.

That makes me wonder if the snackbar you see comes from this line:

but that would mean you tested on an old version of that PR.

@shiki can you try to repro this one and check the state of mPostLoadingState in EditPostAcitivty.handleRemoteAutoSave?

@shiki
Copy link
Contributor

shiki commented Aug 9, 2019

@malinajirka In response to #10319 (comment):

Reverting a Published Post into a Draft
I guess we could show "Save" button instead of "Publish" button on the Post List in these cases. Or another option would be to introduce a completely new label.

I didn't realize there was a Save button there. 🤦‍♂ Seeing that I myself was confused, I think we should change this. But not in this PR. Would you mind creating a separate issue for it? We can ask Chris for his input. The issue is probably a nice-to-have in the context of the Offline Posting project.

  • Create an issue for ☝️

Extra labels for canceled drafts
I'm not sure it's a good idea as if the user clicks on Publish again (after canceling the auto-upload) the post will be published as Private/Pending Review - so the label is imho still valid. Wdyt?

Yeah, you're right. Ignore me. 😁

@shiki
Copy link
Contributor

shiki commented Aug 9, 2019

Failed media uploads and publishing

@malinajirka This is fixed. Thank you. My remaining concern is that the error message in the Post List does not mention that the post will be published automatically. I'm okay with this being done in a separate PR so we can collect all the PRs in the master branch.

Android Emulator - Pixel_2_API_28:5554 2019-08-09 06-54-04

  • Fix or not fix this the error message? Or create an issue?

@shiki
Copy link
Contributor

shiki commented Aug 9, 2019

@maxme In response to #10319 (comment):

@shiki can you try to repro this one and check the state of mPostLoadingState in EditPostAcitivty.handleRemoteAutoSave?

Uhm, I can't reproduce it anymore. 😐 I guess we can close this out for now. Thank you for checking it!

@maxme
Copy link
Contributor

maxme commented Aug 9, 2019

:shipit: to the master branch.

@shiki
Copy link
Contributor

shiki commented Aug 9, 2019

Created issues for the remaining tasks:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants