My Site Dashboard [Phase 2]: Navigate to Edit Post [HACK - DO NOT MERGE] #15720

ParaskP7 · 2021-12-16T11:32:59Z

This PR implements this functionality that will allow the user to navigate to the Edit Post screen, from the My Site screen, through the Posts screen.

PS: The PR is marked as HACK because of the two hack related commits that are trying to bend the paging framework to allow such navigation. @ashiagr and @zwarm I am adding you both as reviewers since I want both your feedback on this PR, its solution and more specifically I want to to focus on the two hack related commits. Maybe you can recommend another way of doing that.

Prerequisite:

Go to My Site -> Me -> App Settings -> Debug Settings configuration.
Turn-on the MySiteDashboardPhase2FeatureConfig feature.
Relaunch the app.

To test:

If you don't have a draft or scheduled post already, create one.
Note that on the My Site tab, your draft or scheduled posts, if any, are shown.
Click on a draft or scheduled posts and verify that:
- First, the Posts screen is shown for a second or two.
- Then, the Edit Post screen is launched with the content of the draft or scheduled post that was selected.

The above is testing the happy path. In addition to that please make sure to test any or all other scenarios, ultimately trying to break the solution. For example:

Before clicking on the draft or scheduled post, update it remotely. Then, verify that by clicking on it, when navigated to the Edit Post screen, then you will get the remote updates, instead of the now stale/out-dated local state of the post.
Enter the Offline mode and try to test the solution. You might need to comment out the CardsSource.postState(...) for when an error occurs during cardsStore.fetchCards(selectedSite) (see line 83). Otherwise, when entering the Offline mode, the dashboard feed will disappear. PS: This scenario will be also handling via the Handle offline mode subtask, but it would be great to test it now anyway.

NOTE: It is expected that the Posts screen is shown. A subsequent PR, which will handle the full screen post loading, will make sure that the loading experience will be seamless and that the user will never notice the intermediate Posts screen.

Regression Notes

Potential unintended areas of impact

Data Loss (⚠️): Due to the nature of the solution, the user can enter into a situation where by clicking on a draft or scheduled post, the Edit Post screen will open a stale version of the post, or an unwanted version. At which point, if the user clicks back on a draft post, publishes this draft post, or rescheduled/publishes a scheduled post, then they might experience unintentional data loss.

What I did to test those areas of impact (or what existing automated tests I relied on)

Extensive manual testing. See To test sections above.

What automated tests I added (or what prevented me from doing so)

N/A

PR submission checklist:

I have completed the Regression Notes.
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.

peril-wordpress-mobile · 2021-12-16T11:33:06Z

You can trigger optional UI/connected tests for these changes by visiting CircleCI here.

peril-wordpress-mobile · 2021-12-16T11:53:20Z

You can test the changes on this Pull Request by downloading the APKs:

Jetpack-pr-15720-build-117782.apk

WordPress-pr-15720-build-117782.apk

This newly data class will now be holding the extra 'postCardType' information, in addition to the 'postId' and it is going to be used to differentiate clicking on draft from scheduled posts.

This update differential between navigating to: - Edit draft post, when a draft post item is clicked - Edit scheduled post, when a scheduled post item is clicked

This is a partial solution and will help the user navigate to the appropriate tab within the 'Posts' screen. On subsequent commit, the user will be further navigated to the 'Edit Post' screen through the 'Posts' screen.

This 'targetPostId' will be utilised to find the post, from the list of posts, based on the remote post id and then automatically click on it.

This 'targetPostId' is now converted to a 'RemotePostId' and passed into the view model. The view model will then be responsible to find the item in the list, upon a data updated event and then trigger the navigation event, just like it is currently for 'scrollToPosition'.

This functionality is a copy-paste of the existing 'scrollToPosition' functionality, which also happens when the 'onDataUpdated(...)' get triggered. The difference here is that now the 'RemotePostId' is used to find the item in the list, instead of the 'LocalPostId'. Also, another difference is that since the 'onDataUpdated(...)' can get triggered multiple times, the 'navigateToRemotePostId' is only reset when the item is found. This can happen either when 'onDataUpdated(...)' is triggered for the first time (database) or afterwards in a subsequent trigger (network).

