Is your feature request related to a problem? Please describe.
By default the application registration URL is open to any logged in user. This works well for the documentation example project, but most people running through that process have a superuser that they've created via the command line.
Describe the solution you'd like
The way I'd implement this is to have a setting, with potential values of public, staff, superuser and the application registration page would then either be open as it is now, or check for is_staff or is_superuser as appropriate.
Describe alternatives you've considered
In a project where I have this issue, we also have django-braces installed which is great for this kind of thing. It's got a "requires staff mixin" so I've setup an app with a view inheriting the registration view and using this mixin. This view is then made available on the same path as the default view, with a test to make sure that the paths are the same.
Is your feature request related to a problem? Please describe.
By default the application registration URL is open to any logged in user. This works well for the documentation example project, but most people running through that process have a superuser that they've created via the command line.
Describe the solution you'd like
The way I'd implement this is to have a setting, with potential values of
public
,staff
,superuser
and the application registration page would then either be open as it is now, or check foris_staff
oris_superuser
as appropriate.Describe alternatives you've considered
In a project where I have this issue, we also have
django-braces
installed which is great for this kind of thing. It's got a "requires staff mixin" so I've setup an app with a view inheriting the registration view and using this mixin. This view is then made available on the same path as the default view, with a test to make sure that the paths are the same.