Re: AbstractUser to get more abstract

[Aaron Merriam]

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.

Re: [GSoC] Revamping validation framework and merging django-secure once again

[Kevin Christopher Henry]

>
>
> We probably cannot move checks of `primary_key` and `unique` living in
> `FileField.__init__`. We test if one of these two parameters was passed; we
> don't check their values. Consider that an user passes unique=False. This 
> is
> the default value, but nevertheless, this should result in an error. We
> cannot check if the attributes where passed while performing system 
> checks. I'm
> not sure if I make myself clear.
>
>
Why not just store a reference to the original arguments (or the relevant 
subsets) in __init__(), and then validate them later in a system check? 
That may seem a little indirect, but I think the validation system will be 
much nicer if we can do everything in system checks instead of splitting 
the work with __init__().

I think there are other places as well where we'd like to do this kind of 
check. For example, right now you can create a OneToOneField with 
unique=False and Django will silently overwrite that value and your model 
will validate just fine. It would be much better if trying to specify 
unique on a OneToOneField caused a validation error, and the same sort of 
pattern could be applied there: storing a reference to the original value 
during __init__(), overwriting with unique=True for the purposes of 
initializing the parent ForeignKey, and then checking the user-supplied 
value in a separate system check. (This is just an example, I'm not saying 
that you should make this change to OneToOneField now, as it's 
backwards-incompatible.)

-- 
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.

Re: AbstractUser to get more abstract

[Russell Keith-Magee]

On Fri, Sep 13, 2013 at 4:44 AM, Abdulaziz Alfoudari <
aziz.alfoud...@gmail.com> 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.
>

The short answer: this isn't going to happen. AbstractUser is a released
and documented API, so we're not in a position to change it in the way you
describe without causing massive inconvenience to everyone that is using it
at present (at least, I don't see an obvious way that this could be done).

However, ticket #20824 describes a proposal to add an email-login analog of
Django's built-in user. This would make introduction of email-based login a
matter of 2 lines of configuration. This ticket is really just waiting on
someone to prepare a patch… and it should be a relatively simple patch to
prepare. If you're looking to get involved in Django development, this
would be an easy place to start.

Yours,
Russ Magee %-)

-- 
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.

Re: AbstractUser to get more abstract

[Cal Leeming [Simplicity Media Ltd]]

Although I cannot comment on the specific of how this could be done better,
I do at least concur that implementing a custom AbstractUser could be done
in a much better way!!

Cal


On Thu, Sep 12, 2013 at 9:44 PM, Abdulaziz Alfoudari <
aziz.alfoud...@gmail.com> 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.

AbstractUser to get more abstract

[Abdulaziz Alfoudari]

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.

Re: Possible breakage of queryset week_day lookup - potential 1.6 release blocker?

[Aymeric Augustin]

2013/9/12 Matt Austin 
>
> I've tried the lookups on a new mysql installation (no tzinfo loaded),
> and '__month', '__day', and '__week_day' lookups all cause an empty
> queryset to be returned. However, '__year' does appear to return the
> correct results.
>

Indeed, year lookups aren't affected by this issue because they're
translated into a range lookup (after Jan 1st, before Dec 31st) in order to
take advantage of indexes.

-- 
Aymeric.

-- 
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.

Re: Possible breakage of queryset week_day lookup - potential 1.6 release blocker?

[Matt Austin]

Hi Aymeric,

On 12 September 2013 18:16, Aymeric Augustin
 wrote:
> Can you confirm that your project has the USE_TZ setting set to True?

Yes, USE_TZ is True, pytz is installed, and default timezone is set to UTC.


> I believe I introduced it with a patch that made the date lookups (__year, 
> __month, __day, __week_day) take the time zone into account. Previously they 
> would consider the date in UTC when USE_TZ = True, which returned incorrect 
> results. Since this was a bugfix, I didn't mention it in the release notes.
>

> The problem probably affects all four date lookups. If you have time to test 
> this, it would help.

I've tried the lookups on a new mysql installation (no tzinfo loaded),
and '__month', '__day', and '__week_day' lookups all cause an empty
queryset to be returned. However, '__year' does appear to return the
correct results.

Thanks for investigating.

--
Matt

-- 
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.

Re: Allowing custom attributes in Meta classes

[code22]

+1 for this. 

Use case: in one of our projects we had to mark fields allowed for 
publishing. Using additional meta option would be great for that and I've 
regretted that it's impossible.  

