Offline Mode: Add support for pending posts

[kean]

Changes

• Add "Submit for Review" support
• When you "Update" the post, stay in the editor
• Show "Publish" as a primary action for admin
• Remove the "Submit for Review" from the list context menu (too many entry-points; low usage; rarely gets tested → let's keep it simple)
• Fix an issue where you couldn't save changes to a pending draft by tapping "Back"
• Fix an issue where the "Status" and "Visibility" sections were still visible in "Post Settings" for pending posts for admins
• Fix a false positive for data conflicts (see test 3.1)

Tests

Submit for Review (Contributor)

Test 1.1

• Login as a contributor
• Create a new draft
• Set a breakpoint on /rest/v1.1/sites/*/media/new
• Add a media asset
• Tap "Submit for Review"
• Verify that the the wait-until-media-is-uploaded alert is shown
• Delete the asset

Test 1.2

• Login as a contributor
• Create a new draft
• Tap "Submit for Review"
• Verify that the spinner is shown
• Verify that editor was dismissed and the snackbar confirming submission was shown
• Verify that the post was submitted for review
• Verify that the cell in the post list has a "Pending review" label

Test 1.3

• Open an exisitng "pending" post as a contributor
• Make changes
• Verify that the primary button is "Update"
• Tap "Update"
• Verify that the changes were saved
• Verify that the editor is still opened and a new revision got created: you can add more changes, discard them, etc
• Verify that if you don't make any additional changes, you can tap "Back" to dismiss the editor without needed to confirm the action

Test 1.4

• Open an existing "pending" post as a contributor
• Make changes
• Tap "Back"
• Tap "Save Draft Changes"
• Verify that the changes were saved (asyncronously)

Test 1.5.1

Moving a pending post back to the .draft state.

• Create and submit a pending draft as a contributor
• Return to the list and open the context menu for the post
• Tap "Move to Draft"
• Verify that after a spinner, the post was moved back to draft

Test 1.5.2

Moving a pending post with unsaved changes back to the .draft state.

• Create and submit a pending draft as a contributor
• Return to the list and open the context menu for the post
• Set the breakpoint on /rest/v1.2/sites/*/posts/*
• Make and save some change to the draft by tapping "Back" and "Save Draft"
• Return to the list and open the context menu for the post
• Tap "Move to Draft"
• Verify that the post-is-being-uploaded-retry-later error is shown
• Release the breakpoint, retry and verify that the action was successful

Note: this is maybe not the most elegant solution, but you are unlikely to hit it, and I think it's easy enough to understand what's going on.

Submit for Review (Admin)

Test 2.1

• Open a blog that has pending posts from other user as an admin
• Verify that you can publish a pending post using the context menu in the list

Test 2.2

• Open a pending post in the editor
• Verify that the primary action is "Publish"
• Tap "Publish" and verify that you can publish the post

Test 2.3

• Open a pending post in the editor
• Open "Post Settings"
• Verify that "Status" and "Visibility" rows are not available

Test 2.4

• Repeat tests 1.5.1 and 1.5.2 but as an admin.

Data Conflicts

Test 3.1

• Create a new draft with content "A" and save it
• Set the breakpoint on /rest/v1.2/sites/*/posts/*
• Change the content to "B" and save
• Release the request breakpoint (but not the response breakpoint)
• Verify that the content got updated on the server to "B"
• Terminate and re-start the app
• Verify that the app tries the upload again
• Verify that it hits 409 (release the breakpoints) but the upload succeeds (false positive data conflict)

The reason why this happens is that the content on the remote get updated to "B" and the post gets assigned a new modified app, but the app still thinks that the upload didn't go through. When it tries again, it sends the old modified date.

Regression Notes

1. Potential unintended areas of impact: Pending Posts
2. What I did to test those areas of impact (or what existing automated tests I relied on): Yes
3. What automated tests I added (or what prevented me from doing so): yes

PR submission checklist:

• I have completed the Regression Notes.
• I have considered adding unit tests for my changes.
• I have considered adding accessibility improvements for my changes.
• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Testing checklist:

• WordPress.com sites and self-hosted Jetpack sites.
• Portrait and landscape orientations.
• Light and dark modes.
• Fonts: Larger, smaller and bold text.
• High contrast.
• VoiceOver.
• Languages with large words or with letters/accents not frequently used in English.
• Right-to-left languages. (Even if translation isn’t complete, formatting should still respect the right-to-left layout)
• iPhone and iPad.
• Multi-tasking: Split view and Slide over. (iPad)

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.

	App Name	WordPress Alpha
	Configuration	Release-Alpha
	Build Number	pr22949-8401617
	Version	24.5
	Bundle ID	org.wordpress.alpha
	Commit	8401617
	App Center Build	WPiOS - One-Offs #9390

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.

	App Name	Jetpack Alpha
	Configuration	Release-Alpha
	Build Number	pr22949-8401617
	Version	24.5
	Bundle ID	com.jetpack.alpha
	Commit	8401617
	App Center Build	jetpack-installable-builds #8434

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[momo-ozawa]

Works as described!