Re: Custom user models in 1.5, not flexible/dry enough?

I implemented a custom User model in my new project so I can sympathize with Ionel a bit. I wanted to change a few fields on User and have an admin with the same functionality as the 1.4 auth.User. This necessitated some copying and pasting to define the User's relations to auth.Group and auth

Re: Custom user models in 1.5, not flexible/dry enough?

I think it's basically a bit of an ambiguous reading of that section of the documentation: *"If you want your custom User model to also work with Admin, your User model must define some additional attributes and methods. These methods allow the admin to control access of the User to admin conte

Re: Custom user models in 1.5, not flexible/dry enough?

I think you are referring to https://docs.djangoproject.com/en/dev/topics/auth/#custom-users-and-django-contrib-admin But I don't want to re-implement those if they already exist on AbstractUser. I want exactly the same permission granularity as with non-custom User so I have to pull in the groups

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

> From my count there are 8 people in this thread in support of the >> functionality, and 2 people against it (1 at the time of my previous >> message). >> > > The bit you're possibly missing due to the way GMail handles some replied: > this thread was a respawn of an older thread from 6 month

Re: Custom user models in 1.5, not flexible/dry enough?

On Tue, Nov 6, 2012 at 7:59 AM, ionel wrote: > Hello, > > I'm trying to make a custom user model so I can login and register > with the email (instead of username). This means the email must become > unique and I don't need the username fields. I don't want to fill it > with random data, unique i

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

On Tue, Nov 6, 2012 at 7:48 AM, Jordan Hagan wrote: > I'm sorry if I came across that way, that wasn't my intention at all. > Andre Terra who was the one to initially raise opposition has changed his > stance on the functionality since he first posted, as per his email 4 days > ago. Aside from hi

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

On 6 November 2012 00:48, Jordan Hagan wrote: > > From my count there are 8 people in this thread in support of the > functionality, and 2 people against it (1 at the time of my previous > message). There is also lots of other people that don't feel the need to join the thread as they feel their

Re: Model forms error messages

I really don’t get it why this isn’t implemented right. The values of model.field.label and model.field.help_text are handled to the modelform so why not also handle model.field.error_messages -- You received this message because you are subscribed to the Google Groups "Django developers"

Custom user models in 1.5, not flexible/dry enough?

Hello, I'm trying to make a custom user model so I can login and register with the email (instead of username). This means the email must become unique and I don't need the username fields. I don't want to fill it with random data, unique ids, hashes or whatnot. Also, I need to have the admin wor

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

I'm sorry if I came across that way, that wasn't my intention at all. Andre Terra who was the one to initially raise opposition has changed his stance on the functionality since he first posted, as per his email 4 days ago. Aside from him there is Tino de Bruijn who voiced opposition, although h

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

On Tue, Nov 6, 2012 at 2:20 AM, Jordan Hagan wrote: > As it seems that there is no longer any real opposition to this ticket (if > there is, now would be the time to speak up) I'll go ahead and prepare a > patch against the current trunk and get it uploaded to trac and see where > we get to from

Re: contrib.contenttypes.generic importing from contrib.admin causing trouble

Hi Jens, does https://code.djangoproject.com/ticket/15654 describe what you see? >From my understanding it seems to be the same bug, patches welcome ;) Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussi

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

As it seems that there is no longer any real opposition to this ticket (if there is, now would be the time to speak up) I'll go ahead and prepare a patch against the current trunk and get it uploaded to trac and see where we get to from there. Hopefully I'll get a chance to take a look at this

Testing documentation

I have done some work on writing up a tutorial for testing (part 5 of the existing tutorial, in effect). My draft so far: I'd really appreciate feedback, on any aspect of this. Trac ticket is

contrib.contenttypes.generic importing from contrib.admin causing trouble

Not really sure what to use as subject here, or whether this qualifies to be called a bug, but I don't think it belongs on django-users due to being an issue in Django itself so I figured I'd ask here before opening a ticket. So, we have a project that doesn't use contrib.auth, and it doesn't use