Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add phone verification #12258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add phone verification #12258
Changes from all commits
1044b42
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue(non-blocking): Sounds ok to leave this as is but I could trigger four (4) messages in a row. Could we easily disable or somehow prevent multiple requests here to avoid abuse or unnecessary charges in Twilio?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aren't the two limits you posted below what you are asking for here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is about limiting users for clicking the button multiple times for fun or abuse. I clicked 4 times in a row and got four SMS messages.
Famous last words: Minor issue, few or no one will notice. 😈
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick: Does it help us achieve our goal (abuse)? I'd rather go with a neutral tone but any option could suffice. Feel free to ignore this nitpick. 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue: Testing is good enough only if you're reaching the limits, see screenshot below. 🙂
Ideally, we could allow users to go back and use a different mobile number when they reach an error like this but we could leave this would probably be an abuse use case and simply reloading should unblock them.
Also, the limit seems to be automatically removed after some time. ⏱️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue(non-blocking): I've ran into this error but should be fine to ignore. Twilio probably hates me by now. 😇
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue(non-blocking): The disabled button state should not have a green color (primary, confirm) but a gray background color like the default button variant. Also, relevant to the comment about the button component.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue(non-blocking): The disabled button state should have the "not-allowed" cursor when hovered and not relying on the CSS class for disabling the interaction. Also, relevant to the comment about the button component.
suggestion: Tailwind supports
cursor-not-allowed
which is something to consider when we build the button component, see relevant docs.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: I noticed we've skipped the verification in progress step from the initial design specs in #11339 (comment) which is fine, but what do you think of injecting a loading state inside the button here with the spinner icon? FWIW, we've used this pattern for running prebuilds in the past, see relevant diff below.
thought: We could use the same pattern also for sending the SMS via code since we rely on an external service for this action.
thought: The loading state of the button is another great example use case where a button component could be used. 💭
gitpod/components/dashboard/src/projects/Prebuild.tsx
Lines 160 to 169 in 3133297
Re-posting the verification in progress design from #11339 (comment) for visibility:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thought: Ideally, instead of relying on a custom class, this would use a link variant of a button component as this involves a reset action but let's keep this out of the scope here as we also don't have a button component yet. 💭
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: Given it's not ideal to update the modal title based on the user action and taking into account the relevant discussion (internal), what do you think of moving the alert component on the loading screen directly where we later on show the warnings about the latest editor release and skip asking users to acknowledge the account validation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think an explicit, "you are verified" message with a 'continue' button is clearer. Especially because we are reloading the page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thought: It is certainly clearer and gives users the time to acknowledge this. 💯
question: What do you think of keeping modal, and updating the modal title to be the same on all cases, and rely on modal body (paragraph and alerts) to inform the user about validation errors or successful validation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: Now that we've tried this, we probably need a new alert component variant for successful messages like this that is using green-ish colors. Could be fine to leave this out of the scope of these changes for now. Your call.
If you'd like to add this here, here's the icon (SVG) and the colors used for light and dark themes:
LIGHT THEME ⛅
DARK THEME 🌔