-
Notifications
You must be signed in to change notification settings - Fork 977
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
feat: make notification to unknown recipients configurable #3075
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3075 +/- ##
==========================================
- Coverage 77.45% 77.30% -0.16%
==========================================
Files 315 315
Lines 19955 19849 -106
==========================================
- Hits 15457 15345 -112
- Misses 3297 3309 +12
+ Partials 1201 1195 -6
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it 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.
Found a few minor issues to improve this
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.
Looking great! Should we add an e2e test covering this case? Or does it not make sense? I'm fine with both
Tests are failing, and I can't repro locally. Going to take another look tomorrow... 😓 |
Maybe the feature is enabled on accident for that e2e test, it looks like the test is expecting an email but not receiving one |
The config schema didn't match the config for the key. I fixed that. Just to double-check, the config schema is manually written, right? And I assume, there is no practical way to generate it? |
Correct and correct |
I thought about this a bit, and IMO it doesn't make sense to test for an email not arriving. As in theory, we'd need to wait an indefinite amount of time to be sure that no email arrives. This would slow down the E2e test pipeline. I have updated the existing tests that test for the email arriving to enable this feature. We already test this config in the go-tests, by checking the DB, which is good enough, IMO. |
@@ -292,7 +292,7 @@ context("2FA TOTP", () => { | |||
|
|||
// The React app keeps using the same flow. The following scenario used to be broken, | |||
// because the internal context wasn't populated properly in the flow after settings were saved. | |||
it.only("should allow changing other settings and then setting up totp", () => { | |||
it("should allow changing other settings and then setting up totp", () => { |
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.
Looks like this was forgotten a few weeks ago. These tests are still passing, though. So crisis averted.
Would be great to have an ESLint rule or some mechanism to prevent .only
s ending up on master. But AFAICT, there is nothing of that sort for cypress :(
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.
Yes please! :)
@@ -138,12 +140,15 @@ context("Account Verification Error", () => { | |||
}) | |||
}) | |||
|
|||
it("unable to verify non-existent account", async () => { | |||
cy.get('input[name="email"]').type(gen.identity().email) | |||
it("unable to verify non-existent account", () => { |
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.
async
prevented this test from being executed properly. So it never actually tested what it was supposed to.
I checked, and this seemed to be the only instance of an async
test body.
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.
LGTM, as discussed on Slack, one test change
Added the test to the appropriate places. |
Related issue(s)
Closes #2345 & supersedes #2585
Checklist
introduces a new feature.
contributing code guidelines.
vulnerability. If this pull request addresses a security vulnerability, I
confirm that I got the approval (please contact
[email protected]) from the maintainers to push
the changes.
works.
Further Comments