W dniu wtorek, 10 września 2013 06:27:29 UTC+2 użytkownik Karan Lyons 
napisał:
>
> Hey all,
>
> I recently opened up a ticket (https://code.djangoproject.com/ticket/21081) 
> that turns out to be a dupe of https://code.djangoproject.com/ticket/5793, 
> both in regards to allowing custom attributes in a model's Meta class.
>
> It was wontfix'd six years ago, the reasoning being that Meta should 
> really only be for setting options related to Django internals. I'm 
> personally of the opinion that at this point Meta is considered the place 
> for *any* options related to a model by developers, and that handling 
> custom options outside of Meta seems against the general Django coding 
> style. Currently you can come up with hacks like 
> https://github.com/karanlyons/django-save-the-change/blob/feature/update-together/save_the_change/mixins.py#L188to
>  take care of the issue, but this isn't very nice for a number of reasons.
>
> Do we think this should still be a wontfix, and are there any other 
> reasons why?
>

-- 
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.

Re: Support POST of application/json content type

[S Berder]

Tom,
I get the context and that form is tied to that behavior but outside of
"that's how it is now" is there any technical reason for this? I can't read
forms code at the moment but will do tonight and will look at how FILES is
used in there. I'm not usually afraid by impacts of it's the "right thing
to do". I think it would make for a stronger interface of you could simply
find your data in request.data.

I will create a branch in my fork on github and will send it here for
progress.

Stefan, from my mobile
-- 
http://www.bonz.org/
/(bb|[^b]{2}/
On 12 Sep 2013 18:20, "Tom Christie"  wrote:

> > why keep data and files separated
>
> Mostly because that's the way it already works, so...
>
> * request.data would essentially provide a strict superset of the
> functionality that request.POST provides.  In general you'd be able to
> replace `request.POST` with `request.data` anywhere and seemlessly start
> supporting JSON or other data without any other changes required.
> * Form expect the data and files to be provided separately which would be
> awkward otherwise.
>
> > In the absence of strong objection, I will start working on this base.
>
> Sure thing.  As it happens, I was also considering taking a crack at this
> in the coming weeks, so please do follow up on this thread linking to your
> repo if you start working on it, so myself and others can track any
> progress.  (And perhaps collaborate.)
>
> Cheers :)
>
>   Tom
>
> On Wednesday, 11 September 2013 04:52:08 UTC+1, Stefan Berder wrote:
>>
>> On Tue, Sep 10, 2013 at 12:17 PM, S Berder  wrote:
>> > On Tue, Sep 10, 2013 at 9:05 AM, Curtis Maloney
>> >  wrote:
>> >>
>> >> On 9 September 2013 19:50, S Berder  wrote:
>> >>>
>> >>> Gents,
>> >>> to sum it up, arguments made and details of how I see the
>> >>> implementation of a response/request encode/decode framework:
>> >>>
>> >>> * need a pluggable interface so current content-types are supported
>> >>> (`application/x-www-form-**urlencoded`, `multipart/form-data`), new
>> >>> types (`application/json`), custom and future types
>> >>> (`application/vnd.foobar+json` anybody? See
>> >>> http://developer.github.com/**v3/media/#api-v3-media-type-**
>> and-the-future
>> >>> for example, `application/msgpack`, `application/protobuf`,
>> >>> `application/capnproto`, etc).
>> >>> * decoder/encoder map (content-type, decoder) should be smart to
>> >>> handle patterns like `text/*` or `application/*xml*` and match things
>> >>> like `Accept: application/json, text/plain, * / *`
>> >>> * choice of decoder would be made on the Content-Type header, maybe
>> >>> supporting a raw by default so data is just passed in case of unknown
>> >>> content type.
>> >>> * decoder/encoder should be available through `request` and
>> `response`
>> >>> objects.
>> >>> * decoded data structure (python object) would be stored in
>> `request.data`
>> >>> * first step is to support requests, next step is to handle responses
>> >>> with the same pluggable functionality and coherent API.
>> >>> * A sensible default for response Content-type would be `text/html;
>> >>> charset=UTF-8`. It should be made available through a setting entry
>> >>> anyway
>> >>>
>> >>
>> >> You should also have access to the decision made by the data parser as
>> to
>> >> which parser was used, instead of having to infer it yourself from the
>> >> content type header.
>> >
>> > Indeed, that's the 4th point of my list, maybe it's not clear as it is
>> > but this would be supported.
>> >
>> >>>
>> >>> Some questions though:
>> >>>
>> >>> * why keep data and files separated, I see no good reason for this
>> >>> except mimicking PHP's structure. An uploaded file comes from a named
>> >>> input, I hope to find it in request.data (why do a common structure
>> >>> otherwise). I might be missing something but nothing indicates a real
>> >>> need for this in django/http/request.py
>> >>
>> >>
>> >> True, there's some added complexity [small as it is] in forms because
>> File
>> >> fields need to look elsewhere for their values.
>> >>
>> >>>
>> >>> * isn't more or less any data sent to your backend representable as a
>> >>> dict or object with dict access modes? I try to think about
>> >>> occurrences where some data would not have a 'name'.
>> >>>
>> >>
>> >> I frequently send JSON lists of data to my APIs...
>> > Ok, was a bit short sighted on this one, still thinking in terms of
>> > form bound data, it was a long day here in Shanghai. I suppose that
>> > the kind of python object you receive is not so important as you
>> > should do data validation anyway. Your earlier concern about checking
>> > for different content-types doesn't apply to the solution I have in
>> > mind as to whatever data representation you have at the beginning, you
>> > should get a very similar object after decoding. What I mean is if you
>> > send the *same* data through Yaml or JSON, the object in request.data
>> > shoul

Re: Support POST of application/json content type

[Tom Christie]

> why keep data and files separated

Mostly because that's the way it already works, so...

* request.data would essentially provide a strict superset of the 
functionality that request.POST provides.  In general you'd be able to 
replace `request.POST` with `request.data` anywhere and seemlessly start 
supporting JSON or other data without any other changes required.
* Form expect the data and files to be provided separately which would be 
awkward otherwise.

> In the absence of strong objection, I will start working on this base. 

Sure thing.  As it happens, I was also considering taking a crack at this 
in the coming weeks, so please do follow up on this thread linking to your 
repo if you start working on it, so myself and others can track any 
progress.  (And perhaps collaborate.)

Cheers :)

  Tom

