Part 1: Sign In Jetpack basic check and error messaging#1121
Part 1: Sign In Jetpack basic check and error messaging#1121nbradbury merged 21 commits intofeature/signin-milestone-1from
Conversation
The new sign in designs start at login by site.
Also converts the layouts to ConstraintLayout for optimal rendering and smoother management.
The new login flow for Woo has the login by site screen leading to this view so it doesn't make any sense having the option available as it would essentially be routing the user back to the previous screen.
This reverts commit d8a0f33. Turns out this part is not yet feasible so we'll skip it for now.
This new mode is for the Woo Android app.
Generated by 🚫 dangerJS |
WooCommerce/src/main/java/com/woocommerce/android/LoginJetpackRequiredFragment.kt
Outdated
Show resolved
Hide resolved
...n/WordPressLoginFlow/src/main/java/org/wordpress/android/login/LoginSiteAddressFragment.java
Show resolved
Hide resolved
anitaa1990
left a comment
There was a problem hiding this comment.
This looks great @AmandaRiu! I love how you migrated a lot of the UI to ConstraintLayout 😄
I tested the functionality and everything works good 👍 I am still trying to understand how the login lib works so not sure if I am the best person to review 😊
| @@ -0,0 +1,109 @@ | |||
| package com.woocommerce.android | |||
There was a problem hiding this comment.
I'm not sure what happened there. I manually moved it once, and then again in the latest branch I'm working on for the second PR. I've manually moved it again 🤞 a0b19dc
| ): View? { | ||
| setHasOptionsMenu(true) | ||
|
|
||
| // Inflate the layout for this fragment |
There was a problem hiding this comment.
I know this is nitpicky (Nickpicky?), but is this comment necessary?
There was a problem hiding this comment.
ha! no that's a really good suggestion. Done in fe639d2
|
@AmandaRiu I'm finished with my first round and it looks good despite my nitpicks. However, one potentially big problem I'm seeing is that after testing with a site that had Jetpack disabled, I then enabled Jetpack and tried again but continued to see the Jetpack required screen. I'm assuming this is a caching issue, or something similar, but it could be a annoyance for users that enable Jetpack and still can't login. |
AmandaRiu
left a comment
There was a problem hiding this comment.
@nbradbury Thank you for the quick review! I've addressed the comments inline and referenced code changes where needed.
I think it should simply show the Help & Support activity, just as it does when the Help button is tapped in the toolbar.
This is pre-existing functionality and I'd prefer not to tinker with it for this project. I'd be down for changing the flow, it would be pretty easy, but I'd definitely like to get @kyleaparker 's thumbs up on it, so we should just create an official ticket so it can be reviewed.
I'm assuming this is a caching issue, or something similar, but it could be a annoyance for users that enable Jetpack and still can't login.
Oh that's no good. I'll have to look into that as well. There must be something I can do there. I'll add it to my TODO list for the project. I wouldn't worry about it for this PR as this is focused more on the flow. Even the way we're checking for Jetpack is temporary.
Ready for another round!
|
@AmandaRiu I was about to merge this then thought I should test against a couple more sites. Both sites I tested with end up showing that Jetpack screen, even though both of them are wp.com sites running WooCommerce. I know you mentioned "The code to check the URL for WordPress and Jetpack is a temporary measure for this round" - does that mean go ahead and merge even if it's not working? Aside: I'm assuming this is why my self-hosted site kept showing that screen even after I enabled Jetpack, so the caching issue I mentioned is likely a red herring. |
After some digging we figured out that Atomic sites have different values returned during the Connected Site check. This is an example response: This is an atomic store and it seems like these values will always be false for an atomic store: I tested with a temp ninja site and walked through the results of the connect site check and verified that during each step of jetpack installation process, install, activate, connect...those values update as expected and can be relied on. I've updated the logic to only require |
|
Looks good! |
👍 ok to leave for the first milestone, will take a look and see if there are improvements we could make later on |
Error TypeErrorDangerfileError TypeErrorDangerfileGenerated by 🚫 dangerJS |
Error TypeErrorDangerfileError TypeErrorDangerfileGenerated by 🚫 dangerJS |



This PR partially addresses #1091. To keep the PRs smaller, I'm breaking them down for review to be merged into a feature branch. This PR covers the following changes:
LoginEmailFragmentto use the site urlLoginSiteAddressFragmentfor all scenarios except the "not connected" scenario (coming in a later PR)SiteAction.FETCH_CONNECT_SITE_INFOto get information on the URL entered to determine if the site has WordPress installed, and if it has Jetpack installed and connected.Note: The code to check the URL for WordPress and Jetpack is a temporary measure for this round. If we decide to fully implement this login flow, we'll need to use the full XMLRPC discovery code and implement handlers for various scenarios such as HTTP Authentication required and self-signed SSL certifications.
Not a valid URL
Not a WordPress site
The initial designs required a check for WooCommerce on a site, but this is not possible without a major overhaul. Instead we check if WordPress is installed, and if not, we display an error:
Jetpack not connected
If jetpack is not installed and connected properly, the user will be directed to the "Jetpack Required" view:
WooCommerce site
If the site is a WordPress site and has Jetpack installed and connected, the user should be routed to login by email as normal. Other than the label changes, everything else should remain the same for the purpose of this PR:
cc: @kyleaparker for design review
Update release notes:
RELEASE-NOTES.txt.