This now connect the 'PostListFragment' with the 'PostListViewModel', listening to the 'navigateToPost' event and triggering the necessary action to automatically navigate to the 'Edit Post' screen from the 'Posts' screen.

Since 'onDataUpdated(...)' can get triggered multiple times, reset the [navigateToRemotePostId] only when the item is found and the navigation trigger is actually invoked. Also, due to the way paging library works (see 'PagedList'), and since this screen utilizes this solution, the 'findItemListItem(...)' process will return a valid result/index twice for a specific tab: - The first result might either be a 'PostListItemUiState' or an 'EndListIndicatorItem', and - The second result will always be an 'EndListIndicatorItem'. Since both results will return a valid index, it is safer to use the second result to make sure that no more 'onDataUpdated(...)' will occur for that specific tab. To achieve that the 'navigateToEditPost' logic is being utilised. Also, by doing that the paging library gets some additional time to load the data, before it is being automatically selected right afterwards. PS: The database vs network trigger is not relevant since the paging library, through its data source solution, will be handling all that internally. NOTE: This whole solution is hacky and done this way to help us achieve a quick result, without needing to update the paging library or the underneath list store related implementation.

In addition to the 'PostListViewModel.navigateToPost(...) and its logic, which includes: - The 'PostListViewModel.navigateToEditPost' to skip the first result, and - The [PostListViewModel.navigateToRemotePostId] to reset the navigation trigger. An extra delay of 'NAVIGATE_TO_EDIT_POST_DELAY_MS' milliseconds it added to make sure that the list is submitted to the [PostListAdapter] paging related adapter (see [PagedListAdapter]). This will make sure that the newly submitted list updated the existing and potentially stale list. Otherwise, and due to the fact that the list submission can take some additional time, selecting the item might launch the 'EditPostActivity' with a stale item and thus this might overwrite any remote changes. PS: A delay of half a second would have been sufficient enough, based on the testing that was done, but doubling this number to 1 second seemed safer to to make sure that no there will be less changes for the stale item to get selected. NOTE: This whole solution is hacky and done this way to help us achieve a quick result, without needing to update the paging library or the underneath list store related implementation.

zwarm

@ParaskP7
This is quite a complex problem, so bravo for finding a solution so quickly. 🥇

I’ve tested according to your instructions and so far, so good. I can't wait to see the next installment that eliminates the post list.

We probably want to add a general testing scenario for configuration changes. I rotated my device after tapping a post card item and I never transitioned from the post list to the edit view (remained on the post list). I may have been premature with this one, but I decides to test it after I was reading the "hack area" comments related to navigateToEditPost. I’ll be sure to repeat the test against subsequent PR’s.

Otherwise, and due to the fact that the list submission can take some additional time, selecting the item might launch the 'EditPostActivity' with a stale item and thus this might overwrite any remote changes.

^^ I haven’t been able to come up with a better solution. I wonder if we should use firebase remote config for the delay value for the testing/beta period to see how it performs. Then if it needs to be adjusted, we can do so without creating a new build. Something to consider.

We talked about guarding this entire implementation with a feature flag … I didn’t see that in here explicitly (yes, we just talked about it today - :)) . It is indirectly guarded by the msd flag and by the postId = null logic. Am I correct in stating that future logic will add a flag so we can switch from “post item tap → post list → highlight row” and this solution?

Nice work. 🙇

zwarm · 2021-12-16T21:20:28Z

WordPress/src/main/java/org/wordpress/android/ui/mysite/MySiteFragment.kt

@@ -321,7 +321,8 @@ class MySiteFragment : Fragment(R.layout.my_site_fragment),
                    PagePostCreationSourcesDetail.POST_FROM_MY_SITE
            )
        // TODO: ashiagr this is unhandled right now as mocked post is being used which cannot be opened in the editor


Can this todo be removed now?

👋 @zwarm !

Thank you, but this TODO is actually removed already, just in a subsequent commit. Can you please verify that?

🙏

zwarm · 2021-12-16T21:26:57Z

WordPress/src/main/java/org/wordpress/android/ui/ActivityLauncher.java

