fix: update MaxFrequency error message to reflect number of seconds #1540
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Pull Request Test Coverage Report for Build 9583492595Details
💛 - Coveralls |
|
This PR is too broad. Will scope down so that it modifies two routes and we can gradually modify more thereafter. |
J0
force-pushed
the
j0/accurately_affect_max_frequency_limit
branch
from
80f1f36 to
aba0b5b
Compare
J0
force-pushed
the
j0/accurately_affect_max_frequency_limit
branch
from
cc4d1db to
9db8cec
Compare
hf
approved these changes
Jun 20, 2024
hf
pushed a commit
that referenced
this pull request
Jun 24, 2024
🤖 I have created a release *beep* *boop* --- ## [2.154.2](v2.154.1...v2.154.2) (2024-06-24) ### Bug Fixes * publish to ghcr.io/supabase/auth ([#1626](#1626)) ([930aa3e](930aa3e)), closes [#1625](#1625) * revert define search path in auth functions ([#1634](#1634)) ([155e87e](155e87e)) * update MaxFrequency error message to reflect number of seconds ([#1540](#1540)) ([e81c25d](e81c25d)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
uxodb
pushed a commit
to uxodb/auth
that referenced
this pull request
Nov 13, 2024
…upabase#1540) ## What kind of change does this PR introduce? Currently we use a constant value on number of seconds left before a developer can send a follow up email confirmation. This can prove confusing if developer has a custom setting for `MaxFrequency` on `Sms` or `SMTP` We change some core email related routes to show the exact number of seconds. This includes `signup`, `magic_link` and `email_change` The rest will follow should this change roll out smoothly. Tested the three flows locally by triggering the max frequency limit and checking that the number of seconds show up as expected.
uxodb
pushed a commit
to uxodb/auth
that referenced
this pull request
Nov 13, 2024
🤖 I have created a release *beep* *boop* --- ## [2.154.2](supabase/auth@v2.154.1...v2.154.2) (2024-06-24) ### Bug Fixes * publish to ghcr.io/supabase/auth ([supabase#1626](supabase#1626)) ([930aa3e](supabase@930aa3e)), closes [supabase#1625](supabase#1625) * revert define search path in auth functions ([supabase#1634](supabase#1634)) ([155e87e](supabase@155e87e)) * update MaxFrequency error message to reflect number of seconds ([supabase#1540](supabase#1540)) ([e81c25d](supabase@e81c25d)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
LashaJini
pushed a commit
to LashaJini/auth
that referenced
this pull request
Nov 13, 2024
…upabase#1540) ## What kind of change does this PR introduce? Currently we use a constant value on number of seconds left before a developer can send a follow up email confirmation. This can prove confusing if developer has a custom setting for `MaxFrequency` on `Sms` or `SMTP` We change some core email related routes to show the exact number of seconds. This includes `signup`, `magic_link` and `email_change` The rest will follow should this change roll out smoothly. Tested the three flows locally by triggering the max frequency limit and checking that the number of seconds show up as expected.
LashaJini
pushed a commit
to LashaJini/auth
that referenced
this pull request
Nov 13, 2024
🤖 I have created a release *beep* *boop* --- ## [2.154.2](supabase/auth@v2.154.1...v2.154.2) (2024-06-24) ### Bug Fixes * publish to ghcr.io/supabase/auth ([supabase#1626](supabase#1626)) ([930aa3e](supabase@930aa3e)), closes [supabase#1625](supabase#1625) * revert define search path in auth functions ([supabase#1634](supabase#1634)) ([155e87e](supabase@155e87e)) * update MaxFrequency error message to reflect number of seconds ([supabase#1540](supabase#1540)) ([e81c25d](supabase@e81c25d)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
LashaJini
pushed a commit
to LashaJini/auth
that referenced
this pull request
Nov 15, 2024
…upabase#1540) ## What kind of change does this PR introduce? Currently we use a constant value on number of seconds left before a developer can send a follow up email confirmation. This can prove confusing if developer has a custom setting for `MaxFrequency` on `Sms` or `SMTP` We change some core email related routes to show the exact number of seconds. This includes `signup`, `magic_link` and `email_change` The rest will follow should this change roll out smoothly. Tested the three flows locally by triggering the max frequency limit and checking that the number of seconds show up as expected.
LashaJini
pushed a commit
to LashaJini/auth
that referenced
this pull request
Nov 15, 2024
🤖 I have created a release *beep* *boop* --- ## [2.154.2](supabase/auth@v2.154.1...v2.154.2) (2024-06-24) ### Bug Fixes * publish to ghcr.io/supabase/auth ([supabase#1626](supabase#1626)) ([930aa3e](supabase@930aa3e)), closes [supabase#1625](supabase#1625) * revert define search path in auth functions ([supabase#1634](supabase#1634)) ([155e87e](supabase@155e87e)) * update MaxFrequency error message to reflect number of seconds ([supabase#1540](supabase#1540)) ([e81c25d](supabase@e81c25d)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What kind of change does this PR introduce?
Currently we use a constant value on number of seconds left before a developer can send a follow up email confirmation. This can prove confusing if developer has a custom setting for
MaxFrequencyonSmsorSMTPWe change some core email related routes to show the exact number of seconds. This includes
signup,magic_linkandemail_changeThe rest will follow should this change roll out smoothly. Tested the three flows locally by triggering the max frequency limit and checking that the number of seconds show up as expected.