Hi Tim.
Thanks for posting this here. I was not aware of this ticket.
Thank you also for taking the initiative and starting moving on this front.
First of all, like you, I'm also recent in Django dev. This means that most
likely, we will both make mistakes in the approach.
The important is that we learn with them, and that is also why we are in a
community of more experience users.
Let me try to convey why is important that we take into account what other
people have already done (i.e. existing apps).
I'm using django-authtools; I found the the app is has tests and it is well
documented.
I'm using it in production and so far I didn't found any issue.
My point is: the main reason we try to use existing code is not because the
code is there, but because it is normally tested (both UnitTests and people
using it and reporting issues) and documented, which means it is less prone to
errors and more robust to integration.
That said, I would start by comparing APIs.
That allow us to have a solid ground on what there is already out there, to see
if any of the existing apps fulfils our expectations of what we would like to
have in the core.
I tried to clone your branch ticket_20824 from github to compare your app with
django-authtools, but it is (far) behind Django master branch, which is causing
merge conflicts that I don't know how to resolve (because I don't know what you
are exactly doing).
Maybe I'm doing something wrong or I don't know enough of git, but could you
please tell us (or maybe is just me that need to be told!) how can we compare
your patch with Django-master?
Let me try to give an example:
After taking a look at github.com/Liberationtech/django-libtech-emailuser, the
following are the main differences and similarities with django-authtools.
Please notice that I'm a (so far) 1-time comitter of django-authtools, so take
this comparison with appropriate care as I'm certainly biased.
Where they are similar:
1. Both are subclasses of AbstractBaseUser and PermissionsMixin (thus allow
permissions API to be used)
2. Both implement the required forms for creation, change, passwordReset.
3. Both implement admin interface
Where they are different:
1. Models implementation:
emailuser uses one model with 3 fields: email, first_name, last_name
(USERNAME_FIELD = 'email)
django-authtools uses defines three models:
A. AbstractUserMail (with one field 'email', like emailuser),
B. AbstractNamedUser, derived from AbstractUserMail with an additional
field "name".
C. User, derived from AbstractNamedUser, which is swappable and
non-abstract.
2. django-authtools has tests, emailuser doesn't
3. django-authtools is documented, emailuser doesn't
4. django-authtools implements views, emailuser doesn't.
5. they have different licences, but I don't know enough about them to know
what are the differences.
6. django-authtools passes on travis-ci.org tests, and, as far as I know,
enforces clean commit history (don't know if it is relevant thought).
7. usermail has a form to ask reset-password (by email?), but I didn't found
any implementation of the actual reset.
Tom, would you be willing to provide the differences and similarities of your
API with django-authtools and emailuser, or teach me how can I compare it
against django-master so I can make a comparison?
It would be nice to have your API documented here so we can take the most out
of the all existing implementations.
Best regards,
Jorge
On Sep 16, 2013, at 10:04 PM, tanderegg <timothy.ander...@gmail.com> wrote:
> Hey folks - I took a crack at implementing this, please check out my comment
> here (which contains a link to the branch in my fork):
> https://code.djangoproject.com/ticket/20824#comment:4
>
> Let me know if I missed anything!
>
> Tim
>
> On Friday, September 13, 2013 1:03:23 AM UTC-4, Aaron Merriam wrote:
> Check out django-authtools
>
> https://django-authtools.readthedocs.org/en/latest/
>
> Provides a few abstract base classes that make this very easy to accomplish.
> I'm sure there are other 3rd party apps doing the same.
>
>
> On Thursday, September 12, 2013 2:44:53 PM UTC-6, Abdulaziz Alfoudari wrote:
> This is a continuation of my post on stackoverflow.
>
> With the introduction of Django 1.5, it was possible to create a custom User
> model which is flexible enough to have any user profile the developer wants
> created. However, looking at a very common problem which is using the email
> as the primary user identifier instead of username, the solution requires
> copying most of Django's internal definition of AbstractUser and that is only
> to remove the username field.
>
> A better solution in my opinion is make AbstractUser even more abstract by
> removing username field, and allowing the developer to explicitly specify the
> field to be used as the user identifier. This will require a tiny extra work
> for those that use the current default behavior, but it will also greatly
> reduce the work needed for the very common problem of using email as the user
> identifier.
>
> Please share your thoughts and opinions on this.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
