Post change conflict resolution dialog

[mzorz]

This is a follow up to PR #8940

Comes from #5984 (comment)

After implementing #8940 as a fix to #8932, posts with local changes are not updated with the remote, and there is no indication if the remote had changes as well.

Quoting @megsfulton here for completeness:

One approach we could take that would be minimally disruptive but still communicate that there's an issue to be resolved:

• When the post list is fetched, display a line on the post card indicating that there's a conflict. Similar to how "Local Changes" appears but with some sort of warning icon.
• When the user opens the post ask them how they would like to resolve the conflict. Until they open the post to take an action both conflicted states would continue to exist.

What this PR does is:

• show a new status that tells the user if a Post has a conflict (needs design review, it only shows Conflicted for now).
• when the user taps on a Post with a Conflicted status, it shows a dialog asking whether they would like to load and the Post from the remote, or edit the local copy. They can cancel and not take any action by dismissing the dialog (either tap back arrow key or tap on the screen outside the dialog area)

Corresponding FluxC PR wordpress-mobile/WordPress-FluxC-Android#1077

Note: this needs copy review, the text and approach here does not intend to be final but to show what the functionality would feel like. Also, the new status's color and icon should probably be different than now? cc @megsfulton .

To test:
CASE A: (show the new status on the Posts list)

1. Create a draft while I am online in the app. That'll create the draft in remote.
2. Go offline
3. Make changes to the post and go back. This will save the changes as local draft
4. Go to web or any other client and make changes to the post.
5. Publish the post.
6. on the app, you should be on the posts list. turn airplane mode off
7. pull to refresh.
8. you should see now the post has a "Conflicted" state.

Dialog shown here:

CASE B: (simple conflict resolution dialog - edit local)

1. follow steps 1 to 8 above.
2. now tap on the post
3. a new dialog should be shown, offering 2 options: EDIT LOCAL and LOAD REMOTE
4. if you tap EDIT LOCAL, the local version is loaded. Beware once you tap on it, you've made a choice, but the contents are not lost (these are added to the revision history).
5. if you tap LOAD REMOTE, an attempt to load the latest version from remote is made. You'll need to be online for this (this prerequisite is checked for, and otherwise a toast is shown). You'll see how it gets updated.
   

CASE C: (simple conflict resolution dialog - load remote)

1. follow steps 1 to 8 in case A above.
2. now tap on the post
3. a new dialog should be shown, offering 2 options: EDIT LOCAL and LOAD REMOTE
4. if you tap LOAD REMOTE, an attempt to load the latest version from remote is made. You'll need to be online for this (this prerequisite is checked for, and otherwise a toast is shown). You'll see how it gets updated.
   

Update release notes:

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

[elibud]

Can we review the copy? As a user "Load from remote" doesn't make a lot of sense to me. Maybe loop in editorial?

[mzorz]

Can we review the copy? As a user "Load from remote" doesn't make a lot of sense to me. Maybe loop in editorial?

Yes @elibud, this is what I wrote in the PR description, got probably lost 😄 :

Note: this needs copy review, the text and approach here does not intend to be final but to show what the functionality would feel like. Also, the new status's color and icon should probably be different than now? cc @megsfulton .

I'd first wait for the functionality and UX to be agreed upon, then bring Editorial in if needed 👍

[iamthomasbishop]

The terminology seems a little confusing here. A couple suggestions, and we should get copy review as well:

• Conflicted label on post card: This is a little odd, what about making this the warning/red color, with a warning icon and changing the label to Conflict or Version Conflict?

• Dialog: I'd propose the following – Title: Version Conflict, Body: The remote version of this Post is different from the version saved on your device. Which version would you like to edit?, Actions: Back Edit Local, Edit Remote. I'm not sure if "local" and "remote" will make sense to everyone, but the messaging seems clearer overall, and the addition of an escape hatch seems appropriate.

// cc @megsfulton for any additions or rebuttals :)

