Closed xcoulon closed 5 years ago
Looks good. But shouldn't we also use this list in user deactivation notification thing too? It can be confusing if we keep sending notifications but never deactivate such users.
oh, right, I changed the wrong method! 😤🤦♂️
Merging #859 into master will increase coverage by
0.01%
. The diff coverage is100%
.
@@ Coverage Diff @@
## master #859 +/- ##
==========================================
+ Coverage 78.16% 78.17% +0.01%
==========================================
Files 100 100
Lines 9429 9431 +2
==========================================
+ Hits 7370 7373 +3
+ Misses 1518 1517 -1
Partials 541 541
Impacted Files | Coverage Δ | |
---|---|---|
authentication/account/service/user.go | 80.95% <100%> (ø) |
:arrow_up: |
configuration/configuration.go | 81.9% <100%> (+0.08%) |
:arrow_up: |
authentication/account/repository/identity.go | 76.82% <100%> (+0.12%) |
:arrow_up: |
...rovider/service/authentication_provider_service.go | 73.33% <0%> (+1.11%) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 22bd410...da99f93. Read the comment docs.
Use a configuration-based list of usernames to exclude from the user deacvation. It's enough if those users are not notified: they won't have a scheduled deactivation either.
Fixes #ODC1007
Signed-off-by: Xavier Coulon xcoulon@redhat.com