Re: ANN: Django 1.4 string freeze and translation updates needed
Hello, A second RC was just released [2]; it includes translations contributed until yesterday (roughly 2012-03-14 08:50:00 UTC). If everything goes according to plan, the final 1.4 release will happen on March 21st. We'll probably pull the translations from Transifex on March 20th. I'd like to draw the attention of the Russian maintainers to ticket #17901; at least one string appears to be off in the admin translations [3]. Thanks and keep up the good work! -- Aymeric. [1] https://www.djangoproject.com/weblog/2012/mar/14/14rc2/ [2] https://code.djangoproject.com/ticket/17901 [3] https://www.transifex.net/projects/p/django/resource/contrib-admin/l/ru/view/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Custom permissions on proxy model no longer created in 1.4
Hi all,
this could very well be one of those "don't do that" things, but here is my
problem.
I have been using some specific permissions concerning the auth user model,
so I created a proxy model on user like this:
class User(auth_models.User):
class Meta:
proxy = True
permissions = (
("display_users", "May display users information"),
("edit_users", "May edit users information"),
)
In 1.3 these custom permissions were created during syncdb (linked to the
auth.User model).
Now I was testing my project with the 1.4 RC, and it turns out those
permissions are no longer created.
This is caused by the refactor of the create_permissions code, which now
uses get_for_models to determine the class to get the options for, but this
returns the proxied class (auth.User), not the proxy class, so my custom
permissions are not found and not created.
Maybe I am using the proxy model for something it was not intended for. If
so, it might be a good idea to add a warning in the release notes about
this, in case others are doing something similar.
BTW, thanks for yet another awesome new release.
Koen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/gdAd5dGloeoJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: authentication by email
On Mon, Mar 12, 2012 at 16:57, Clay McClure wrote: >[...] > New django projects can elect to use an entirely different pluggable auth >[...] > The pluggable-auth-apps fork is barely two days old, so it's still rough > around the edges, and I've almost certainly missed some things. I haven't >[...] I'm sorry I don't know if I like that. I hope I understand correctly what you're doing, and that my criticism is seen as constructive. This sells itself as "pluggable auth" but really only provides the originally requested auth by email, and I don't see how it could go from there, i.e. what else would be possible (in regards to auth). Pulling username and email out of (Base)User and then bringing one or both of them - and the logic of which to check - back in, is not really a pluggable auth. It's the mixing of profile and information relevant to authentication (and authorization - is_staff?) that's another problem of the existing User model, and this is where this approach allows for dangerous developments. You've pulled those two out and said it's up to the chosen auth to decide a) which to even include in the User model b) which is used to authenticate and which is just "secondary" user (profile?) information. What about first_name and last_name? Why can't a pluggable auth dump those from the User model? And certainly an "auth" should get to have a say about "password". And then... there's not much left anymore in that (Base)User model, right... (GSoC: "reducing the user table to little more than an identifying primary key") Ok email auth problem solved. But now there's a simple way of providing any User model I like, so first thing I'm going to do is to bring in what I think the User should look like i.e. use the "auth" to define what really is a "profile". And so will lots of projects. "The User model needs a username for this app to work". "The User model needs a timezone for this app to work". etc. I'd like to see a later, "proper" auth.user that can undo that chaos. Cheers, Danny -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: authentication by email
On Thu, Mar 15, 2012 at 22:53, Danny Adair wrote: >[...] > I'd like to see a later, "proper" auth.user that can undo that chaos. I originally thought you intended a setting which let's the user switch from the existing auth to an email auth with corresponding User model. As lame as that may be - at least a later, "proper" auth.user solution would only have two known (shipped) auths to deal with. Cheers, Danny -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Custom permissions on proxy model no longer created in 1.4
Le 15 mars 2012 10:27, koenb a écrit : > this could very well be one of those "don't do that" things, but here is > my problem. > > I have been using some specific permissions concerning the auth user model (... snip ...) Now I was testing my project with the 1.4 RC, and it turns out those > permissions are no longer created. > Hi Koen, At first sight, you code is valid, and this is a regression. I suppose it happened somewhere in this list: https://code.djangoproject.com/log/django/trunk/django/contrib/auth/management/__init__.py Could you open a ticket on code.djangoproject.com and set Severity to "Release blocker"? Thanks, -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Custom permissions on proxy model no longer created in 1.4
Op donderdag 15 maart 2012 11:52:42 UTC+1 schreef Aymeric Augustin het volgende: > > Le 15 mars 2012 10:27, koenb a écrit : > >> this could very well be one of those "don't do that" things, but here is >> my problem. >> >> I have been using some specific permissions concerning the auth user model > > (... snip ...) > > Now I was testing my project with the 1.4 RC, and it turns out those >> permissions are no longer created. >> > > Hi Koen, > > At first sight, you code is valid, and this is a regression. > > I suppose it happened somewhere in this list: > > https://code.djangoproject.com/log/django/trunk/django/contrib/auth/management/__init__.py > > Could you open a ticket on code.djangoproject.com and set Severity to > "Release blocker"? > > Thanks, > > -- > Aymeric. > Done: #17904 Koen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/VhZC9AxfB9sJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Composite Key at Europython
I'd like speak at europython about a project on composite primary and foreign key for Django. https://github.com/simone/django-compositekey This solution that I'm using on a very small realty. I've developed using monkey some patch because the purpose was not forking django. Is more easy introduce a small library in a project that a fork of django itself. So I was preparing the paper to submit to Europython when I saw the konk (Michal Petrucha) fork of Django, that is envolved on "composite key problem". [Hey Michal nice to meet you]. Now, I'd like meet someone at Europython to speak about this project, and how the multiple primary/foreign key will be introduced in Django. Maybe in 1.5? Do you think it will be possible? I think this is possible. Michal do you think to fly on florence next July? someone else wants to join the idea? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
[1.4] SECRET_KEY deprecation is confusing...
Hi, There is a problem in 1.4rc2 where a missing SECRET_KEY causes Django to refuse to start. According to the current version of the release notes on the website: *In Django 1.4, starting Django with an empty SECRET_KEY will raise a DeprecationWarning. In Django 1.5, it will raise an exception and Django will refuse to start.* * * This doesn't make sense... It currently raises DeprecationWarning which is an exception which causes Django to fail to start. To trigger a deprecation warning while allowing execution to continue you need to use warnings.warn(). As things stand you are essentially implementing the behaviour for both 1.4 *and* 1.5! Cheers, Nick -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/lYpYVlaGlZYJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: authentication by email
Tom makes a good point, but you can already store emails in the username, they are just limited to 30 characters or fewer. Lift this length restriction and I will be able to do everything I need without having to wait for contrib.auth2. In the 'I use django to make a living' world the solution doesn't have to be perfect just good enough. The talk of lazy foreign keys just so we can create contrib.auth2 just rubs me the wrong way, adds additional complexity, and I see no benefit of it over a UserProfile model or with model inheritance. And Django developer ought to be familiar how to do a schema migration for this simple change, and if they fail to know instructions can be provided in the release notes; there is NO need to have progress being stalled because there is no built automated schema migration. Why can we not just increase the length limit on the username field?, Why can't we just throw a validation error if data entered is to long and the schema has not been updated? I think the answer yes we can and easily. -Original Message- From: Tom Evans Sent: Friday, March 09, 2012 11:46 AM To: django-developers@googlegroups.com Subject: Re: authentication by email On Fri, Mar 9, 2012 at 3:52 PM, Luke Plant wrote: On 09/03/12 14:49, Tom Evans wrote: Yes, since no one needs it. Okay no one isn't true, but no one (for true this time) who needed it stepped up and said "I'll implement it and see that it ends up in trunk" I'm sorry, that completely mis-characterises the situation. Lots of people want this, but every single time this has been brought up since I started using django (1.0), a core dev or BFDL has explicitly ruled it out, saying "we cannot do this, requires schema migration, we'll look at it for the next version". This is not true. There have been times when we have said we cannot consider it right now, and that a solid proposal should be brought up at the calls for proposals for 1.1/1.2/1.3 etc., or at other times when the core developers can look at it. And every time, the proposal has either been missing or simply not been adequate - for example, the GSoC 2010 and 2011 proposals regarding this. Russell gave detailed feedback on why these solutions were not adequate [1], and at other times has provided feedback on possible strategies [2]. And the people who went away to work on the problem have gone silent or admitted defeat. One presumes they fixed their immediate problem in a way that would not be a general solution, and moved on, and that is perfectly understandable. A adequate solution to this is very hard, and probably requires solving several other big problems first (like at least one of lazy foreign keys/virtual models/database migrations). It isn't, however, impossible. Our definition of 'need' is that someone is sufficiently motivated to overcome the obstacles, and contribute a solution that works for other people as well as themselves. Regards, Luke [1] http://goo.gl/swTpr [2] http://goo.gl/7p1JN I disagree. There are small problems with the User model that have not been fixed. Every proposal you've listed does not address these issues, but instead looks to find ways of replacing the base user object, which is a complex and difficult project. There is a reason why these are the proposals. Every time someone proposes fixing these minor bugs, the cry from on high is that instead, d.c.auth will be overhauled to allow for more customization by the project, immediately increasing the scope and complexity. But this fabled d.c.auth2 never appears. In fact, your reply alludes to this. We're talking about why a field is too short to contain valid values, and you suggest that the solution inevitably will involve "lazy foreign keys/virtual models/database migrations" - it's changing one line, and adding a comment to relnotes! We may have to agree to disagree on how easy some of these things are to fix. Lets look at one isolated aspect. The User email field in d.c.auth is too short. Emails can be up to 248 characters long, and d.c.auth only allows 75. Clearly, this is a bug, is wrong and should be fixed. How can we fix it? We can alter the length of the field in the model definition. What problems does this bring? Users who do not manually update their database will not be able to store longer length emails, and will get 'strange effects' when they try - either silent truncation, or database integrity errors. How can we mitigate this for users who refuse to update? Provide a compat shim that resets the email length to that in 1.3, and immediately mark it PendingDeprecation. Users who read the relnotes and don't want to change their DB can use the shim, and have a clear expectation of when they must have updated their database. I still think these bug fixes are paralysed by a fear of change, and a desire to engineer a solution that is every thing to every man. Lets just fix these glaring bugs… Cheers Tom -- You received this message b
Re: authentication by email
On March 15, 2012, at 11:24 , Daniel Sokolowski wrote: > Tom makes a good point, but you can already store emails in the username, > they are just limited to 30 characters or fewer. Lift this length restriction > and I will be able to do everything I need without having to wait for > contrib.auth2. In the 'I use django to make a living' world the solution > doesn't have to be perfect just good enough. The talk of lazy foreign keys > just so we can create contrib.auth2 just rubs me the wrong way, adds > additional complexity, and I see no benefit of it over a UserProfile model or > with model inheritance. > > And Django developer ought to be familiar how to do a schema migration for > this simple change, and if they fail to know instructions can be provided in > the release notes; there is NO need to have progress being stalled because > there is no built automated schema migration. > > Why can we not just increase the length limit on the username field?, Why > can't we just throw a validation error if data entered is to long and the > schema has not been updated? I think the answer yes we can and easily. Wouldn't increasing the length of the username field *also* incur a schema migration? After all, anyone who has spun up a Django site previous to the change would have a CHARACTER VARYING(30) (or a VARCHAR(30) or whatever the appropriate database-specific type is) in their database. So, we'd have a situation where Django would accept a 40 character email address, but then the database would truncate it or error out. The argument that Django developers ought to know how to do the schema migrations themselves seems poor to me. I expect some don't, and it's certainly a bigger backwards incompatible change than the Django development community has traditionally been comfortable with. Regards, Luke > > -Original Message- From: Tom Evans > Sent: Friday, March 09, 2012 11:46 AM > To: django-developers@googlegroups.com > Subject: Re: authentication by email > > On Fri, Mar 9, 2012 at 3:52 PM, Luke Plant wrote: >> On 09/03/12 14:49, Tom Evans wrote: >> Yes, since no one needs it. Okay no one isn't true, but no one (for true this time) who needed it stepped up and said "I'll implement it and see that it ends up in trunk" >>> >>> I'm sorry, that completely mis-characterises the situation. Lots of >>> people want this, but every single time this has been brought up since >>> I started using django (1.0), a core dev or BFDL has explicitly ruled >>> it out, saying "we cannot do this, requires schema migration, we'll >>> look at it for the next version". >> >> This is not true. There have been times when we have said we cannot >> consider it right now, and that a solid proposal should be brought up at >> the calls for proposals for 1.1/1.2/1.3 etc., or at other times when the >> core developers can look at it. >> >> And every time, the proposal has either been missing or simply not been >> adequate - for example, the GSoC 2010 and 2011 proposals regarding this. >> Russell gave detailed feedback on why these solutions were not adequate >> [1], and at other times has provided feedback on possible strategies >> [2]. And the people who went away to work on the problem have gone >> silent or admitted defeat. One presumes they fixed their immediate >> problem in a way that would not be a general solution, and moved on, and >> that is perfectly understandable. A adequate solution to this is very >> hard, and probably requires solving several other big problems first >> (like at least one of lazy foreign keys/virtual models/database migrations). >> >> It isn't, however, impossible. Our definition of 'need' is that someone >> is sufficiently motivated to overcome the obstacles, and contribute a >> solution that works for other people as well as themselves. >> >> Regards, >> >> Luke >> >> >> [1] http://goo.gl/swTpr >> >> [2] http://goo.gl/7p1JN >> > > I disagree. There are small problems with the User model that have not > been fixed. Every proposal you've listed does not address these > issues, but instead looks to find ways of replacing the base user > object, which is a complex and difficult project. > > There is a reason why these are the proposals. Every time someone > proposes fixing these minor bugs, the cry from on high is that > instead, d.c.auth will be overhauled to allow for more customization > by the project, immediately increasing the scope and complexity. But > this fabled d.c.auth2 never appears. > > In fact, your reply alludes to this. We're talking about why a field > is too short to contain valid values, and you suggest that the > solution inevitably will involve "lazy foreign keys/virtual > models/database migrations" - it's changing one line, and adding a > comment to relnotes! > > We may have to agree to disagree on how easy some of these things are to fix. > > Lets look at one isolated aspect. The User email field in d.c.auth
Re: authentication by email
Yes it clearly would, however I see two possible solutions to make it more friendly: 1. We provide MySQL, Sqlite3, PostgreSQL instructions on how to do it - I mean the actual commands to execute. 2. Catch the DB error and throw a form validation warning for those that didn't. -Original Message- From: Luke Sneeringer Sent: Thursday, March 15, 2012 12:28 PM To: django-developers@googlegroups.com Subject: Re: authentication by email On March 15, 2012, at 11:24 , Daniel Sokolowski wrote: Tom makes a good point, but you can already store emails in the username, they are just limited to 30 characters or fewer. Lift this length restriction and I will be able to do everything I need without having to wait for contrib.auth2. In the 'I use django to make a living' world the solution doesn't have to be perfect just good enough. The talk of lazy foreign keys just so we can create contrib.auth2 just rubs me the wrong way, adds additional complexity, and I see no benefit of it over a UserProfile model or with model inheritance. And Django developer ought to be familiar how to do a schema migration for this simple change, and if they fail to know instructions can be provided in the release notes; there is NO need to have progress being stalled because there is no built automated schema migration. Why can we not just increase the length limit on the username field?, Why can't we just throw a validation error if data entered is to long and the schema has not been updated? I think the answer yes we can and easily. Wouldn't increasing the length of the username field *also* incur a schema migration? After all, anyone who has spun up a Django site previous to the change would have a CHARACTER VARYING(30) (or a VARCHAR(30) or whatever the appropriate database-specific type is) in their database. So, we'd have a situation where Django would accept a 40 character email address, but then the database would truncate it or error out. The argument that Django developers ought to know how to do the schema migrations themselves seems poor to me. I expect some don't, and it's certainly a bigger backwards incompatible change than the Django development community has traditionally been comfortable with. Regards, Luke -Original Message- From: Tom Evans Sent: Friday, March 09, 2012 11:46 AM To: django-developers@googlegroups.com Subject: Re: authentication by email On Fri, Mar 9, 2012 at 3:52 PM, Luke Plant wrote: On 09/03/12 14:49, Tom Evans wrote: Yes, since no one needs it. Okay no one isn't true, but no one (for true this time) who needed it stepped up and said "I'll implement it and see that it ends up in trunk" I'm sorry, that completely mis-characterises the situation. Lots of people want this, but every single time this has been brought up since I started using django (1.0), a core dev or BFDL has explicitly ruled it out, saying "we cannot do this, requires schema migration, we'll look at it for the next version". This is not true. There have been times when we have said we cannot consider it right now, and that a solid proposal should be brought up at the calls for proposals for 1.1/1.2/1.3 etc., or at other times when the core developers can look at it. And every time, the proposal has either been missing or simply not been adequate - for example, the GSoC 2010 and 2011 proposals regarding this. Russell gave detailed feedback on why these solutions were not adequate [1], and at other times has provided feedback on possible strategies [2]. And the people who went away to work on the problem have gone silent or admitted defeat. One presumes they fixed their immediate problem in a way that would not be a general solution, and moved on, and that is perfectly understandable. A adequate solution to this is very hard, and probably requires solving several other big problems first (like at least one of lazy foreign keys/virtual models/database migrations). It isn't, however, impossible. Our definition of 'need' is that someone is sufficiently motivated to overcome the obstacles, and contribute a solution that works for other people as well as themselves. Regards, Luke [1] http://goo.gl/swTpr [2] http://goo.gl/7p1JN I disagree. There are small problems with the User model that have not been fixed. Every proposal you've listed does not address these issues, but instead looks to find ways of replacing the base user object, which is a complex and difficult project. There is a reason why these are the proposals. Every time someone proposes fixing these minor bugs, the cry from on high is that instead, d.c.auth will be overhauled to allow for more customization by the project, immediately increasing the scope and complexity. But this fabled d.c.auth2 never appears. In fact, your reply alludes to this. We're talking about why a field is too short to contain valid values, and you suggest that the solution inevitably will involve "lazy foreign keys/virtual mod
Re: authentication by email
That would be a workable compromise, yes? -Original Message- From: Daniel Sokolowski Sent: Thursday, March 15, 2012 12:41 PM To: django-developers@googlegroups.com Subject: Re: authentication by email Yes it clearly would, however I see two possible solutions to make it more friendly: 1. We provide MySQL, Sqlite3, PostgreSQL instructions on how to do it - I mean the actual commands to execute. 2. Catch the DB error and throw a form validation warning for those that didn't. -Original Message- From: Luke Sneeringer Sent: Thursday, March 15, 2012 12:28 PM To: django-developers@googlegroups.com Subject: Re: authentication by email On March 15, 2012, at 11:24 , Daniel Sokolowski wrote: Tom makes a good point, but you can already store emails in the username, they are just limited to 30 characters or fewer. Lift this length restriction and I will be able to do everything I need without having to wait for contrib.auth2. In the 'I use django to make a living' world the solution doesn't have to be perfect just good enough. The talk of lazy foreign keys just so we can create contrib.auth2 just rubs me the wrong way, adds additional complexity, and I see no benefit of it over a UserProfile model or with model inheritance. And Django developer ought to be familiar how to do a schema migration for this simple change, and if they fail to know instructions can be provided in the release notes; there is NO need to have progress being stalled because there is no built automated schema migration. Why can we not just increase the length limit on the username field?, Why can't we just throw a validation error if data entered is to long and the schema has not been updated? I think the answer yes we can and easily. Wouldn't increasing the length of the username field *also* incur a schema migration? After all, anyone who has spun up a Django site previous to the change would have a CHARACTER VARYING(30) (or a VARCHAR(30) or whatever the appropriate database-specific type is) in their database. So, we'd have a situation where Django would accept a 40 character email address, but then the database would truncate it or error out. The argument that Django developers ought to know how to do the schema migrations themselves seems poor to me. I expect some don't, and it's certainly a bigger backwards incompatible change than the Django development community has traditionally been comfortable with. Regards, Luke -Original Message- From: Tom Evans Sent: Friday, March 09, 2012 11:46 AM To: django-developers@googlegroups.com Subject: Re: authentication by email On Fri, Mar 9, 2012 at 3:52 PM, Luke Plant wrote: On 09/03/12 14:49, Tom Evans wrote: Yes, since no one needs it. Okay no one isn't true, but no one (for true this time) who needed it stepped up and said "I'll implement it and see that it ends up in trunk" I'm sorry, that completely mis-characterises the situation. Lots of people want this, but every single time this has been brought up since I started using django (1.0), a core dev or BFDL has explicitly ruled it out, saying "we cannot do this, requires schema migration, we'll look at it for the next version". This is not true. There have been times when we have said we cannot consider it right now, and that a solid proposal should be brought up at the calls for proposals for 1.1/1.2/1.3 etc., or at other times when the core developers can look at it. And every time, the proposal has either been missing or simply not been adequate - for example, the GSoC 2010 and 2011 proposals regarding this. Russell gave detailed feedback on why these solutions were not adequate [1], and at other times has provided feedback on possible strategies [2]. And the people who went away to work on the problem have gone silent or admitted defeat. One presumes they fixed their immediate problem in a way that would not be a general solution, and moved on, and that is perfectly understandable. A adequate solution to this is very hard, and probably requires solving several other big problems first (like at least one of lazy foreign keys/virtual models/database migrations). It isn't, however, impossible. Our definition of 'need' is that someone is sufficiently motivated to overcome the obstacles, and contribute a solution that works for other people as well as themselves. Regards, Luke [1] http://goo.gl/swTpr [2] http://goo.gl/7p1JN I disagree. There are small problems with the User model that have not been fixed. Every proposal you've listed does not address these issues, but instead looks to find ways of replacing the base user object, which is a complex and difficult project. There is a reason why these are the proposals. Every time someone proposes fixing these minor bugs, the cry from on high is that instead, d.c.auth will be overhauled to allow for more customization by the project, immediately increasing the scope and complexity. But this fabled d.c.auth2 never appear
Re: authentication by email
Hi Daniel, On 03/15/2012 09:24 AM, Daniel Sokolowski wrote: > Why can we not just increase the length limit on the username field?, > Why can't we just throw a validation error if data entered is to long > and the schema has not been updated? I think the answer yes we can and > easily. I don't mean to pick on you specifically, but to me this is an excellent example of a casual assertion of something we can "easily" do that doesn't hold up under real examination (for instance, if you tried to write the patch to actually do it). How do you propose to "throw a validation error" if "the schema has not been updated"? How do we know whether it's been updated? Are you proposing that Django should introspect the users database table every time it starts up in order to check the length of the username field? Where would you put this introspection check? Have you considered the effects this would have on every user of contrib.auth (both those who do and don't run the schema migration)? And the effect on Django development (needing to run the tests with both an "old" and "new" table to ensure that the backwards-compatibility handling is tested?) Carl signature.asc Description: OpenPGP digital signature
Re: authentication by email
On 03/15/2012 09:41 AM, Daniel Sokolowski wrote: > Yes it clearly would, however I see two possible solutions to make it > more friendly: > > 1. We provide MySQL, Sqlite3, PostgreSQL instructions on how to do it - > I mean the actual commands to execute. > 2. Catch the DB error and throw a form validation warning for those that > didn't. Catching the database error won't work - some databases won't raise an error, they'll just silently truncate the value, potentially leading to all sorts of nasty data corruption problems and confusing bugs down the road. Carl signature.asc Description: OpenPGP digital signature
Re: [1.4] SECRET_KEY deprecation is confusing...
On 03/15/2012 07:52 AM, Nick Pope wrote: > There is a problem in 1.4rc2 where a missing SECRET_KEY causes Django to > refuse to start. > > According to the current version of the release notes on the > website: *In Django 1.4, starting Django with an empty SECRET_KEY will > raise a DeprecationWarning. In Django 1.5, it will raise an exception > and Django will refuse to start.* > * > * > This doesn't make sense... It currently raises DeprecationWarning which > is an exception which causes Django to fail to start. To trigger a > deprecation warning while allowing execution to continue you need to use > warnings.warn(). > > As things stand you are essentially implementing the behaviour for both > 1.4 *and* 1.5! Indeed; thanks for the report. I've now fixed it to use warnings.warn, as it should have originally. Carl signature.asc Description: OpenPGP digital signature
Re: Revisiting multiline tags
before we lay this discussion to rest, I would like the dissenters to feast your eyes on this great new feature that *you have approved*: http://www.scribd.com/doc/57270484/Djangocon-EU-2011-Revised-Form-Rendering-Lightning-Talk-by-Gregor-Mullegger and don't forget, this *is coming soon* (at least, I hope it is) https://code.djangoproject.com/wiki/SummerOfCode2012 These tags are a great idea. Moving HTML-related code into the template *gasp* and out of the forms, so that designers can do their thing, and it will make it easier to write javascript: adding classes and setting ids, which is inherently *template* (aka DOM) related stuff. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: authentication by email
Carl, I sincerely appreciate your feedback, however again it seems no answers are given except more questions and considerations to consider. Why is it so unreasonable that we expect the end developer to be able to manually adjust their schemas, it's part of an upgrade process and it's been done in the past labelled backwards incompatible changes due to bugs or security, perhaps 30 character limitation ought to be considered a design bug - tomorrow I'll do an R&D day and see the feasibility of a solution. -Original Message- From: Carl Meyer Sent: Thursday, March 15, 2012 12:49 PM To: django-developers@googlegroups.com Subject: Re: authentication by email -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: [GSoC 2012] Improved error reporting
В сообщении от Thursday 15 of March 2012 11:07:03 Russell написал: > Essentially, we're going to be looking for evidence that you understand the > scope of the problem you're proposing to solve. Generic statements like > "I'm going to fix the errors in X" aren't especially convincing by > themselves. > > To put it another way: Our selection process is essentially guided by > looking at the proposals, and determining what we (as a project) are going > to get out of the project at the end of the GSoC. A generic plan that says > "I'm going to spend 12 weeks fixing error messages in Django" doesn't > really let us know what the end product will be. Will you fix 1 error? 10? > 100? Will they all be in contrib? django.core? > > We also need to be convinced that you appear to understand the complexity > (or lack of complexity) of the problem you're proposing to fix, and that > you have a plan that will enable you to deliver on what you're promising. > A plan that just says "I'm going to fix these 10 problems" without > providing any details isn't very helpful either. Yes, it would be good to > have 10 less problems -- but how do we know that the 10 problems can > actually be fixed in 12 weeks? Or, at the other end of the scale -- how do > we know that you're not going to be finished in a week? > > What we really need is a list of the areas you're going to look at, and > some sort of analysis of the source of the problems in those areas -- > e.g., is it just a matter of the error messages being unhelpful, or is > there something fundamental that needs to be fixed (e.g., internally > generated exceptions being re-raised in unhelpful ways, or exceptions > being raised by a side effect, rather than the real problem). > > You don't have to go to the level of enumerating every single error message > you will fix (although that would certainly be nice!), but we will be > looking for a rigorous analysis. This will require some research and > elaboration on your part. > > A good rule of thumb: Can you produce a convincing timeline for a 12 week > project? If your project plan is filled with "3 weeks: Fix errors in > admin", then you haven't provided us with any evidence that you understand > the scope of the problem. If you can get to 1 week granularity, you're > starting to be convincing. Granularity at the level of days would be > excellent. Thanks, got it. What's the deadline for that plan submission? Do I have to send it before the applications acceptance date, in my application or during the Interim Period (April 6-20)? Will it be a one-time submission or some (little) discussion will be held about it with possibility to fix and change some parts of that plan? -- WBR, Boris. signature.asc Description: This is a digitally signed message part.
Re: authentication by email
On March 15, 2012, at 12:23 , Daniel Sokolowski wrote: > Carl, I sincerely appreciate your feedback, however again it seems no answers > are given except more questions and considerations to consider. Why is it so > unreasonable that we expect the end developer to be able to manually adjust > their schemas, it's part of an upgrade process and it's been done in the past > labelled backwards incompatible changes due to bugs or security, perhaps 30 > character limitation ought to be considered a design bug - tomorrow I'll do > an R&D day and see the feasibility of a solution. > I don't think Carl's point was to provide answers; his point was to explain why the proposal isn't a very good one. He doesn't have to propose an alternative to establish that a proposal doesn't work. Most of Django's backwards incompatible changes are corner cases that most end developers never actually encounter. The only exception I can think of to this is the CSRF changes to AJAX requests in Django 1.3. This change, on the other hand, would affect basically every single Django installation; this is much more widespread than past Django releases. Regards, Luke > -Original Message- From: Carl Meyer > Sent: Thursday, March 15, 2012 12:49 PM > To: django-developers@googlegroups.com > Subject: Re: authentication by email > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: authentication by email
Ok to recap, The issue here is that django auth is limited, and restrictive and needs hacks to make it use emails as usernames, we can agree on that yes? We can also agree that contrib.auth2 with LFK is a complex undertaking far into the future?. Can we also agree that the 30 character limitation on the username ought to be increased? -Original Message- From: Luke Sneeringer Sent: Thursday, March 15, 2012 2:11 PM To: django-developers@googlegroups.com Subject: Re: authentication by email On March 15, 2012, at 12:23 , Daniel Sokolowski wrote: Carl, I sincerely appreciate your feedback, however again it seems no answers are given except more questions and considerations to consider. Why is it so unreasonable that we expect the end developer to be able to manually adjust their schemas, it's part of an upgrade process and it's been done in the past labelled backwards incompatible changes due to bugs or security, perhaps 30 character limitation ought to be considered a design bug - tomorrow I'll do an R&D day and see the feasibility of a solution. I don't think Carl's point was to provide answers; his point was to explain why the proposal isn't a very good one. He doesn't have to propose an alternative to establish that a proposal doesn't work. Most of Django's backwards incompatible changes are corner cases that most end developers never actually encounter. The only exception I can think of to this is the CSRF changes to AJAX requests in Django 1.3. This change, on the other hand, would affect basically every single Django installation; this is much more widespread than past Django releases. Regards, Luke -Original Message- From: Carl Meyer Sent: Thursday, March 15, 2012 12:49 PM To: django-developers@googlegroups.com Subject: Re: authentication by email -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: authentication by email
On Thu, Mar 15, 2012 at 5:53 AM, Danny Adair wrote: Hi Danny, > I'm sorry I don't know if I like that. I hope I understand correctly > what you're doing, and that my criticism is seen as constructive. > Thanks for reviewing the code and providing feedback. > This sells itself as "pluggable auth" but really only provides the > originally requested auth by email, and I don't see how it could go > from there, i.e. what else would be possible (in regards to auth). > Pulling username and email out of (Base)User and then bringing one or > both of them - and the logic of which to check - back in, is not > really a pluggable auth. > It's "pluggable" in the sense that you could write a User model with whatever fields, methods, and attributes best suits your application. You aren't required to extend BaseUser—I only added that abstract class because I figure that most deviations from the stock User won't be that drastic, and it's convenient to be able to inherit from a model that has most of what you need already. It's the mixing of profile and information relevant to authentication > (and authorization - is_staff?) that's another problem of the existing > User model, and this is where this approach allows for dangerous > developments. > My dissatisfaction with the stock User model has less to do with the the fact that it combines authentication credentials and profile information in a single model, and more to do with the fact that it's hard to work around the stock User model if it doesn't meet your needs. The stock User model is the simplest thing that could possibly work—and indeed it does work, for most projects—but it's also one of the few components of Django that isn't configurable or replaceable. I can provide a custom ModelBackend easily enough, and a custom AuthenticationForm, but I'm always stuck with the auth.User model. We could debate for a long time (in fact, we have—the ticket was opened five years ago) what constitutes a proper User model, but may never reach a conclusion. Some will want to separate authentication from identity from profile, others will want to keep it simple. It's not clear to me that there's a "correct" User model, just as there's not a "correct" blogging application. So, rather than offer specific improvements to the stock User model, I aim to provide a means for developers to use their own User model, should they need to do that. > What about first_name and last_name? Why can't a pluggable auth dump > those from the User model? And certainly an "auth" should get to have > a say about "password". > Certainly, you could write a pluggable User model without first_name and last_name fields. Some have requested a User model with a simple "name" field. You could do that. It may not work in the admin, unless you define a first_name property, but your User model should work with a great many applications. The same is true for the password field: write a User model without it, if you'd like. That should work almost everywhere, even in the admin, so long as you provide your own UserCreationForm and UserChangeForm, and your own backend that handles authentication another way. And then... there's not much left anymore in that (Base)User model, > right... (GSoC: "reducing the user table to little more than an > identifying primary key") > Just to be clear, the BaseUser that I've proposed is there for convenience. It is not required. We could pare down BaseUser even more, but I suppose there will always be some disagreement about what should be the minimum set of fields and methods on a User model. I avoid that debate by saying that BaseUser isn't required—inherit from it, or don't, it's your choice. Some developers may want a User object that is just a primary key. They may have factored authentication and identity out in a way that is much more flexible (and much more complex) than the stock User model. That should be possible—and with pluggable auth apps, it is. Ok email auth problem solved. But now there's a simple way of > providing any User model I like, so first thing I'm going to do is to > bring in what I think the User should look like i.e. use the "auth" to > define what really is a "profile". And so will lots of projects. "The > User model needs a username for this app to work". "The User model > needs a timezone for this app to work". etc. > I'd like to see a later, "proper" auth.user that can undo that chaos. I don't know that I would call that "chaos". For many applications, it makes sense to have a simple User model with some profile data. I might not want to incur the extra JOIN or SELECT required to fetch a separate UserProfile object. Maybe it makes sense to store some profile attributes (display name, for instance) with the authentication credentials. Maybe it doesn't make sense to store email address there—what if I have several email addresses?—or timezone—what if I travel? There isn't a one-size-fits-all solution, but I think we can at least gi
Re: authentication by email
On Thu, Mar 15, 2012 at 2:48 PM, Daniel Sokolowski < daniel.sokolow...@klinsight.com> wrote: > The issue here is that django auth is limited, and restrictive and needs > hacks to make it use emails as usernames, we can agree on that yes? I agree with this point. > We can also agree that contrib.auth2 with LFK is a complex undertaking far > into the future? I agree that LFK isn't a simple undertaking, and doesn't solve all the auth.User problems, anyway. > Can we also agree that the 30 character limitation on the username ought > to be increased? I don't agree that changing the length of the username field is the general solution to the problem of email authentication. First, there's the issue of backwards compatibility: as Carl pointed out, you can't just change the size of the field without requiring a schema migration in every existing django installation, and that's very painful. Second, there's the issue that if you're storing emails in your username field, you've got a redundant email field floating around. With pluggable auth apps, you could make a User model with a longer username field, if you decide that's the best solution for your app, and if you're comfortable with the schema migration. I might elect to use a different User model that foregoes the username field altogether. With pluggable auth apps, the choice is mine—and yours. :) Cheers, Clay -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Model.save and Model.full_clean
I'm working up a documentation patch to make this spelled out more explicitly
but I wonder if there isn't more that should be done.
Currently ``Model.full_clean`` is not called automatically when saving a model.
This is not a big deal when manually constructing your models as you can
just do:
m = MyModel(field=foo)
m.full_clean()
m.save()
However there is no easy way to get a similar behavior when using
``MyModel.objects.create``
or ``MyModel.objects.get_or_create``.
The documentation currently mentions that get_or_create is useful in data
import scripts, but
also mentions using it in views. My patches will try to make it more explicit
that it's unsafe
to assume that the constraints in the field (e.g. URLField) will be enforced
but I wonder if
maybe it would make sense to either make running ``full_clean`` the default or
provide a way
for people to specify that it should be ran. It appears that it's not run by
default due to
backwards compatibility: https://code.djangoproject.com/changeset/12103 .
Currently I would assume that both because of the lack of warning in the
documentation, and
because it isn't obvious behavior (e.g. an URLField that accepts unsafe input,
such as
``javascript:alert("xss");``), that more than one Django powered site is
vulnerable to attacks
such as an XSS where they are using ``create`` or ``get_or_create`` manually
without passing
through a form.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: authentication by email
Hi Daniel, On 03/15/2012 11:48 AM, Daniel Sokolowski wrote: > The issue here is that django auth is limited, and restrictive and needs > hacks to make it use emails as usernames, we can agree on that yes? Certainly. > We > can also agree that contrib.auth2 with LFK is a complex undertaking far > into the future?. It is not a simple undertaking. How far into the future it is depends entirely on whether someone who wants to see it happen takes it upon themselves to make it happen. > Can we also agree that the 30 character limitation on > the username ought to be increased? I am not sure whether this should happen as a separate step or not. In an ideal world, we would have a longer username field. In the real world, we have to balance the benefit against the cost, and requiring a schema migration from practically every Django installation on the planet would IMO be the most significant backwards-incompatible change Django has ever shipped, at least since Django 1.0. It is not at all clear to me that the status quo, bad as it is, is worse than this cure. The cost would be mitigated somewhat if we had schema migrations in core, which would make the upgrade instructions much simpler and more foolproof. The cost would be reduced even more if we simply shipped this as part of a larger customizable-auth change (which will probably require at least a deprecation path itself). So, in my opinion, your energies would be more productively directed towards helping make one of those latter two things happen. But feel free to work on a proposal to simply change the field length. If you can provide a patch with a really compelling backwards-compatibility story, my mind is certainly open to change. Carl signature.asc Description: OpenPGP digital signature
Re: [GSoC 2012] Improved error reporting
On 16/03/2012, at 2:07 AM, Boris Bobrov wrote: > В сообщении от Thursday 15 of March 2012 11:07:03 Russell написал: > >> Essentially, we're going to be looking for evidence that you understand the >> scope of the problem you're proposing to solve. Generic statements like >> "I'm going to fix the errors in X" aren't especially convincing by >> themselves. >> >> To put it another way: Our selection process is essentially guided by >> looking at the proposals, and determining what we (as a project) are going >> to get out of the project at the end of the GSoC. A generic plan that says >> "I'm going to spend 12 weeks fixing error messages in Django" doesn't >> really let us know what the end product will be. Will you fix 1 error? 10? >> 100? Will they all be in contrib? django.core? >> >> We also need to be convinced that you appear to understand the complexity >> (or lack of complexity) of the problem you're proposing to fix, and that >> you have a plan that will enable you to deliver on what you're promising. >> A plan that just says "I'm going to fix these 10 problems" without >> providing any details isn't very helpful either. Yes, it would be good to >> have 10 less problems -- but how do we know that the 10 problems can >> actually be fixed in 12 weeks? Or, at the other end of the scale -- how do >> we know that you're not going to be finished in a week? >> >> What we really need is a list of the areas you're going to look at, and >> some sort of analysis of the source of the problems in those areas -- >> e.g., is it just a matter of the error messages being unhelpful, or is >> there something fundamental that needs to be fixed (e.g., internally >> generated exceptions being re-raised in unhelpful ways, or exceptions >> being raised by a side effect, rather than the real problem). >> >> You don't have to go to the level of enumerating every single error message >> you will fix (although that would certainly be nice!), but we will be >> looking for a rigorous analysis. This will require some research and >> elaboration on your part. >> >> A good rule of thumb: Can you produce a convincing timeline for a 12 week >> project? If your project plan is filled with "3 weeks: Fix errors in >> admin", then you haven't provided us with any evidence that you understand >> the scope of the problem. If you can get to 1 week granularity, you're >> starting to be convincing. Granularity at the level of days would be >> excellent. > > Thanks, got it. > What's the deadline for that plan submission? Do I have to send it before the > applications acceptance date, in my application or during the Interim Period > (April 6-20)? The only deadline is the end-of-submissions deadline, on Friday 6 April. (The April 6-20 period is where we rank and select proposals) The formal submission period starts on 26 March, but we don't enforce that at a project level -- if you want to get started early, please do. > Will it be a one-time submission or some (little) discussion will be held > about it with possibility to fix and change some parts of that plan? We encourage students to send their draft proposals to django-developers so we can give them feedback. This gives us an opportunity to evaluate how you work with the community, and gives you the opportunity to revise and improve your proposals. Obviously, this isn't a completely limitless resource -- you can't send dozens of drafts and expect to get feedback every time -- but it would be unusual for a project to *not* go through at least 2 or 3 revisions. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
