#13164 closed (invalid)
Why contrib.auth does not do the registration/signup process?
| Reported by: | peyman | Owned by: | nobody |
|---|---|---|---|
| Component: | *.djangoproject.com | Version: | 1.1 |
| Severity: | Keywords: | ||
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Why contrib.auth does not do the registration/signup process?
Why do djangoproject.com use registration, an external package; instead, it could obviously use the contrib.auth code, instead of relying in external projects for such a small feature.
Thanks
Change History (5)
comment:1 by , 15 years ago
follow-up: 3 comment:2 by , 15 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:3 by , 15 years ago
| Resolution: | invalid |
|---|---|
| Status: | closed → reopened |
Replying to russellm:
Firstly, if you want to ask a question, ask on the mailing list. Trac is for identifying clear bugs or paths for improvement.
I have posted in the google groups of django. Isn't it the right place? I can try the mailing list if it is where it should go.
http://groups.google.com/group/django-users/browse_thread/thread/77a2d0a61ee42d4a
Secondly, The registration process isn't part of contrib.auth because there are lots of ways to handle registration. django-registration is certainly a very good example of a reusable application that implements registration, and it will handle a lot of use-cases, but it won't handle *every* possible registration use case.
I don't agree. django.auth should provide at least one solution for registration. It is such a frustration for new users to try to use contrib.auth, and finding that it does only half of the job.
Also, in contrib.auth.forms, why do we have UserCreationForm if there is no view to use it?
Finally, django-registration is an external package, with its own bugs, translations, community, managers, and terms of use. Why is not django suffisent by itself?
Thirdly, this is one excellent example of a place where we can demonstrate that something doesn't need to be in django trunk in order to be exceedingly useful.
I see that djangoproject.com uses this package. Obviously, the registration is very useful.
Finally, I have coded the missing registration views and forms for contrib.auth. Here is the code : http://peyman-django.blogspot.com/
I hope you will reconsider this, since the authentication feature is one of the most important and one of the first, new developers use with a new framework. They should be frustrated by it.
comment:4 by , 15 years ago
| Resolution: | → invalid |
|---|---|
| Status: | reopened → closed |
Firstly, don't reopen a ticket that a core developer has closed wontfix.
Secondly, if you've posted to the mailing list, you don't need a ticket as well. Once the issue is resolved on the mailing list *then* you open a ticket. Until then, I'm closing this ticket again, for the same reasons I said last time.
comment:5 by , 15 years ago
Understood. Sorry for that.
I will wait for your comments on the mailing list.
Regards.
Firstly, if you want to ask a question, ask on the mailing list. Trac is for identifying clear bugs or paths for improvement.
Secondly, The registration process isn't part of contrib.auth because there are lots of ways to handle registration. django-registration is certainly a very good example of a reusable application that implements registration, and it will handle a lot of use-cases, but it won't handle *every* possible registration use case.
Thirdly, this is one excellent example of a place where we can demonstrate that something doesn't need to be in django trunk in order to be exceedingly useful.