Re: status of 1.8 release blockers

[Raúl Cumplido]

\o/

On Wed, Feb 25, 2015 at 1:08 AM, Tim Graham  wrote:

> Zero blockers as of this writing. If we survive the next 12 hours with no
> new ones, I'll release the beta around then (famous last words).
>
>
> On Monday, February 23, 2015 at 7:29:09 PM UTC-5, Tim Graham wrote:
>>
>> Previous two issues have been fixed, and now we have two new issues:
>>
>> #24391  UUIDField with
>> default=uuid4 triggers validation on otherwise empty inline formsets
>> 
>>
>> #24395  Cannot reference FK
>> relation from inline ModelForm.save()
>> 
>>
>> There is a chance to resolve them both tomorrow and then release the beta.
>>
>> On Saturday, February 21, 2015 at 3:53:51 PM UTC-5, Tim Graham wrote:
>>>
>>> Patches for the two remaining blockers are awaiting review.
>>>
>>> #24381  Cache pickling
>>> exception in 1.8a1 with cross-table filter params
>>> 
>>> #24377  UUIDField as
>>> primary key breaks inline admins
>>> 
>>>
>>> On Friday, February 20, 2015 at 4:48:01 PM UTC-5, Tim Graham wrote:

 The three issues from last time are resolved, but there is a new issue
 I've been working on today. I have a tentative fix, but there is a failing
 test. Assuming nothing else comes up, I might consider releasing the beta
 tomorrow even if I can't solve that by then as it's not really a new issue,
 just magnified by the fact that UUIDField is in core and that it's
 implementation as a primary_key requires default=uuid.uuid4 unlike some
 existing third-party implementations.

 #24377  UUIDField as
 primary key breaks inline admins
 

 On Thursday, February 19, 2015 at 2:45:07 AM UTC-5, Loïc Bistuer wrote:
>
> From my point of view #24351 is ready for a final sanity check and
> merging.
>
> --
> Loïc
>
> > On Feb 19, 2015, at 10:10, Tim Graham  wrote:
> >
> > 3 issues remain. I haven't confirmed with the owners, but it seems
> to me there may be a good chance to wrap them up tomorrow.
> >
> >
> > #24351  RunPython/RunSQL operations in contrib migrations
> and multi-db routers.
> > Owner: Loic
> > Status: In review.
> >
> >
> > #24328 The new Options._get_fields() method needs to be cleaned up
> > Owner: Anssi
> > Status: In review.
> >
> > #24343 UUID foreign key accessor returns inconsistent type
> >
> > Owner: Marc
> > Status: Marc to polish patch.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send an email to django-develop...@googlegroups.com.
> > To post to this group, send email to django-d...@googlegroups.com.
> > Visit this group at http://groups.google.com/group/django-developers.
>
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/
> 170625d3-1bb5-4b9d-ab74-501fd5dea86b%40googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7d933ca2-ed55-408b-bdce-551060e24d54%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAD1RbrrfpFq9h7rDAcA7-PvK50OMCpPFhrvKg5d4yR0znmgQ2Q%40mail.gmail.com.
For more options, visit https:

Re: django admin: open popups as modals instead of windows

[Russell Keith-Magee]

On Wed, Feb 25, 2015 at 10:39 AM, Loïc Bistuer 
wrote:

> >
> > On Feb 25, 2015, at 09:07, Russell Keith-Magee 
> wrote:
> >
> > I have an operating system with a graphical user interface. The
> developers of that operating system spent an immense amount of time
> developing it, polishing it, making it behave in predictable ways, getting
> keyboard accessibility sorted out, and so on. The idea of a CSS+HTML+JS
> implementation of UI features that badly implement half of the behavior
> provided natively by the OS - and the idea that this implementation is
> somehow *preferable* to native UI elements - absolutely *boggles* my mind.
>
> While I agree on desktop OS, I find responsive HTML modals much more
> usable on mobile.
>
>
Weird - I've found the exact opposite, especially if you're talking about a
site that doesn't have a mobile-optimised website. I've given up counting
the number of websites that have popups that are larger than the screen
size of the mobile device... and then helpfully keep the modal window
centred on the screen so that the dismiss button is off the screen.

That said, HTML modals vs popups is hardly the biggest issue we have when
> it comes to usability on mobile platforms, which isn't surprising
> considering the admin look & feel was invented way before mobile was a
> thing.
>

Very much agreed on this point.

Russ %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq848YtSe9QC2JnPD8OVYncfmQ38N7SSHX2sfcnDRtfLuhug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for DATABASES['default'] = {}

[Thomas Recouvreux]

Hello,

I have a case where the 'default' database does not have any sense, but I 
still want the tests to create and manage transactions on other defined 
databases, so the option `--database` would not help me. I could put 
something in the default database like in memory sqlite for the tests but 
it does not feel good to me since this could lead to successful tests but 
failures on production environment.