@@ -609,7 +622,7 @@ public static void viewCurrentBlogPostsOfType(Context context, SiteModel site, P
        if (postListType == null) {
            context.startActivity(PostsListActivity.buildIntent(context, site));
        } else {
-            context.startActivity(PostsListActivity.buildIntent(context, site, postListType, false, null));
+            context.startActivity(PostsListActivity.buildIntent(context, site, postListType, false, null, postId));
        }
        AnalyticsUtils.trackWithSiteDetails(AnalyticsTracker.Stat.OPENED_POSTS, site);


NOTE: This is what I was talking about earlier today re: tracking "opened posts" . Should we be tracking the open post list when we are automagically opening edit? Perhaps we need to track it some other way, because who knows, we MAY actually land on the posts view depending upon the scenario.

Nothing to do with this comment, just wanted us to think about it. :)

👋 @zwarm !

Yeap, totally. As I said, let's think and talk about it more at any point you like while you will be implementing this kind of tracking event logic, I believe there are multiple ways to do what we want.

👍

ashiagr · 2021-12-17T07:30:25Z

Great job @ParaskP7! Although hacky, it works and serves the purpose! 👏

It was only after I extensively tested that I found two extreme edge cases when a (dashboard card) post couldn't be found on the posts screen on navigateToPost even though they existed there.

Scenario 1: Local draft post

Disable Internet
Create a Local draft post
Return to My Site Dashboard screen
Enable internet
Pull-to-refresh (so that local draft post is uploaded and visible on the draft post card)
Click this post on the draft post card
Notice that the navigation stops at the posts screen with logs
E/WordPress-POSTS: NavigateToPost failed - the post not found.

Note that it happens only the first time. The navigation works if we return to the dashboard and re-click that post.

local_draft_post.mp4

Scenario 2: Author's post not yet laid out on the posts screen

As we always display the author's most recent posts on the dashboard draft posts card, most of the time they will be present on the top of the posts list and can be found during this navigation.

There's a possibility that a few posts from a contributor are present before the author's post on the posts screen and the author post is not yet laid out. In that case, the author's post won't be found during this navigation and the flow will stop at the posts screen.

author_post_not_yet_laid_out.mp4

Not yet sure if auto-scrolling to that position and then performing a click can help.

I'll continue to test and let you know if I come across anything else. 🙇‍♀️

ParaskP7 · 2021-12-17T09:51:02Z

👋 @zwarm !

This is quite a complex problem, so bravo for finding a solution so quickly. 🥇

🙇 + 🙏 Now let's see what I have missed... 😅

I’ve tested according to your instructions and so far, so good. I can't wait to see the next installment that eliminates the post list.

Yes, this can be found in this #15723 PR here. I just added you as a reviewer as well, just in case.

We probably want to add a general testing scenario for configuration changes. I rotated my device after tapping a post card item and I never transitioned from the post list to the edit view (remained on the post list). I may have been premature with this one, but I decides to test it after I was reading the "hack area" comments related to navigateToEditPost. I’ll be sure to repeat the test against subsequent PR’s.

Hmmm... let me test this and thanks for figuring out an inconsistency with the flow! So, what you are saying is that you:

Tap the Post Item from the My Site screen and Post card.
This navigated you to the Posts screen.
Now, and before navigating automatically to the Edit Post screen, you rotated the device. PS: Note that on the next My Site Dashboard [Phase 2]: Load Handling while Navigating to Edit Post [DO NOT MERGE] #15723 PR you will be getting a full screen post loading dialog instead.
Expected Behavior: This would navigate you to the Edit Post screen with the device rotated.
Actual Behavior: This didn't navigate you to the Edit Post screen, instead you stays on the Posts screen with the device rotated.

Are the above described steps correct? If so, I wonder if we need to care for that since the user will be getting a full screen post loading dialog at this point anyway. Maybe we can lock the screen orientation when the full screen post loading dialog is shown to prevent that from even happening. Is that worth it, wdyt?

^^ I haven’t been able to come up with a better solution. I wonder if we should use firebase remote config for the delay value for the testing/beta period to see how it performs. Then if it needs to be adjusted, we can do so without creating a new build. Something to consider.

Good idea!

However, I wonder and I would be kind against that because I don't want to start creating a tool for us to bend and improve on this hacky solution. Instead, what I want is for us to drop this solution and revert to a simpler one if we figure out that our user are having issues with it.