On Wednesday, 11 September 2013 04:52:08 UTC+1, Stefan Berder wrote:
>
> On Tue, Sep 10, 2013 at 12:17 PM, S Berder > 
> wrote: 
> > On Tue, Sep 10, 2013 at 9:05 AM, Curtis Maloney 
> > > wrote: 
> >> 
> >> On 9 September 2013 19:50, S Berder > 
> wrote: 
> >>> 
> >>> Gents, 
> >>> to sum it up, arguments made and details of how I see the 
> >>> implementation of a response/request encode/decode framework: 
> >>> 
> >>> * need a pluggable interface so current content-types are supported 
> >>> (`application/x-www-form-urlencoded`, `multipart/form-data`), new 
> >>> types (`application/json`), custom and future types 
> >>> (`application/vnd.foobar+json` anybody? See 
> >>> http://developer.github.com/v3/media/#api-v3-media-type-and-the-future 
> >>> for example, `application/msgpack`, `application/protobuf`, 
> >>> `application/capnproto`, etc). 
> >>> * decoder/encoder map (content-type, decoder) should be smart to 
> >>> handle patterns like `text/*` or `application/*xml*` and match things 
> >>> like `Accept: application/json, text/plain, * / *` 
> >>> * choice of decoder would be made on the Content-Type header, maybe 
> >>> supporting a raw by default so data is just passed in case of unknown 
> >>> content type. 
> >>> * decoder/encoder should be available through `request` and `response` 
> >>> objects. 
> >>> * decoded data structure (python object) would be stored in 
> `request.data` 
> >>> * first step is to support requests, next step is to handle responses 
> >>> with the same pluggable functionality and coherent API. 
> >>> * A sensible default for response Content-type would be `text/html; 
> >>> charset=UTF-8`. It should be made available through a setting entry 
> >>> anyway 
> >>> 
> >> 
> >> You should also have access to the decision made by the data parser as 
> to 
> >> which parser was used, instead of having to infer it yourself from the 
> >> content type header. 
> > 
> > Indeed, that's the 4th point of my list, maybe it's not clear as it is 
> > but this would be supported. 
> > 
> >>> 
> >>> Some questions though: 
> >>> 
> >>> * why keep data and files separated, I see no good reason for this 
> >>> except mimicking PHP's structure. An uploaded file comes from a named 
> >>> input, I hope to find it in request.data (why do a common structure 
> >>> otherwise). I might be missing something but nothing indicates a real 
> >>> need for this in django/http/request.py 
> >> 
> >> 
> >> True, there's some added complexity [small as it is] in forms because 
> File 
> >> fields need to look elsewhere for their values. 
> >> 
> >>> 
> >>> * isn't more or less any data sent to your backend representable as a 
> >>> dict or object with dict access modes? I try to think about 
> >>> occurrences where some data would not have a 'name'. 
> >>> 
> >> 
> >> I frequently send JSON lists of data to my APIs... 
> > Ok, was a bit short sighted on this one, still thinking in terms of 
> > form bound data, it was a long day here in Shanghai. I suppose that 
> > the kind of python object you receive is not so important as you 
> > should do data validation anyway. Your earlier concern about checking 
> > for different content-types doesn't apply to the solution I have in 
> > mind as to whatever data representation you have at the beginning, you 
> > should get a very similar object after decoding. What I mean is if you 
> > send the *same* data through Yaml or JSON, the object in request.data 
> > should be the same or extremely close. I say extremely close because 
> > I'm thinking about xml that is always way more verbose than the others 
> > and *might* add more data to the resulting object. (hint: I don't like 
> > XML, don't need it in what I do and last used it ~8/9 years ago in a 
> > disastrous explosion of SOAP and unix/microsoft interfaces) 
> > 
> > Stefan 
> > -- 
> > http://www.bonz.org/ 
> >  /(bb|[^b]{2})/ 
>
> In the absence of strong objection, I will start working on this base. 
>
> Stefan 
> -- 
> http://www.bonz.org/ 
>  /(bb|[^b]{2})/ 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and