Would it be possible to remove the requirement of the 'default' alias ? It 
seems a bit odd to me that DATABASES = {} and DATABASES = { 'default': {}, 
'mysite': { .. } } are valid settings but DATABASES = { 'mysite': { .. } } 
is not.

Whatever is the final decision, do not forget to update the doc if 
necessary, since the current doc 
(https://docs.djangoproject.com/en/1.7/topics/db/multi-db/#defining-your-databases)
 
states DATABASES = { 'default': {} } is a valid setting.






On Tuesday, February 24, 2015 at 4:42:52 PM UTC+1, Markus Holtermann wrote:
>
> The question I'm asking myself right now: what is a "default" database in 
> a multi database setup where "default" does not make sense at all? I can 
> easily think of a case where I have multiple other databases used by other 
> services where Django provides a dashboard. I don't see any of those 
> databases being a "default".
>
> That said, having an implicit default database that defaults to a dummy 
> backend doesn't seem too bad. I'd rather see the docs updated in that 
> regards and fix code that relies on "default" although giving an explicit 
> database alias isn't complicated. "manage.py test" could get a --database 
> option (if it doesn't have it already).
>
> /Markus
>
> On Tuesday, February 24, 2015 at 3:11:08 PM UTC+1, Marc Tamlyn wrote:
>>
>> I can't see why it is sensible to support an invalid database 
>> configuration as the default. If you explicitly want the default to be a 
>> dummy, you should configure that IMO.
>>
>> On 24 February 2015 at 14:04, Marten Kenbeek  wrote:
>>
>>> Which one? :P This was more intended as a question than as a proposal.
>>>
>>> I personally prefer a documentation change and strict checking of 
>>> `default` if and only if the database configuration is not empty. 
>>> django.db.connection relies on the default connection, and third-party apps 
>>> which (intentionally or unintentionally) do not support multi-db setups 
>>> might be using that. I can't think of a scenario where it hurts to have a 
>>> default database. I'm easily swayed on this matter, though. 
>>>
>>> On Tuesday, February 24, 2015 at 2:52:47 PM UTC+1, Marc Tamlyn wrote:

 In that case your proposal sounds perfectly reasonable.

 On 24 February 2015 at 13:47, Marten Kenbeek  
 wrote:

> In fact, DATABASES={} is a valid configuration and merely sets 
> 'default' as a dummy backend. An exception is only explicitly raised if 
> you 
> supply a non-empty setting that does not include `default`. 
>
> On Tuesday, February 24, 2015 at 2:43:51 PM UTC+1, Marc Tamlyn wrote:
>>
>> It would seem more sensible to me to try to support DATABASES={}. 
>> There's no reason why a Django site should have to run a database - a 
>> microservice using redis or something similar is perfectly reasonable 
>> and 
>> you could want to use Django for other reasons (e.g. shared templates).
>>
>> Marc
>>
>> On 24 February 2015 at 13:38, Marten Kenbeek  
>> wrote:
>>
>>> With recent bug reports (#24332 
>>> , #24298 
>>>  and now #24394 
>>> ) all caused by 
>>> setting `DATABASES['default'] = {}`, this makes me wonder if it should 
>>> be 
>>> supported at all.
>>> The documentation states:
>>>
>>> The DATABASES 
 
  setting 
 must configure a default database; any number of additional 
 databases may also be specified.[1] 
>>>
>>>
>>> And indeed, if default is not set at all, an error is raised. If 
>>> default does not provide valid database settings, it is set to use 
>>> `django.db.backends.dummy`. This will raise a `NotImplementedError` as 
>>> soon 
>>> as it is used, but it seems you can work around this quite well and 
>>> ensure 
>>> that `default` is barely used. The exceptions to this are reported in 
>>> the 
>>> mentioned bug reports, most notably `manage.py test` uses the `default` 
>>> database. 
>>>
>>> Should the documentation be clarified that it not only requires 
>>> `default` to be set, but that it requires a valid database 
>>> configuration as 
>>> well? Or should an empty `default` configuration be valid?
>>>
>>> In #24332 and #24398, both fixed now, there was the additional issue 
>>

Re: Support for DATABASES['default'] = {}

[Marten Kenbeek]

If the docs state that it is a valid setting, then we shouldn't change that 
to maintain compatibility and your ticket is indeed a bug. In that case, it 
makes sense to me not to require the `default` database setting in the 
first place. The error caused in #24394 is a result of looping over all 
available connections, removing this requirement should fix the bug as 
well. 

Looking at just the traceback for this bug, it seems that, without a 
`default` configuration, a `--database` option in the test command is not 
necessary with proper routing in the application, and it wouldn't even make 
sense in a multi-db testing environment. 

On Wednesday, February 25, 2015 at 1:34:34 PM UTC+1, Thomas Recouvreux 
wrote:
>
> Hello,
>
> I have a case where the 'default' database does not have any sense, but I 
> still want the tests to create and manage transactions on other defined 
> databases, so the option `--database` would not help me. I could put 
> something in the default database like in memory sqlite for the tests but 
> it does not feel good to me since this could lead to successful tests but 
> failures on production environment.
>
> Would it be possible to remove the requirement of the 'default' alias ? It 
> seems a bit odd to me that DATABASES = {} and DATABASES = { 'default': {}, 
> 'mysite': { .. } } are valid settings but DATABASES = { 'mysite': { .. } } 
> is not.
>
> Whatever is the final decision, do not forget to update the doc if 
> necessary, since the current doc (
> https://docs.djangoproject.com/en/1.7/topics/db/multi-db/#defining-your-databases)
>  
> states DATABASES = { 'default': {} } is a valid setting.
>
>
>
>
>
>
> On Tuesday, February 24, 2015 at 4:42:52 PM UTC+1, Markus Holtermann wrote:
>>
>> The question I'm asking myself right now: what is a "default" database in 
>> a multi database setup where "default" does not make sense at all? I can 
>> easily think of a case where I have multiple other databases used by other 
>> services where Django provides a dashboard. I don't see any of those 
>> databases being a "default".
>>
>> That said, having an implicit default database that defaults to a dummy 
>> backend doesn't seem too bad. I'd rather see the docs updated in that 
>> regards and fix code that relies on "default" although giving an explicit 
>> database alias isn't complicated. "manage.py test" could get a --database 
>> option (if it doesn't have it already).
>>
>> /Markus
>>
>> On Tuesday, February 24, 2015 at 3:11:08 PM UTC+1, Marc Tamlyn wrote:
>>>
>>> I can't see why it is sensible to support an invalid database 
>>> configuration as the default. If you explicitly want the default to be a 
>>> dummy, you should configure that IMO.
>>>
>>> On 24 February 2015 at 14:04, Marten Kenbeek  wrote:
>>>
 Which one? :P This was more intended as a question than as a proposal.

 I personally prefer a documentation change and strict checking of 
 `default` if and only if the database configuration is not empty. 
 django.db.connection relies on the default connection, and third-party 
 apps 
 which (intentionally or unintentionally) do not support multi-db setups 
 might be using that. I can't think of a scenario where it hurts to have a 
 default database. I'm easily swayed on this matter, though. 

 On Tuesday, February 24, 2015 at 2:52:47 PM UTC+1, Marc Tamlyn wrote:
>
> In that case your proposal sounds perfectly reasonable.
>
> On 24 February 2015 at 13:47, Marten Kenbeek  
> wrote:
>
>> In fact, DATABASES={} is a valid configuration and merely sets 
>> 'default' as a dummy backend. An exception is only explicitly raised if 
>> you 
>> supply a non-empty setting that does not include `default`. 
>>
>> On Tuesday, February 24, 2015 at 2:43:51 PM UTC+1, Marc Tamlyn wrote:
>>>
>>> It would seem more sensible to me to try to support DATABASES={}. 
>>> There's no reason why a Django site should have to run a database - a 
>>> microservice using redis or something similar is perfectly reasonable 
>>> and 
>>> you could want to use Django for other reasons (e.g. shared templates).
>>>
>>> Marc
>>>
>>> On 24 February 2015 at 13:38, Marten Kenbeek  
>>> wrote:
>>>
 With recent bug reports (#24332 
 , #24298 
  and now #24394 
 ) all caused by 
 setting `DATABASES['default'] = {}`, this makes me wonder if it should 
 be 
 supported at all.
 The documentation states:

 The DATABASES 
> 
>  setting 
> must configure a default database; any number of additional 
> databases may also be specified.[1] 


 And ind

[ANNOUNCE] Django 1.8 beta 1 and 1.7.5 released

[Tim Graham]

In addition to a bug fix release for the 1.7 series, the Django team has 
made the second release on the way to Django 1.8. Check out the blog post:

https://www.djangoproject.com/weblog/2015/feb/25/releases/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8bd0b8c8-20ba-4d5e-9e1d-74b12846751e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: User.username max_length 254

[Daniel Hawkins]

>
> Beta 1 marks the end of any changes that aren't considered release 
> blocking bugs. A bug is a "Release blocker" if it's a regression from a 
> previous version of Django or if it's an important bug in a new feature.


... so I guess the ship has sailed on this idea?  :(

On Wednesday, February 11, 2015 at 3:27:35 AM UTC-5, Daniel Hawkins wrote:
>
> Yes please!  Since contrib.auth.models.User.email is an EmailField, that 
> change will require everyone to run a migration, right?  Then we might as 
> well change the character limit on the username field at the same time, 
> no?  And any other defaults that might be less-than-reasonable?
>
> I was going to update the longerusername package by adding a Django 1.7 
> migration, but it seems I can't alter fields on the User model from 
> within another app's migrations in Django 1.7.  This was possible with 
> South, but it appears to be impossible with Django migrations (except 
> perhaps with raw SQL, which seems like a bad idea).  So now I *have to* 
> create a custom user model just so I can migrate to Django 1.7 (which I *have 
> to* do in order to continue getting security releases after 1.8 is 
> released).
>
> According to the docs, setting a custom user model after you've already 
> run initial migrations is not supported (
> https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#substituting-a-custom-user-model).
>  
>  So, for anyone without a custom user model, who is already running on 
> Django 1.7 in production, who would like to have usernames longer than 30 
> characters, there is no way to make that happen.
>
>
> On Friday, February 6, 2015 at 8:10:02 PM UTC-5, Collin Anderson wrote:
>>
>> Hi All,
>>
>> I was reminded by:
>> Allow shadowing of abstract fields 
>> https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ
>> and https://code.djangoproject.com/ticket/24288 (Custom User Models for 
>> small tweaks).
>>
>> Could we reopen https://code.djangoproject.com/ticket/20846 
>> 
>>  
>> and increase User.username max_length to 254?
>>
>> Personally, that's the only thing I've ever needed to change about my 
>> User class. I just need it long enough to hold email addresses. I've seen 
>> many other people wanting the same thing.
>>
>> In 1.8 we migrated the length of EmailField from 75 to 254, so it should 
>> be almost™ as easy to change the username field.
>>
>> If needed, we could keep the 30-character limit on UserCreationForm and 
>> UserChangeForm for backwards compatibility. The limit in the database is 
>> the real killer :) Though, consistency is also nice.
>>
>> Thanks,
>> Collin
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/037b52c1-e583-4d04-aeca-e7d907f2fccf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: User.username max_length 254

[Collin Anderson]

Hi,

I'm actually about to run into a similar situation myself where I already 
have migrations for my project but need to start using a custom user model 
(because I need a longer username :).

There's talk of possibly including a custom user in the project template 
https://code.djangoproject.com/ticket/24370. However, I think we need to at 
least document how to hack your project so you can switch to a custom user 
after using migrations.

Collin

On Wednesday, February 25, 2015 at 11:19:46 AM UTC-5, Daniel Hawkins wrote:
>
> Beta 1 marks the end of any changes that aren't considered release 
>> blocking bugs. A bug is a "Release blocker" if it's a regression from a 
>> previous version of Django or if it's an important bug in a new feature.
>
>
> ... so I guess the ship has sailed on this idea?  :(
>
> On Wednesday, February 11, 2015 at 3:27:35 AM UTC-5, Daniel Hawkins wrote:
>>
>> Yes please!  Since contrib.auth.models.User.email is an EmailField, that 
>> change will require everyone to run a migration, right?  Then we might as 
>> well change the character limit on the username field at the same time, 
>> no?  And any other defaults that might be less-than-reasonable?
>>
>> I was going to update the longerusername package by adding a Django 1.7 
>> migration, but it seems I can't alter fields on the User model from 
>> within another app's migrations in Django 1.7.  This was possible with 
>> South, but it appears to be impossible with Django migrations (except 
>> perhaps with raw SQL, which seems like a bad idea).  So now I *have to* 
>> create a custom user model just so I can migrate to Django 1.7 (which I 
>> *have 
>> to* do in order to continue getting security releases after 1.8 is 
>> released).
>>
>> According to the docs, setting a custom user model after you've already 
>> run initial migrations is not supported (
>> https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#substituting-a-custom-user-model).
>>  
>>  So, for anyone without a custom user model, who is already running on 
>> Django 1.7 in production, who would like to have usernames longer than 30 
>> characters, there is no way to make that happen.
>>
>>
>> On Friday, February 6, 2015 at 8:10:02 PM UTC-5, Collin Anderson wrote:
>>>
>>> Hi All,
>>>
>>> I was reminded by:
>>> Allow shadowing of abstract fields 
>>> https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ
>>> and https://code.djangoproject.com/ticket/24288 (Custom User Models for 
>>> small tweaks).
>>>
>>> Could we reopen https://code.djangoproject.com/ticket/20846 
>>> 
>>>  
>>> and increase User.username max_length to 254?
>>>
>>> Personally, that's the only thing I've ever needed to change about my 
>>> User class. I just need it long enough to hold email addresses. I've seen 
>>> many other people wanting the same thing.
>>>
>>> In 1.8 we migrated the length of EmailField from 75 to 254, so it should 
>>> be almost™ as easy to change the username field.
>>>
>>> If needed, we could keep the 30-character limit on UserCreationForm and 
>>> UserChangeForm for backwards compatibility. The limit in the database is 
>>> the real killer :) Though, consistency is also nice.
>>>
>>> Thanks,
>>> Collin
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9663cfe8-933f-4720-b24d-0cd6aec7fb3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: User.username max_length 254

[Tim Graham]

Well, this change wouldn't have been made after alpha (feature-freeze) 
either. As there haven't been any outright rejections of the idea, I think 
the next step is for someone to write a patch and carefully consider and 
document and backwards compatibility concerns.

On Wednesday, February 25, 2015 at 11:19:46 AM UTC-5, Daniel Hawkins wrote:
>
> Beta 1 marks the end of any changes that aren't considered release 
>> blocking bugs. A bug is a "Release blocker" if it's a regression from a 
>> previous version of Django or if it's an important bug in a new feature.
>
>
> ... so I guess the ship has sailed on this idea?  :(
>
> On Wednesday, February 11, 2015 at 3:27:35 AM UTC-5, Daniel Hawkins wrote:
>>
>> Yes please!  Since contrib.auth.models.User.email is an EmailField, that 
>> change will require everyone to run a migration, right?  Then we might as 
>> well change the character limit on the username field at the same time, 
>> no?  And any other defaults that might be less-than-reasonable?
>>
>> I was going to update the longerusername package by adding a Django 1.7 
>> migration, but it seems I can't alter fields on the User model from 
>> within another app's migrations in Django 1.7.  This was possible with 
>> South, but it appears to be impossible with Django migrations (except 
>> perhaps with raw SQL, which seems like a bad idea).  So now I *have to* 
>> create a custom user model just so I can migrate to Django 1.7 (which I 
>> *have 
>> to* do in order to continue getting security releases after 1.8 is 
>> released).
>>
>> According to the docs, setting a custom user model after you've already 
>> run initial migrations is not supported (
>> https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#substituting-a-custom-user-model).
>>  
>>  So, for anyone without a custom user model, who is already running on 
>> Django 1.7 in production, who would like to have usernames longer than 30 
>> characters, there is no way to make that happen.
>>
>>
>> On Friday, February 6, 2015 at 8:10:02 PM UTC-5, Collin Anderson wrote:
>>>
>>> Hi All,
>>>
>>> I was reminded by:
>>> Allow shadowing of abstract fields 
>>> https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ
>>> and https://code.djangoproject.com/ticket/24288 (Custom User Models for 
>>> small tweaks).
>>>
>>> Could we reopen https://code.djangoproject.com/ticket/20846 
>>> 
>>>  
>>> and increase User.username max_length to 254?
>>>
>>> Personally, that's the only thing I've ever needed to change about my 
>>> User class. I just need it long enough to hold email addresses. I've seen 
>>> many other people wanting the same thing.
>>>
>>> In 1.8 we migrated the length of EmailField from 75 to 254, so it should 
>>> be almost™ as easy to change the username field.
>>>
>>> If needed, we could keep the 30-character limit on UserCreationForm and 
>>> UserChangeForm for backwards compatibility. The limit in the database is 
>>> the real killer :) Though, consistency is also nice.
>>>
>>> Thanks,
>>> Collin
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bd38d58e-a330-44e3-9516-2964f1f1def4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django admin: open popups as modals instead of windows

[Gordon]

I just wanted to add my 2cents worth as an opinion in favor of modals 
replacing popups for many of the admin links.

I am in no way claiming that a poorly implemented modal window is superior 
to a new window...  and there are certainly cases where a new window is 
preferable to the "perfect" modal.  Taking that into consideration, assume 
for the remainder of my reply that the modal popup is well implemented and 
addresses all raised usability concerns.

In my experience, modals can be very beneficial to users that are not 
technically inclined.  From a UX perspective, this is important to 
consider.  As long as the modal window is implemented using unobtrusive 
javascript, "power users" can be expected to know (or at least be 
taught/shown) that they can click with the middle mouse button to open a 
new tab or right click to select between new tab and new window instead of 
the default modal.  During my encounters with the fabled "technically 
challenged" user, I have observed that they tend to get confused (or at the 
very least have trouble navigating) when several windows are opened.  They 
are not proficient with alt-tab or any other window management techniques 
that you and I are comfortable with.  For this class of user, it makes 
sense to select the most appropriate default action for their click 
whenever possible.

I would counter the argument about native windows being superior with the 
following: the browser isn't aware of how tightly related the linked 
content is to the current page.  As such, it can't decide that the link 
should be opened as a modal inside of the current browsing context instead 
of a new window.  This means that it must fall back to the more generic of 
choices to cover all cases.  However, the content author does know the 
relation between the current page and the linked page.  Because of this 
knowledge, it makes sense that the author can make a better default 
selection than the browser when choosing a context in which to open a 
particular link.

For the sake of demonstration, I've found jQuery mobile to be an excellent 
choice when dealing with non-technical users.  Just to be clear, I am not 
advocating for JQM to be used in the admin with this reply.  With that 
being said, here is a link to examples of modal dialogs that I am fond of: 
http://demos.jquerymobile.com/1.4.5/pages-dialog/


On Wednesday, February 25, 2015 at 5:41:38 AM UTC-5, Russell Keith-Magee 
wrote:
>
>
> On Wed, Feb 25, 2015 at 10:39 AM, Loïc Bistuer  > wrote:
>
>> >
>> > On Feb 25, 2015, at 09:07, Russell Keith-Magee > > wrote:
>> >
>> > I have an operating system with a graphical user interface. The 
>> developers of that operating system spent an immense amount of time 
>> developing it, polishing it, making it behave in predictable ways, getting 
>> keyboard accessibility sorted out, and so on. The idea of a CSS+HTML+JS 
>> implementation of UI features that badly implement half of the behavior 
>> provided natively by the OS - and the idea that this implementation is 
>> somehow *preferable* to native UI elements - absolutely *boggles* my mind.
>>
>> While I agree on desktop OS, I find responsive HTML modals much more 
>> usable on mobile.
>>
>>  
> Weird - I've found the exact opposite, especially if you're talking about 
> a site that doesn't have a mobile-optimised website. I've given up counting 
> the number of websites that have popups that are larger than the screen 
> size of the mobile device... and then helpfully keep the modal window 
> centred on the screen so that the dismiss button is off the screen.
>
> That said, HTML modals vs popups is hardly the biggest issue we have when 
>> it comes to usability on mobile platforms, which isn't surprising 
>> considering the admin look & feel was invented way before mobile was a 
>> thing.
>>
>
> Very much agreed on this point.
>
> Russ %-) 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cc40ed4d-fb21-48e5-822f-3ff5c7a4b810%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

enum fields in django

[Thomas Stephenson]

As discussed in Issue 24342 , 
I've got an implementation of EnumField that we've found useful when 
developing our django REST API that I'd like to add to django core. It was 
suggested I bring this issue up in the developers mailing list for 
discussion. Unfortunately, updates to the issue were delivered to my spam 
folder, so there has been some delay in actually raising the issue.

Basically, the implementation consists of a new field type, and a new 
migration operation (to register the values associated with an enum type). 
The field takes an `enum_type` argument and registers a type with values 
taken from the enum value names. The actual values associated with the 
names are ignored, so support for IntEnum and other enum types comes as 
standard.

In a real implementation, the enum type would have to be checked when 
running migrations to ensure that values haven't been added/removed from 
the python class. It's not something that we've needed to deal with in our 
in-house implementation.

Any database which does not support an enum field natively would default to 
a CharField implementation. 

Useful addition? Or does it overlap too much with the choices API? 

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/59072aa1-7e7a-4fcf-8dd1-effde66675c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: User.username max_length 254

[Chris Foresman]

Given that 1.8 is an LTS, and increasing the default username length 
addresses the 80% use-case for custom user models, isn't it worth adding 
this change now (even if it philosophically violates the alpha/beta split)?



On Wednesday, February 25, 2015 at 12:24:20 PM UTC-6, Tim Graham wrote:
>
> Well, this change wouldn't have been made after alpha (feature-freeze) 
> either. As there haven't been any outright rejections of the idea, I think 
> the next step is for someone to write a patch and carefully consider and 
> document and backwards compatibility concerns.
>
> On Wednesday, February 25, 2015 at 11:19:46 AM UTC-5, Daniel Hawkins wrote:
>>
>> Beta 1 marks the end of any changes that aren't considered release 
>>> blocking bugs. A bug is a "Release blocker" if it's a regression from a 
>>> previous version of Django or if it's an important bug in a new feature.
>>
>>
>> ... so I guess the ship has sailed on this idea?  :(
>>
>> On Wednesday, February 11, 2015 at 3:27:35 AM UTC-5, Daniel Hawkins wrote:
>>>
>>> Yes please!  Since contrib.auth.models.User.email is an EmailField, 
>>> that change will require everyone to run a migration, right?  Then we might 
>>> as well change the character limit on the username field at the same 
>>> time, no?  And any other defaults that might be less-than-reasonable?
>>>
>>> I was going to update the longerusername package by adding a Django 1.7 
>>> migration, but it seems I can't alter fields on the User model from 
>>> within another app's migrations in Django 1.7.  This was possible with 
>>> South, but it appears to be impossible with Django migrations (except 
>>> perhaps with raw SQL, which seems like a bad idea).  So now I *have to* 
>>> create a custom user model just so I can migrate to Django 1.7 (which I 
>>> *have 
>>> to* do in order to continue getting security releases after 1.8 is 
>>> released).
>>>
>>> According to the docs, setting a custom user model after you've already 
>>> run initial migrations is not supported (
>>> https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#substituting-a-custom-user-model).
>>>  
>>>  So, for anyone without a custom user model, who is already running on 
>>> Django 1.7 in production, who would like to have usernames longer than 30 
>>> characters, there is no way to make that happen.
>>>
>>>
>>> On Friday, February 6, 2015 at 8:10:02 PM UTC-5, Collin Anderson wrote:

 Hi All,

 I was reminded by:
 Allow shadowing of abstract fields 
 https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ
 and https://code.djangoproject.com/ticket/24288 (Custom User Models 
 for small tweaks).

 Could we reopen https://code.djangoproject.com/ticket/20846 
 
  
 and increase User.username max_length to 254?

 Personally, that's the only thing I've ever needed to change about my 
 User class. I just need it long enough to hold email addresses. I've seen 
 many other people wanting the same thing.

 In 1.8 we migrated the length of EmailField from 75 to 254, so it 
 should be almost™ as easy to change the username field.

 If needed, we could keep the 30-character limit on UserCreationForm and 
 UserChangeForm for backwards compatibility. The limit in the database is 
 the real killer :) Though, consistency is also nice.

 Thanks,
 Collin



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a9542359-cc2d-43cb-922f-1addb78216f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: User.username max_length 254

[Josh Smeaton]

As Tim pointed out, it's unlikely that the change would have made Alpha, 
let alone Beta. Adding a new feature now breaks the 'philosophical' release 
rules but it also allows a feature through without the wider community 
testing in alpha and beta (now that it's cut). As far as I can tell, 
increasing the length of the field only really affects existing deployments 
without a custom user model. New deployments are free to implement custom 
user models if they require different constraints.

So the set of users with existing deployments without a custom user model 
would probably make up at least 80%, but I'd bet an extremely large portion 
of those users don't absolutely have to have an increased username field. 
They've gone this long without it. Breaking the release rules to push a 
change that'll affect such a large segment of the community isn't going to 
fly.

Cheers

On Thursday, 26 February 2015 15:56:26 UTC+11, Chris Foresman wrote:
>
> Given that 1.8 is an LTS, and increasing the default username length 
> addresses the 80% use-case for custom user models, isn't it worth adding 
> this change now (even if it philosophically violates the alpha/beta split)?
>
>
>
> On Wednesday, February 25, 2015 at 12:24:20 PM UTC-6, Tim Graham wrote:
>>
>> Well, this change wouldn't have been made after alpha (feature-freeze) 
>> either. As there haven't been any outright rejections of the idea, I think 
>> the next step is for someone to write a patch and carefully consider and 
>> document and backwards compatibility concerns.
>>
>> On Wednesday, February 25, 2015 at 11:19:46 AM UTC-5, Daniel Hawkins 
>> wrote:
>>>
>>> Beta 1 marks the end of any changes that aren't considered release 
 blocking bugs. A bug is a "Release blocker" if it's a regression from a 
 previous version of Django or if it's an important bug in a new feature.
>>>
>>>
>>> ... so I guess the ship has sailed on this idea?  :(
>>>
>>> On Wednesday, February 11, 2015 at 3:27:35 AM UTC-5, Daniel Hawkins 
>>> wrote:

 Yes please!  Since contrib.auth.models.User.email is an EmailField, 
 that change will require everyone to run a migration, right?  Then we 
 might 
 as well change the character limit on the username field at the same 
 time, no?  And any other defaults that might be less-than-reasonable?

 I was going to update the longerusername package by adding a Django 
 1.7 migration, but it seems I can't alter fields on the User model 
 from within another app's migrations in Django 1.7.  This was possible 
 with 
 South, but it appears to be impossible with Django migrations (except 
 perhaps with raw SQL, which seems like a bad idea).  So now I *have to* 
 create a custom user model just so I can migrate to Django 1.7 (which I 
 *have 
 to* do in order to continue getting security releases after 1.8 is 
 released).

 According to the docs, setting a custom user model after you've already 
 run initial migrations is not supported (
 https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#substituting-a-custom-user-model).
  
  So, for anyone without a custom user model, who is already running on 
 Django 1.7 in production, who would like to have usernames longer than 30 
 characters, there is no way to make that happen.


 On Friday, February 6, 2015 at 8:10:02 PM UTC-5, Collin Anderson wrote:
>
> Hi All,
>
> I was reminded by:
> Allow shadowing of abstract fields 
> https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ
> and https://code.djangoproject.com/ticket/24288 (Custom User Models 
> for small tweaks).
>
> Could we reopen https://code.djangoproject.com/ticket/20846 
> 
>  
> and increase User.username max_length to 254?
>
> Personally, that's the only thing I've ever needed to change about my 
> User class. I just need it long enough to hold email addresses. I've seen 
> many other people wanting the same thing.
>
> In 1.8 we migrated the length of EmailField from 75 to 254, so it 
> should be almost™ as easy to change the username field.
>
> If needed, we could keep the 30-character limit on UserCreationForm 
> and UserChangeForm for backwards compatibility. The limit in the database 
> is the real killer :) Though, consistency is also nice.
>
> Thanks,
> Collin
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.g

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Thanks Russell.

Investigating contrib apps I can see some are django apps using django
framework and some are modules which is used to extend django frameworks
functionality.

For admin app theres is no use of urls.py for the admin app but admin_urls
in template tags, admin_lists etc. isn't it possible to used classed based
views,  to handle views and forms? there are also many files some of them
could be changed unders class based views. are this type of checking shoul
I perform to prepare my proposal for best practices ?

Reagrds



On Tue, Feb 24, 2015 at 6:09 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> Hi Asif,
>
> The "Best Practices" project requires a bit of investigation on your part.
> The project description gives one suggestion (expanding the use of
> Class-based views), but essentially, pick any feature that has been added
> in the last 5 years, and see if Django is making good use of that feature
> internally. If not, propose how we could be doing better.
>
> Yours,
> Russ Magee %-)
>
> On Mon, Feb 23, 2015 at 1:00 AM, Asif Saifuddin  wrote:
>
>> Seems my previous idea is not well suited for gsoc right now. have to
>> look for more convanient ideas then. what about best practise update? where
>> will I get Ideas about what are considered as best practise in django
>> 1.8/+? or other suggestions?
>>
>> Regards
>>
>> On Sun, Feb 22, 2015 at 6:36 AM, Russell Keith-Magee <
>> russ...@keith-magee.com> wrote:
>>
>>>
>>> To my mind, the goal of this project isn't to replace Django's routing
>>> infrastructure - as Josh and Florian have pointed out, unless you can
>>> provide a backwards compatible interface as well as tangible API
>>> improvements, we're unlikely to adopt that code.
>>>
>>> However, there *would* be benefit in making changes to Django's codebase
>>> so that if someone *wanted* to use an alternate routing infrastructure,
>>> they could, *in their own project*. In this context, the purpose of using
>>> webOb/werkzeug routing isn't to provide new features or backwards
>>> compatibility - it's to demonstrate that a completely alien codebase with
>>> analogous features can be integrated into Django's infrastructure using a
>>> standardised API.
>>>
>>> That said, I don't know enough about webOb or werkzeug to know if this
>>> is even plausible, so you'd need to provide a very strong technical
>>> proposal for this to be selected as a GSoC project.
>>>
>>> Yours,
>>> Russ Magee %-)
>>>
>>> On Sun, Feb 22, 2015 at 8:04 AM, Josh Smeaton 
>>> wrote:
>>>
 To expand on Florians reply, why do you think replacing the routing
 infrastructure is a good idea? Is there any tangible benefit in doing so?
 Can you demonstrate that you can stay completely backwards compatible while
 realising those benefits? If there answer is no to benefits or backwards
 compatibility, then I don't think you're going to see much support for the
 idea.

 Regards,


 On Sunday, 22 February 2015 07:52:49 UTC+11, Florian Apolloner wrote:
>
> Hi Aisf,
>
> while it theoretically would be possible to replace all of Django's
> request/response handling with Werkzeug, there is not much gain in it
> currently -- especially when considering backwards compatibility etc…
>
> Cheers,
> Florian
>
> On Saturday, February 21, 2015 at 9:14:27 PM UTC+1, Asif Saifuddin
> wrote:
>>
>> Hi,
>>
>> Analyzing django code base docs and other tools I'm thinking of using
>> werkzeug's routing infrastructure for developing django's one. django 
>> http
>> mechanism can e re written using webOb/werkzeugs utilities too. this will
>> need working django urlresolve, urls, middlewares, views, http and some
>> more related components. Introducinf werkzeug/+webOb in django will let
>> eliminate some of django's built in way of handling request/response
>> processing, urlresolving, url routing, view processing some error 
>> handling
>> etc.
>>
>> Sould I go for a detail one with what I have thought to implement
>> till now?
>>
>> ./auvipy
>>
>> On Wed, Feb 4, 2015 at 5:57 AM, Russell Keith-Magee <
>> rus...@keith-magee.com> wrote:
>>
>>>
>>> On Wed, Feb 4, 2015 at 1:49 AM, Asif Saifuddin 
>>> wrote:
>>>
 Thank you both for the feedback. I will continue my analysis to
 understand django well and also try to contribute some patch on django 
 if I
 can.


 For django URL dispatcher improvement I am also looking for some
 suggestions. Should I also look to some tool like werkzeug, webob along
 side django http, url dispatch, middleware and related stuffs. Some 
 guide
 will help me to dig more and go to proper direction.

>>>
>>> Take inspiration from wherever you can. Those patches will
>>> demonstrate different ways of doing dispatch, and d