Adding ad-hoc delays to see how it performs and controlling that from Firebase Remote Config seems a bit too much for me. Also we might increase the robustness of this hacky solution this way, but decrease the user experience since now every user would have to way that extra delay more before navigating to the Edit Post screen, without really needing it, which I am really not liking.

We talked about guarding this entire implementation with a feature flag … I didn’t see that in here explicitly (yes, we just talked about it today - :)) .

I just added a Suggestions section in the parent #15709 issue, with the title: Add a new feature flag and use Firebase Remote Config to control and switch between two possible solutions

It is indirectly guarded by the msd flag and by the postId = null logic. Am I correct in stating that future logic will add a flag so we can switch from “post item tap → post list → highlight row” and this solution?

This need to be discussed and agreed upon, for now it is just an idea, thus I added it as a suggestion. But, I am personally in favor of it. However, I would wait up until we end up completing our initial hacky solution and then we can move forward with thinking about this. Because, who knows, maybe we will end up dropping this hacky solution after all and thus this will leave us with the next best thing to be doing. Wdyt? 🤔

ParaskP7 · 2021-12-17T10:04:03Z

👋 @ashiagr !

Great job @ParaskP7! Although hacky, it works and serves the purpose! 👏

🙇 + 🙏 Now let's see what I have missed... 😅

It was only after I extensively tested that I found two extreme edge cases when a (dashboard card) post couldn't be found on the posts screen on navigateToPost even though they existed there.

So many thanks for going through this extensive testing and for the two scenarios you found that might cause us trouble. I'll check both and come back to you on that.

Scenario 1: Local draft post

Let me check on that and I'll report back to you. 🙏

Note that it happens only the first time. The navigation works if we return to the dashboard and re-click that post.

Yes, if a problem happens it will happen only the first time, when you return back to the Posts screen, and then further back to the My Site screen, the underneath data will end up becoming available and up-to-date. Thus, when you re-click on that or any post it will now work without problem as the local and remote state will match.

Scenario 2: Author's post not yet laid out on the posts screen

Let me check on that and I'll report back to you. 🙏

As we always display the author's most recent posts on the dashboard draft posts card, most of the time they will be present on the top of the posts list and can be found during this navigation.

There's a possibility that a few posts from a contributor are present before the author's post on the posts screen and the author post is not yet laid out. In that case, the author's post won't be found during this navigation and the flow will stop at the posts screen.

This is so very interesting, I wouldn't expect this to happen. What I would expect instead is for the top 3 drafts and scheduled on the dashboard feed and My Site screen to match the top 3 drafts and scheduled on the Posts screen. If there exist a diff there, because of the author vs contributor problem, then maybe the Posts screen is incomplete, in which case this might end up being an edge case that we simply can't work with. Wdyt?

Let me dig a bit deeper and I'll come back to you on that.

Not yet sure if auto-scrolling to that position and then performing a click can help.

Yeap, not sure as well, but at least it will not cause any data loses. 🤔

PS: I just added a Suggestions section in the parent #15709 issue, with the title: Add a new feature flag and use Firebase Remote Config to control and switch between two possible solutions

I'll continue to test and let you know if I come across anything else. 🙇‍♀️

Thank you so much, that would be great! Actually everything you done so far helps enormously, so please keep it up! 🙇

ashiagr · 2021-12-17T10:12:43Z

This is so very interesting, I wouldn't expect this to happen. What I would expect instead is for the top 3 drafts and scheduled on the dashboard feed and My Site screen to match the top 3 drafts and scheduled on the Posts screen.

This is indeed an interesting find. I also tested from a contributor's account and noticed that they could only see author's draft posts on the dashboard draft post card and could not see drafts created by them even if they were more recent.

contributor_drafts.mp4

I think we should discuss this scenario whether contributors should see their draft or author's and vice-versa:
whether authors should see their posts or contributors as well.

ParaskP7 · 2021-12-17T14:11:11Z

👋 @ashiagr !

Scenario 1: Local draft post

Once again, thank you for testing and finding out that this scenario doesn't work. I actually tested it myself and verified the same thing. Then, I started digging deeper and I found the solution. I also found why this happens. So, the solution is mainly to do the below two things, one is optional but I totally recommend to keep things simple:

