On 9/11/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
>
> Are you guys also planning on
> removing the admin application's dependence on
> contrib.auth.models.User?
That's my long-term goal, but generic-auth isn't enough to get there.
is_staff, is_superuser, is_active, get_and_create_messages, and
p
Chris Long wrote:
> The generic auth branch should allow you to create your own custom
> permission checking system easily.
Well, I'm fine with the system that's already there (or the system that
generic auth will be replacing it with). Are you guys also planning on
removing the admin applicatio
sure I could do that.
not DRY though.
anyway, thanks for the hint.
patrick
Am 11.09.2006 um 17:21 schrieb Rob Hudson:
>
> patrickk wrote:
>> 2. when using a custom manipulator for letting the user change his
>> personal values (first name, last name, address, zip_code ...), I
>> have to change
patrickk wrote:
> 2. when using a custom manipulator for letting the user change his
> personal values (first name, last name, address, zip_code ...), I
> have to change 2 different tables (user and userprofile). that doesn
> ´t seem to be clean ... ???
Can you not put first name, last name, and
The generic auth branch should allow you to create your own custom
permission checking system easily.
Chris
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send ema
I agree that there is no one model that fits everyone's needs.
Instead, I think it would be nice if the user model to use could be
configurable. The admin application currently expects auth User
objects, when it should instead expect an object that conforms to an
interface, similar to the changes
On 9/10/06, patrickk <[EMAIL PROTECTED]> wrote:
> in my view, anything that´s not needed for user-authentication
> belongs to a user-profile. for me (and I may be wrong here) a user-
> profile is for personal information (like first name, last name,
> address and what have you).
As I see it, pari
I totally agree with what you say - and (if I understand you right)
that´s exactly my point.
it seems like a compromise. we don´t need first_name, last_name and
email for user-authentication. it´s just there because of an
assumption what users might need (or not).
some notes below:
Am 10.
On 9/10/06, patrickk <[EMAIL PROTECTED]> wrote:
> 1. why are these personal values (first name, last name, email) there
> in the first place? did I miss something?
The User model is not meant to be an exact match for the needs of 100%
of all possible authentication use cases; instead it's meant t
while playing with the authentication system, I don´t really get the
pre-defined model.
we have first_name, last_name and email in there - these values are
optional and we don´t need them for authentication. when I extend the
user-model with a user-profile I´m having (profile) values in 2
10 matches
Mail list logo
