We require either allowed_email_addresses or allowed_email_domains to be passed in either as a default or for each upstream, however this limits the usability of email groups as a functional validator. It's difficult to validate a user based on groups alone if you also have to specify email addresses or email domains, for example -- it requires work arounds which should be avoided.
Solution
Require allowed_email_addresses, allowed_email_domainsORallowed_groups instead. This means the email group validator can still be used simultaneously with others, but also standalone which allows for a sometimes more expected workflow.
Notes
This PR also removes functionality that means if an empty list of groups is passed in to the validator then the user is automatically 'valid' per the group validator. If a group validator can be the only validator, I don't think this logic makes sense (however there may be other historic reasons why this was allowed that I'm unaware of)
Problem
We require either
allowed_email_addressesorallowed_email_domainsto be passed in either as a default or for each upstream, however this limits the usability of email groups as a functional validator. It's difficult to validate a user based on groups alone if you also have to specify email addresses or email domains, for example -- it requires work arounds which should be avoided.Solution
Require
allowed_email_addresses,allowed_email_domainsORallowed_groupsinstead. This means the email group validator can still be used simultaneously with others, but also standalone which allows for a sometimes more expected workflow.Notes
This PR also removes functionality that means if an empty list of groups is passed in to the validator then the user is automatically 'valid' per the group validator. If a group validator can be the only validator, I don't think this logic makes sense (however there may be other historic reasons why this was allowed that I'm unaware of)