(Optional): Add the EXTRA_TARGET_POST_LIST_TYPE, in addition to the EXTRA_TARGET_POST_REMOTE_ID and make sure that the whole checkAndNavigateToPost(...) is only triggered from when the targetPostId is present and for that specific targeted tab, ignoring any other tab. This makes the solution simpler to reason and avoids any additional computation (like findItemListItem).
Move the if (navigateToEditPost) { ... } and navigateToEditPost = true switch out of the navigateToPost(...) and into the checkAndNavigateToPost(...) function. This will make sure that the first result will always be ignored, no matter whether the item is found in the list or not. This was the problem with this Local draft scenario.

Below, I am going to provide some logs so that you understand what is happening and with those I am going to explain why the above change will work on all 3 below scenarios:

1st Scenario: Posts list screen has already fetched the list of post at least once. (SITE.1)
2nd Scenario: Posts list screen has already fetched the list of post at least once. But, then a Local draft is added. (SITE.1)
3rd Scenario: Posts list screen hasn't fetched the list of post yet. (SITE.2)

Below, lots are happening, don't get overwhelmed and please feel free to reach out to me so I can explain in more detail.

1st Scenario: Posts list screen has already fetched the list of post at least once. (SITE.1 - 3 DRAFTS)

In this scenario you will see that the 1st call of onDataUpdated(...) that will end up navigating to the inside of the checkAndNavigateToPost(...) will give you 3 x PostListItemUiStateData and then the 2nd call will give you 3 x PostListItemUiStateData and 1 x EndListIndicatorItem.

checkAndNavigateToPost: OUT
checkAndNavigateToPost: OUT
checkAndNavigateToPost: IN

Data: [Size: 3]
Data 1: PostListItemUiStateData(remotePostId=RemotePostId(id=RemoteId(value=23)))
Data 2: PostListItemUiStateData(remotePostId=RemotePostId(id=RemoteId(value=21)))
Data 3: PostListItemUiStateData(remotePostId=RemotePostId(id=RemoteId(value=20)))
Data: [Remote Post Id: RemotePostId(id=RemoteId(value=23))]

navigateToPost: OUT
checkAndNavigateToPost: OUT
checkAndNavigateToPost: OUT
checkAndNavigateToPost: IN

Data: [Size: 4]
Data 1: PostListItemUiStateData(remotePostId=RemotePostId(id=RemoteId(value=23)))
Data 2: PostListItemUiStateData(remotePostId=RemotePostId(id=RemoteId(value=21)))
Data 3: PostListItemUiStateData(remotePostId=RemotePostId(id=RemoteId(value=20)))
Data 4: EndListIndicatorItem
Data: [Remote Post Id: RemotePostId(id=RemoteId(value=23))]

navigateToPost: IN
PostListItemUiState: FOUND

2nd Scenario: Posts list screen has already fetched the list of post at least once. But, then a Local draft is added. (SITE.1 - 3 DRAFTS)

In this scenario you will see that the 1st call of onDataUpdated(...) that will end up navigating to the inside of the checkAndNavigateToPost(...) will give you 3 x PostListItemUiStateData and then the 2nd call will give you 4 x PostListItemUiStateData, which will include the local draft on top and 1 x EndListIndicatorItem.

checkAndNavigateToPost: OUT
checkAndNavigateToPost: OUT
checkAndNavigateToPost: IN

Data: [Size: 3]
Data 1: PostListItemUiStateData(remotePostId=RemotePostId(id=RemoteId(value=23)))
Data 2: PostListItemUiStateData(remotePostId=RemotePostId(id=RemoteId(value=21)))
Data 3: PostListItemUiStateData(remotePostId=RemotePostId(id=RemoteId(value=20)))
Data: [Remote Post Id: RemotePostId(id=RemoteId(value=41))]

navigateToPost: OUT
checkAndNavigateToPost: IN

