Open david-code opened 1 year ago
I would enjoy if all/most allauth settings were in our custom model including oidc's server_url. I wonder how feasible this might be? Is there a way we could tackle these settings all at once instead of one at a time? We could potentially use a HStore or JSON field for flexible data. For reference, upstream didn't seem interested in this. I think it would be a popular feature and could even merit it's own tiny open source project, maybe as a django app + allauth provider.
is_private
Yes that makes sense to me. I have always seen that as the future of this work. Any field that is frequently filtered or benefits from constraints should be relational. Any field like auto_signup I think is better for json/hstore.
Ideally - an org like Terraso would sign up for kf.kobotoolbox.org, create an organization, and set their own SSO provider. I think a lot of users would appreciate this type of feature. We are already working on teams and organizations internally. Let me know if you think this is too much.
Description
In Terraso, users aren't provided with a signup form. Ideally we would like for users coming from Terraso to sign up for a KoBo Toolbox account to have the same experience and skip the signup form. This issue describes a proposal on how to accomplish this.
Feature
The feature would work similarly to django-allauth's config setting
SOCIALACCOUNT_AUTO_SIGNUP
. When setTrue
, this variable takes the username and email retrieved from the SSO client to try automating the signup. If a new user with the username and email does not exist in the database, the user is created and the signup form is bypassed. If not, the signup form is displayed as usual.Instead of working for all apps like the config variable, however, we would add the setting to the
SocialAppCustomData
model, letting individual social apps control if they want to bypass the signup form or not. The default would be to set this variable toFalse
and not bypass signup.Implementation
Here's a rough sketch of how to achieve this:
SocialAppCustomData
class would be modified to add a variable (probablyauto_signup
), defaulting toFalse
SocialAppAdapter
. Specifically, in theis_auto_signup_allowed method
implementation would be overriden. In the method we would call the parent method, and if the result isTrue
, we would returnTrue
; ifFalse
we’d checkSocialApp
hasauto_signup
setTrue
and returnTrue
if soFalse
; else returnTrue
As the association of a
SocialAppCustomData
to aSocialApp
implies that the app is "private", this could only be applied for private apps. This behaviour ofSocialAppCustomData
could also be changed in a separate PR to add a separateis_private
boolean if desired (or some other behaviour).