[elibud]

Sorry about that, I should read carefully before commenting @mzorz 🤦‍♀️

[megsfulton]

For the status label I like what @iamthomasbishop suggested. Version conflict in red with the notice outline icon

For the dialog copy, I think we need to provide more information so the user can make an informed choice on which version to keep. Also we need to make it clear that only one version will continue to exist so the choice they're making which version to "keep."

Resolve version sync conflict
This post has two versions that are in conflict. Select the version you would like to keep.

Local
Synced on Jan. 14, 2019 at 4:53 PM

Cloud
Synced on Jan. 15, 2019 at 10:33 AM

Keep Local Keep Cloud

Then depending on which version they keep, can we have the editor open with the version they chose?

[oguzkocer]

@mzorz I have only done a tentative check of this PR for now to keep things moving. I'll do a full review once we settle on a decision in the FluxC PR. I think everything looks right though, so I don't expect to add any other comments for the existing changes :)

[oguzkocer]

I guess this is mostly a design question, but would we prefer to make this a non-cancelable dialog instead? I feel like this is a good opportunity to make sure this conflict is resolved by the user. cc @megsfulton

[mzorz]

My thoughts are that when put under this situation, the user may also prefer to double check on the web before making a decision? Especially given we won't be (for now) allowing them to preview what's on one version and the other. So, forcing them to not have a way to escape would then let them stuck there until they can check on the web. Wdyt?

[oguzkocer]

Again, this might be a design question, but when the user selects to edit the local post, shouldn't we push the current post to remote so the conflict is resolved? cc @megsfulton

[mzorz]

technically that's right, but just to add to this (and maybe making it less complex), if they choose to edit the local copy, it'll be sent to the remote side as soon as they exit the editor, so in the end it's probably the same result.

[iamthomasbishop]

I love the recommendations on dialog copy, @megsfulton! I'm not sure how I feel about "cloud" but it's definitely more approachable than "remote".

[mzorz]

Thanks for the input @megsfulton !
This is how the status on the Post card looks so far:

Regarding the dialog, can we change the wording from: Synced on ... to Saved on... ? I think it better reflects what's going on when you see the Local and Cloud titles, as there hasn't been any sync yet (we're trying to figure out which copy to sync here, right?).

Also using the basic Dialog I cannot use bold in within the message - we can totally do that with a custom Dialog but implies a bit more of effort, so I wanted to run it through you first and see if making a custom Dialog is worth that effort:

How does that look to you? Also note I'm re-using an old function we had that uses the @ character for showing the time instead of using the word at, which is hard to translate to some languages when connecting two different values like we're doing in this case.

[mzorz]

hi @oguzkocer thanks for the thorough review and the tips here and there! I think I've addressed all your comments now - after going ahead with each one I had to bring the nullifying statements back (the ones we got rid of / changed in 9494851, 9a38333, and b3bcec0) as they were before, did it in fd320bc.

They were there for a purpose: coordinating the snackbars (in this sense this check here is of importance.), otherwise this was the output:

As opposed to what can be seen in #8989 (comment)

I understand it may not be as clear by looking into the code, I can introduce a new variable to make it explicit if not. Wdyt?

Other than that, this should be ready to go - let me know your thoughts 🙇

[oguzkocer]

@mzorz I took the liberty to merge origin/develop into this branch to resolve the conflict which resulted in an automatic merge. I'll test things once more and merge this in 🤞

[oguzkocer]

It turns out the auto-merge re-added the Introduced new site creation wizard to the release notes which is definitely what we want. I've removed this change and since it doesn't affect the code, I am going to approve and merge this PR once it's done.

P.S: I'd normally work with the author on this, but the code freeze is early tomorrow (for me) and I won't have a chance to do that. These are very simple changes, so I am taking a chance here that it's OK. Let me know if you feel otherwise @mzorz and feel free to address them in a PR. Thanks!

[mzorz]

Thank you @oguzkocer! 👍