Data: [Size: 5]
Data 1: PostListItemUiStateData(remotePostId=RemotePostId(id=RemoteId(value=41))) -> Local draft
Data 2: PostListItemUiStateData(remotePostId=RemotePostId(id=RemoteId(value=23)))
Data 3: PostListItemUiStateData(remotePostId=RemotePostId(id=RemoteId(value=21)))
Data 4: PostListItemUiStateData(remotePostId=RemotePostId(id=RemoteId(value=20)))
Data 5: EndListIndicatorItem
Data: [Remote Post Id: RemotePostId(id=RemoteId(value=41))]

navigateToPost: IN
PostListItemUiState: FOUND
checkAndNavigateToPost: OUT
checkAndNavigateToPost: OUT

3rd Scenario: Posts list screen hasn't fetched the list of post yet. (SITE.2 - 1 DRAFT)

In this scenario you will see that the 1st call of onDataUpdated(...) that will end up navigating to the inside of the checkAndNavigateToPost(...), but will give you 0 results, then the 2nd call will give you 2 x PostListItemUiStateData and finally a 3rd call will give you 1 x PostListItemUiStateData and 1 x EndListIndicatorItem.

At this point you will notice 3 calls, which I have missed previously, thinking that there will be always 2 calls. However, this new solution, by moving the if (navigateToEditPost) { ... } and navigateToEditPost = true switch out of the navigateToPost(...) and into the checkAndNavigateToPost(...) function, will make it work since:

The 1st call will be always ignored.
The 2nd call will be ignored, only if data is not found.
The 3rd call will never be ignored, thus capturing... 🤞 all cases.

checkAndNavigateToPost: IN

Data: [Size: 0]
Data: [Remote Post Id: RemotePostId(id=RemoteId(value=7))]

navigateToPost: OUT
checkAndNavigateToPost: OUT
checkAndNavigateToPost: OUT
checkAndNavigateToPost: OUT
checkAndNavigateToPost: IN

Data: [Size: 2]
Data 1: EndListIndicatorItem
Data 2: EndListIndicatorItem
Data: [Remote Post Id: RemotePostId(id=RemoteId(value=7))]

navigateToPost: IN
LoadingItem: NOT FOUND
EndListIndicatorItem: NOT FOUND
checkAndNavigateToPost: OUT
checkAndNavigateToPost: OUT
checkAndNavigateToPost: OUT
checkAndNavigateToPost: IN

Data: [Size: 2]
Data 1: PostListItemUiStateData(remotePostId=RemotePostId(id=RemoteId(value=7)))
Data 2: EndListIndicatorItem
Data: [Remote Post Id: RemotePostId(id=RemoteId(value=7))]

navigateToPost: IN
PostListItemUiState: FOUND

ParaskP7 · 2021-12-17T14:16:48Z

👋 @ashiagr !

Scenario 2: Author's post not yet laid out on the posts screen

As per your latest comment, and this one from myself on this other #15723 PR, I think we not need to step back a bit and reassess how we want to deal with this new find of yours and Chris's.

No matter, this should not block this PR as nothing can be done as part of this PR to address this issue. Wdyt?

ashiagr

👋 @ParaskP7 !

Scenario 1: Local draft post

Thanks for fixing the issue and also including a detailed explanation in #15720 (comment).

I've tested the solution, it works like a charm. 🎉

Scenario 2: Author's post not yet laid out on the posts screen

I think we not need to step back a bit and reassess how we want to deal with this new find of yours and Chris's.

I agree with the above. Let's reassess how to deal with it. Can we add it to our TODO list?

I'm approving the PR, feel free to merge when you're ready.

ParaskP7 · 2021-12-20T09:00:17Z

👋 @ashiagr !

👋 @ParaskP7 !

Scenario 1: Local draft post

Thanks for fixing the issue and also including a detailed explanation in #15720 (comment).

I've tested the solution, it works like a charm. 🎉

Thank you for testing and verifying that everything now work as expected, including this extra scenario. 👍

Scenario 2: Author's post not yet laid out on the posts screen

I think we not need to step back a bit and reassess how we want to deal with this new find of yours and Chris's.

I agree with the above. Let's reassess how to deal with it. Can we add it to our TODO list?

Yes, I agree, actually this and its subsequent PR are now on hold, see comment here. We will reassess the solution as a whole and take any appropriate steps afterwards, but for now and in order to wrap up the project, we will keep it simple and just show the draft/scheduled posts screen when a user taps a draft/scheduled post.