Re: Possible breakage of queryset week_day lookup - potential 1.6 release blocker?

[Aymeric Augustin]

Hi Matt,

2013/9/12 Matt Austin 

> I discovered today that unless timezone data is loaded in to mysql, then
> previously working (although functionally broken) week_day lookups return
> an empty queryset.
>
> I couldn't find notes in the docs (release notes or queryset week_day
> docs) that mention this requirement - but happened to read the docs for the
> new datetimes() behaviour and then discovered how to load tzinfo in to
> mysql.
>
> I filled a ticket to update the docs:
> https://code.djangoproject.com/ticket/21095
>

Thanks for filing this ticket. I noticed it this morning and planned to
investigate it.

Can you confirm that your project has the USE_TZ setting set to True?


> I am happy to contribute modifications to the docs - but before I do, I
> thought it might be worth seeing if this is the correct approach.
>
> Should an empty list be the desired behaviour, should an exception be
> raised, or should the old behaviour (which doesn't honour timezones) be
> maintained when tzinfo is not available?
>

I believe I introduced it with a patch that made the date lookups (__year,
__month, __day, __week_day) take the time zone into account. Previously
they would consider the date in UTC when USE_TZ = True, which returned
incorrect results. Since this was a bugfix, I didn't mention it in the
release notes.

I didn't realize it was a backwards-incompatible change, considering that
"no results at all" is much worse than "results off by a few hours". (On a
side note, I love MySQL's helpful error handling.)

The solution is indeed to add a paragraph describing this backwards
incompatibility in the release notes, as well as a warning in the docs for
the date lookups if there's not one already (IIRC there is).

The problem probably affects all four date lookups. If you have time to
test this, it would help.

Thanks again,

-- 
Aymeric.

-- 
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.

Possible breakage of queryset week_day lookup - potential 1.6 release blocker?

[Matt Austin]

I discovered today that unless timezone data is loaded in to mysql, then
previously working (although functionally broken) week_day lookups return
an empty queryset.

I couldn't find notes in the docs (release notes or queryset week_day docs)
that mention this requirement - but happened to read the docs for the new
datetimes() behaviour and then discovered how to load tzinfo in to mysql.

I filled a ticket to update the docs:
https://code.djangoproject.com/ticket/21095

I am happy to contribute modifications to the docs - but before I do, I
thought it might be worth seeing if this is the correct approach.

Should an empty list be the desired behaviour, should an exception be
raised, or should the old behaviour (which doesn't honour timezones) be
maintained when tzinfo is not available?

-- 
Matt
m...@mattaustin.me.uk
http://mattaustin.me.uk/

-- 
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.