I'm approving the PR, feel free to merge when you're ready.

Thank for approving, but as per the above comment I am going to close this and its subsequent PR. Then, I am going to create a new PR which just navigates to the draft/scheduled posts screen when a user taps a draft/scheduled post, keeping all the commits that I did to do so from this PR, up until the launcher changes.

PS: I'll keep the navigation action functionality separate, include the remote postId in it, even if that is not used, then update your todo explaining that for the time being this will just navigate to the Posts screen, but later on it should navigate to the Edit Post screen, thus the unused postId. Wdyt?

ParaskP7 · 2021-12-20T09:03:55Z

As per this comment, I am now closing this PR.

PS: I am going to create a new PR which just navigates to the draft/scheduled posts screen when a user taps a draft/scheduled post, keeping all the commits that I did to do so from this PR, up until the launcher changes.

ParaskP7 · 2021-12-20T09:19:56Z

👋 @ashiagr !

I agree with the above. Let's reassess how to deal with it. Can we add it to our TODO list?

I created this #15736 issue for us and added it in the newly created TBD extra section on this #15198 parent issue of ours. Let me know what you think.

This navigation is temporary and as such not utilizing the 'action.postId' in order to navigate to the 'Edit Post' screen. Instead, it fallbacks to navigating to the 'Posts' screen and targeting a specific tab. Previously, another issue was opened in order to help us create a solution to navigate straight to 'Edit Post', just as the user expected. However, as this solution was implemented and problems were popping-up, this solution was paused indefinitely and until it further reassessment. Useful links: - Issue: https://github.com/wordpress-mobile/WordPress-Android/issues /15709 - PR: #15720 - PR: #15723 - Decision: https://github.com/wordpress-mobile/WordPress-Android/pull/ 15723#issuecomment-996762177

ashiagr · 2021-12-20T12:24:47Z

I created this #15736 issue for us and added it in the newly created TBD extra section on this #15198 parent issue of ours. Let me know what you think.

Thank you! Looks good to me. 👍

ParaskP7 added the My Site Dashboard label Dec 16, 2021

ParaskP7 added this to the 19.0 milestone Dec 16, 2021

ParaskP7 requested review from zwarm and ashiagr December 16, 2021 11:33

ParaskP7 self-assigned this Dec 16, 2021

ParaskP7 mentioned this pull request Dec 16, 2021

My Site Dashboard - Phase 2 - Navigate to Edit Post [DO NOT PROGRESS] #15709

Closed

8 tasks

ParaskP7 added Tooling and removed Tooling labels Dec 16, 2021

ParaskP7 added 15 commits December 16, 2021 17:02

Test: Make post date constant non null on post card builder test

236f857

Feature: Update on post item click type to post item click params

137c6f3

This newly data class will now be holding the extra 'postCardType' information, in addition to the 'postId' and it is going to be used to differentiate clicking on draft from scheduled posts.

Feature: Update edit draft/scheduled post navigation on post item click

458e0c4

This update differential between navigating to: - Edit draft post, when a draft post item is clicked - Edit scheduled post, when a scheduled post item is clicked

Feature: Navigate to edit draft/scheduled post on post item click

f111d55

This is a partial solution and will help the user navigate to the appropriate tab within the 'Posts' screen. On subsequent commit, the user will be further navigated to the 'Edit Post' screen through the 'Posts' screen.

Refactor: Remove unnecessary menu dot let kotlin guard

870a961

Refactor: Remove redundant sam constructors from post list fragment

9c0fb2e

Refactor: Correct optional typo on post list fragment

5cd7f08

Feature: Forward target post id to post list fragment through adapter

bc93156

This 'targetPostId' will be utilised to find the post, from the list of posts, based on the remote post id and then automatically click on it.

Refactor: Remove redundant sam constructors from post list view model

f2e34f7

Cleanup: Remove unnecessary tag constant from post list fragment

d1967ae

ParaskP7 force-pushed the issue/15709-navigate-to-edit-post branch from 664aaa1 to d1967ae Compare December 16, 2021 15:03

ParaskP7 added Tooling and removed Tooling labels Dec 16, 2021

ParaskP7 mentioned this pull request Dec 16, 2021

My Site Dashboard [Phase 2]: Load Handling while Navigating to Edit Post [DO NOT MERGE] #15723

Closed

3 tasks

zwarm approved these changes Dec 16, 2021

View reviewed changes

ParaskP7 added 2 commits December 17, 2021 16:34

Feature: Add target post list type logic when navigating to post

0a65672

Hack: Move extra navigate to edit post logic to ignore first result

a07fcc4

ParaskP7 changed the title ~~My Site Dashboard [Phase 2]: Navigate to Edit Post [HACK]~~ My Site Dashboard [Phase 2]: Navigate to Edit Post [HACK - DO NOT MERGE] Dec 17, 2021

ParaskP7 added the [Status] Not Ready for Merge label Dec 17, 2021

Test: Fix test compilation failure on post list view model test

f60c875

ParaskP7 added Tooling and removed Tooling labels Dec 17, 2021

ashiagr added Tooling and removed Tooling labels Dec 20, 2021

ashiagr approved these changes Dec 20, 2021

View reviewed changes

ParaskP7 closed this Dec 20, 2021

ParaskP7 mentioned this pull request Dec 20, 2021

My Site Dashboard - Phase 2 - Update Draft/Scheduled Post Order #15736

Closed

ParaskP7 mentioned this pull request Dec 20, 2021

My Site Dashboard [Phase 2]: Navigate to Posts #15737

Merged

3 tasks

ParaskP7 deleted the issue/15709-navigate-to-edit-post branch October 31, 2022 09:58

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

My Site Dashboard [Phase 2]: Navigate to Edit Post [HACK - DO NOT MERGE] #15720

My Site Dashboard [Phase 2]: Navigate to Edit Post [HACK - DO NOT MERGE] #15720

ParaskP7 commented Dec 16, 2021 •

edited

Loading

peril-wordpress-mobile bot commented Dec 16, 2021 •

edited

Loading

peril-wordpress-mobile bot commented Dec 16, 2021 •

edited

Loading

zwarm left a comment

zwarm Dec 16, 2021

ParaskP7 Dec 17, 2021

zwarm Dec 16, 2021

ParaskP7 Dec 17, 2021

ashiagr commented Dec 17, 2021

ParaskP7 commented Dec 17, 2021

ParaskP7 commented Dec 17, 2021

ashiagr commented Dec 17, 2021

ParaskP7 commented Dec 17, 2021

ParaskP7 commented Dec 17, 2021

ashiagr left a comment

ParaskP7 commented Dec 20, 2021

ParaskP7 commented Dec 20, 2021

ParaskP7 commented Dec 20, 2021

ashiagr commented Dec 20, 2021

My Site Dashboard [Phase 2]: Navigate to Edit Post [HACK - DO NOT MERGE] #15720

My Site Dashboard [Phase 2]: Navigate to Edit Post [HACK - DO NOT MERGE] #15720

Conversation

ParaskP7 commented Dec 16, 2021 • edited Loading

Regression Notes

peril-wordpress-mobile bot commented Dec 16, 2021 • edited Loading

peril-wordpress-mobile bot commented Dec 16, 2021 • edited Loading

zwarm left a comment

Choose a reason for hiding this comment

zwarm Dec 16, 2021

Choose a reason for hiding this comment

ParaskP7 Dec 17, 2021

Choose a reason for hiding this comment

zwarm Dec 16, 2021

Choose a reason for hiding this comment

ParaskP7 Dec 17, 2021

Choose a reason for hiding this comment

ashiagr commented Dec 17, 2021

ParaskP7 commented Dec 17, 2021

ParaskP7 commented Dec 17, 2021

ashiagr commented Dec 17, 2021

ParaskP7 commented Dec 17, 2021

ParaskP7 commented Dec 17, 2021

ashiagr left a comment

Choose a reason for hiding this comment

ParaskP7 commented Dec 20, 2021

ParaskP7 commented Dec 20, 2021

ParaskP7 commented Dec 20, 2021

ashiagr commented Dec 20, 2021

ParaskP7 commented Dec 16, 2021 •

edited

Loading

peril-wordpress-mobile bot commented Dec 16, 2021 •

edited

Loading

peril-wordpress-mobile bot commented Dec 16, 2021 •

edited

Loading