Re: [Django] #27368: mail.tests.SMTPBackendTests.test_server_login generates ResourceWarning unclosed socket

2016-10-19 Thread Django 
#27368: mail.tests.SMTPBackendTests.test_server_login generates ResourceWarning
unclosed socket
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jon Dufresne):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/7413 PR]

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.adc4601c4d08bfd760384ca30fa8885f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27368: mail.tests.SMTPBackendTests.test_server_login generates ResourceWarning unclosed socket

2016-10-19 Thread Django 
#27368: mail.tests.SMTPBackendTests.test_server_login generates ResourceWarning
unclosed socket
+
   Reporter:  Jon Dufresne  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Testing framework |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 {{{
 $ python -Wall runtests.py --failfast
 mail.tests.SMTPBackendTests.test_server_login
 Testing against Django installed in '/home/jon/devel/django/django' with
 up to 4 processes
 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 /usr/lib64/python3.5/socket.py:646: ResourceWarning: unclosed
 
   self._sock = None
 .
 --
 Ran 1 test in 0.048s

 OK
 Destroying test database for alias 'default'...
 Destroying test database for alias 'other'...
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.a4922f658038abd4d192f8036932141c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27367: Document behaviour when several urls have the same name

2016-10-19 Thread Django 
#27367: Document behaviour when several urls have the same name
-+
 Reporter:  Christoph Schindler  |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Documentation|Version:  1.10
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Currently -- as far as i can tell -- it is no problem to give the same
 name to different urls and then reverse them:

 {{{
 url(r'^spam/$', 'myapp.views.index', name='myview'),
 url(r'^spam/(?P[\w-]+)/$', 'myapp.views.detail', name='myview'),
 url(r'^spam/(?P[\w-]+)/(?P[\w-]+)/$', 'myapp.views.detail',
 name='myview'),
 }}}

 {{{
 In [8]: reverse('myview', kwargs={'ham': 'foo', 'eggs': 'bar'})
 Out[8]: u'/spam/foo/bar/'

 In [9]: reverse('myview', kwargs={'ham': 'foo'})
 Out[9]: u'/spam/foo/'

 In [10]: reverse('myview')
 Out[10]: u'/spam/'
 }}}

 But this is not documented and it is not clear, whether this is supported
 or unsupported behaviour.

 It should either be stated clearly that url names should be unique /or/
 that it is possible to "overload" url patterns by giving them the same
 name when they have a different number of arguments.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/046.71fe18991e8610a11a73ca9cc0ea667c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27364: DATE_INPUT_FORMATS is not working

2016-10-19 Thread Django 
#27364: DATE_INPUT_FORMATS is not working
-+-
 Reporter:  Alex |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  date | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * needs_docs:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 My understanding is that only form fields (rather than model fields)
 handle those formats (e.g.
 
[https://github.com/django/django/blob/90c3b11e873a326219a68c14a3b5dca0181e7b3c/django/forms/fields.py#L409
 DateField]).

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.49538154591618ccf0a85f2cb556ed52%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27366: KeyError: 'no_color' in base.py, l. 314

2016-10-19 Thread Django 
#27366: KeyError: 'no_color' in base.py, l. 314
---+--
 Reporter:  Geoffrey R.|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Migrations |  Version:  1.10
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by Geoffrey R.):

 Replying to [comment:1 Tim Graham]:
 > Django is likely not at fault, see :ticket:26315#comment:7.

 Alright, I'll submit a patch to mezzanine then.

 Sorry for the inconvenience.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.d100143b88f03ae4821803023d051b9b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27366: KeyError: 'no_color' in base.py, l. 314

2016-10-19 Thread Django 
#27366: KeyError: 'no_color' in base.py, l. 314
---+--
 Reporter:  Geoffrey R.|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Migrations |  Version:  1.10
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by Geoffrey R.):

 I made a Pull Request on github to fix this issue:
 https://github.com/django/django/pull/7412

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.c0789948372b8a83ec7d792f527eceac%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27366: KeyError: 'no_color' in base.py, l. 314

2016-10-19 Thread Django 
#27366: KeyError: 'no_color' in base.py, l. 314
---+--
 Reporter:  Geoffrey R.|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Migrations |  Version:  1.10
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by Tim Graham):

 * status:  new => closed
 * needs_docs:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 Django is likely not at fault, see :ticket:26315#comment:7.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.5c316c99e8663ac1a29e701d20cae835%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27366: KeyError: 'no_color' in base.py, l. 314

2016-10-19 Thread Django 
#27366: KeyError: 'no_color' in base.py, l. 314
---+
 Reporter:  Geoffrey R.|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Migrations |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 Hello.

 I played with Django Mezzanine [http://mezzanine.jupo.org/] and when
 creating the database with the following settings:


 {{{
 USE_MODELTRANSLATION = True

 LANGUAGE_CODE = 'en'

 LANGUAGES = (
 ('en', _('English')),
 ('fr', _('French'))
 )
 }}}

 and executing

 {{{
 python manage.py createdb
 }}}

 as mentionned on mezzanine's website, I get the following Traceback after
 having provided my login / email / pwd and saying that I want to translate
 fields:

 {{{
 [...]
 Django-modeltranslation is installed for this project and you have
 specified to use i18n.
 Would you like to update translation fields from the default ones?
 (yes/no): yes
 Traceback (most recent call last):
   File "manage.py", line 14, in 
 execute_from_command_line(sys.argv)
   File "/home/ge0/envs/bakadeshi/lib/python3.5/site-
 packages/django/core/management/__init__.py", line 367, in
 execute_from_command_line
 utility.execute()
   File "/home/ge0/envs/bakadeshi/lib/python3.5/site-
 packages/django/core/management/__init__.py", line 359, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/ge0/envs/bakadeshi/lib/python3.5/site-
 packages/django/core/management/base.py", line 294, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/ge0/envs/bakadeshi/lib/python3.5/site-
 packages/django/core/management/base.py", line 345, in execute
 output = self.handle(*args, **options)
   File "/home/ge0/envs/bakadeshi/lib/python3.5/site-
 packages/mezzanine/core/management/commands/createdb.py", line 61, in
 handle
 func()
   File "/home/ge0/envs/bakadeshi/lib/python3.5/site-
 packages/mezzanine/core/management/commands/createdb.py", line 151, in
 translation_fields
 verbosity=self.verbosity, interactive=False)
   File "/home/ge0/envs/bakadeshi/lib/python3.5/site-
 packages/django/core/management/base.py", line 314, in execute
 if options['no_color']:
 KeyError: 'no_color'
 }}}

 Python version: 3.5.2

 Installed packages:

 {{{
 Mezzanine==4.2.2
 django-modeltranslation
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/046.d4d20423a08a891f353bd71a4457fe97%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27365: Fields suddenly not found.

2016-10-19 Thread Django 
#27365: Fields suddenly not found.
-+-
 Reporter:  Brandon  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  FieldDoesNotExist| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => needsinfo


Comment:

 Please see TicketClosingReasons/UseSupportChannels for ways to get help
 and reopen the ticket if you can say why Django is at fault.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/088.452d5b08c449ee6141470dec2ffcdb49%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27365: Fields suddenly not found.

2016-10-19 Thread Django 
#27365: Fields suddenly not found.
-+-
 Reporter:  Brandon  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  FieldDoesNotExist| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Brandon):

 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * component:  Uncategorized => Database layer (models, ORM)
 * needs_tests:   => 0
 * needs_better_patch:   => 0


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/088.319ad686dd31290cf5f07956105dffec%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27365: Fields suddenly not found.

2016-10-19 Thread Django 
#27365: Fields suddenly not found.
--+---
 Reporter:  brandon+django@…  |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Uncategorized |Version:  1.9
 Severity:  Normal|   Keywords:  FieldDoesNotExist
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+---
 Hello,
 We just moved from Django 1.7.10 to 1.9.9. After the move a new error
 began occurring. The exception is:
 {{{ FieldDoesNotExist: No related field named '...' }}}

 We see the exception when accessing the reverse OneToOne of a non-abstract
 models.Model subclass that has been subclassed.
 {{{
 class Case(models.Model):
...lots of fields...
 class SubclassCase(Case):
   ...lots more fields...
 SubclassCase.objects.get(id=12345)
 }}}
 generates traceback
 {{{
 Traceback (most recent call last):
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/handlers/base.py", line 149, in get_response
 response = self.process_exception_by_middleware(e, request)
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/handlers/base.py", line 147, in get_response
 response = wrapped_callback(request, *callback_args,
 **callback_kwargs)
   File "/usr/local/lib/python2.7/dist-
 packages/django/contrib/auth/decorators.py", line 23, in _wrapped_view
 return view_func(request, *args, **kwargs)
   File "/var/www/vhosts/prod/lib/workpath/workflow/views.py", line 1730,
 in view_case
 additional_view = case_module.view(case)
   File
 "/var/www/vhosts/prod/lib/workpath/workflow/cases/subclasscase/views.py",
 line 286, in view
 case = SubclassCase.objects.get(id=case.id)
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/models/manager.py", line 122, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py",
 line 378, in get
 clone = self.filter(*args, **kwargs)
   File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py",
 line 790, in filter
 return self._filter_or_exclude(False, *args, **kwargs)
   File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py",
 line 808, in _filter_or_exclude
 clone.query.add_q(Q(*args, **kwargs))
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/models/sql/query.py", line 1243, in add_q
 clause, _ = self._add_q(q_object, self.used_aliases)
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/models/sql/query.py", line 1269, in _add_q
 allow_joins=allow_joins, split_subq=split_subq,
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/models/sql/query.py", line 1149, in build_filter
 lookups, parts, reffed_expression = self.solve_lookup_type(arg)
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/models/sql/query.py", line 1035, in solve_lookup_type
 _, field, _, lookup_parts = self.names_to_path(lookup_splitted,
 self.get_meta())
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/models/sql/query.py", line 1345, in names_to_path
 targets = (final_field.remote_field.get_related_field(),)
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/models/fields/reverse_related.py", line 244, in
 get_related_field
 self.field_name)
 FieldDoesNotExist: No related field named 'subclasscase'
 }}}
 Whenever the exception occurs, it is exactly this exception every time
 once {{{_filter_or_exclude}}} is reached. We've seen it in the context of
 function based views, class based views, the views of our tastypie backed
 API (XML and JSON) and from view functions that support light-weight JSON
 functions.
 We see it across multiple disconnected deployments with completely
 separate machines, datastores, databases, etc.
 We do not see it all the time.
 We do not see it when running under the development server.
 An apache restart fixes it... for a little while.

 We are using mpm_event with WSGI.
 Our mpm_event configuration looks like this:
 {{{
 
 StartServers   2
 MinSpareThreads   25
 MaxSpareThreads   75
 ThreadLimit   64
 ThreadsPerChild   25
 MaxRequestWorkers150
 MaxConnectionsPerChild  5000
 
 }}}
 Our WSGI ({{{libapache2-mod-wsgi 3.4-4ubuntu2.1.14.04.2}}}) configuration
 looks like this:
 {{{
 WSGIDaemonProcess prod processes=2 python-path=/usr/local/lib/python2.7
 /dist-packages:/var/www/vhosts/prod/lib
 }}}
 Based on our experience that an apache restart fixed it we changed our
 WSGI configuration to this:
 {{{
 WSGIDaemonProcess prod processes=10 threads=1 maximum-requests=50 python-
 path=/usr/local/lib/python2.7/dist-packages:/var/www/vhosts/prod/lib
 }}}
 This causes the apache children to cycle quickly and the error goes away
 but as

Re: [Django] #27337: Convoluted MTI with abstract model mixin fails on PY2, works on PY3

2016-10-19 Thread Django 
#27337: Convoluted MTI with abstract model mixin fails on PY2, works on PY3
-+-
 Reporter:  Tim Heap |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  python2, mti py2 | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Aymeric Augustin):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 Closing as Django doesn't seem to be at fault here.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.12850f335b2af6658b3062403f95df2d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27337: Convoluted MTI with abstract model mixin fails on PY2, works on PY3

2016-10-19 Thread Django 
#27337: Convoluted MTI with abstract model mixin fails on PY2, works on PY3
-+-
 Reporter:  Tim Heap |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  python2, mti py2 | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Andrew Nester):

 Hi guys!

 I was able to reproduce this behavior just in plain Python 2.7
 You can check my question on Stack Overflow for more details.
 http://stackoverflow.com/questions/40134852/metaclass-inheritance-in-
 python-2-and-python-3

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.0655bab28564efcb730ae55e5faffcf7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27364: DATE_INPUT_FORMATS is not working

2016-10-19 Thread Django 
#27364: DATE_INPUT_FORMATS is not working
--+
 Reporter:  Alex  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.10
 Severity:  Normal|   Keywords:  date
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Per the Django Docs, in settings.py if I set USE_L10N to false, I should
 be able to override the supported date formats. My settings.py has the
 following:



 {{{
 LANGUAGE_CODE = 'en-us'

 TIME_ZONE = 'UTC'

 USE_I18N = False

 USE_L10N = False

 USE_TZ = False

 DATE_INPUT_FORMATS = [
 '%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', # '2006-10-25', '10/25/2006',
 '10/25/06'
 '%b %d %Y', '%b %d, %Y',# 'Oct 25 2006', 'Oct 25, 2006'
 '%d %b %Y', '%d %b, %Y',# '25 Oct 2006', '25 Oct, 2006'
 '%B %d %Y', '%B %d, %Y',# 'October 25 2006', 'October 25,
 2006'
 '%d %B %Y', '%d %B, %Y',# '25 October 2006', '25 October,
 2006'
 ]
 }}}

 I have a model that looks like the following:

 {{{
 class DateTest(models.Model):
 date = models.DateField(blank=True, null=True)
 }}}

 When I run the following command, i get an error:


 {{{
 >>> DateTest.objects.create(date='09/01/2016')
 Traceback (most recent call last):
   File "", line 1, in 
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/manager.py", line 85, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/query.py", line 399, in create
 obj.save(force_insert=True, using=self.db)
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/base.py", line 796, in save
 force_update=force_update, update_fields=update_fields)
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/base.py", line 824, in save_base
 updated = self._save_table(raw, cls, force_insert, force_update,
 using, update_fields)
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/base.py", line 908, in _save_table
 result = self._do_insert(cls._base_manager, using, fields, update_pk,
 raw)
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/base.py", line 947, in _do_insert
 using=using, raw=raw)
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/manager.py", line 85, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/query.py", line 1045, in _insert
 return query.get_compiler(using=using).execute_sql(return_id)
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/sql/compiler.py", line 1053, in execute_sql
 for sql, params in self.as_sql():
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/sql/compiler.py", line 1006, in as_sql
 for obj in self.query.objs
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/sql/compiler.py", line 1006, in 
 for obj in self.query.objs
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/sql/compiler.py", line 1005, in 
 [self.prepare_value(field, self.pre_save_val(field, obj)) for field in
 fields]
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/sql/compiler.py", line 945, in prepare_value
 value = field.get_db_prep_save(value, connection=self.connection)
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/fields/__init__.py", line 755, in
 get_db_prep_save
 prepared=False)
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/fields/__init__.py", line 1280, in
 get_db_prep_value
 value = self.get_prep_value(value)
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/fields/__init__.py", line 1275, in
 get_prep_value
 return self.to_python(value)
   File "/Users/abeach/Workspace/orchard/env/lib/python3.5/site-
 packages/django/db/models/fields/__init__.py", line 1250, in to_python
 params={'value': value},
 django.core.exceptions.ValidationError: ["'09/01/2016' value has an
 invalid date format. It must be in -MM-DD format."]

 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received

Re: [Django] #27361: Use "from django import forms" in forms api examples (was: Small clean up on forms api documentation)

2016-10-19 Thread Django 
#27361: Use "from django import forms" in forms api examples
-+-
 Reporter:  Zach Borboa  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Ready for checkin
 * component:  Uncategorized => Documentation


Old description:



New description:

 It's more common to define forms using a style like:
 {{{
 from django import forms

 class PersonForm(forms.Form):
first_name = forms.CharField()
 }}}
 than `from django.forms import Form, CharField`.

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.66baf7d35fa02e3f253374690a4a7d1a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27361: Use "from django import forms" in forms api examples

2016-10-19 Thread Django 
#27361: Use "from django import forms" in forms api examples
-+-
 Reporter:  Zach Borboa  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"90c3b11e873a326219a68c14a3b5dca0181e7b3c" 90c3b11e]:
 {{{
 #!CommitTicketReference repository=""
 revision="90c3b11e873a326219a68c14a3b5dca0181e7b3c"
 Fixed #27361 -- Used "from django import forms" in forms api docs.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.3453570cc23d2d61d5a5b20b4350654d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27361: Use "from django import forms" in forms api examples

2016-10-19 Thread Django 
#27361: Use "from django import forms" in forms api examples
-+-
 Reporter:  Zach Borboa  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"3f730457d861a661079832792e5085378464a8ff" 3f73045]:
 {{{
 #!CommitTicketReference repository=""
 revision="3f730457d861a661079832792e5085378464a8ff"
 [1.10.x] Fixed #27361 -- Used "from django import forms" in forms api
 docs.

 Backport of 90c3b11e873a326219a68c14a3b5dca0181e7b3c from master
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.aefa813bb5e4765380cc673ed1a1cf27%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27363: SessionMiddleware can return redirect(request.path) which might be an unsafe thing to do

2016-10-19 Thread Django 
#27363: SessionMiddleware can return redirect(request.path) which might be an
unsafe thing to do
--+--
 Reporter:  Raphael Michel|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Nicole Klünder):

 * cc: nicole@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.1947503c9bedbfd4d2232d568eefefb5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27363: SessionMiddleware can return redirect(request.path) which might be an unsafe thing to do

2016-10-19 Thread Django 
#27363: SessionMiddleware can return redirect(request.path) which might be an
unsafe thing to do
--+
 Reporter:  Raphael Michel|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.sessions  |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Hello everyone,

 a friend of mine just spent hours to debug why a view randomly responded
 to a POST request with a redirect even though no redirects appeared in
 the code at all. While the root cause was a caching issue in the session
 backend, the redirect was caused by the redirect call in SessionMiddleware
 that has been introduced in
 
[https://github.com/django/django/commit/3389c5ea229884a1943873fe7e7ffc2800cefc22
 #diff-7e0a8bc945a2cf57bf4e4b4c9804c340R58] in an attempt to fix the issue
 reported in #21608.

 I believe this is a regression in 1.10 as it causes highly unexpected
 behaviour by issuing a redirect to the same view, a view that might have
 been called via POST and not even support handling GET requests.

 Also, the patch is only appropriate under the assumption that sessions are
 only used for authentication. The code comment says "The user is now
 logged out; redirecting to same page will result in a redirect to the
 login page if required". This is problematic whenever sessions are used
 for something other than authentication and a subsequent GET request might
 do something completely different than redirecting to the login page.

 The underlying problem that causes #21608 is to be seen as a race
 condition between two requests, where one request deletes the session and
 then another request tries to save it. I believe, if this race condition
 occurs, we either need to fail silently (just don't save) or fail loudly
 (raise e.g. an error somewhere between 400 and 500, like we raise a 403 if
 an old CSRF token is used after a logout which is a different but similar
 race).

 I'm personally in favour of failing loudly, as the view might expect the
 changed session to be saved - which it then isn't.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.c315c5cc7d3d043f66ddef3760ff7b78%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27299: Document Widget.use_required_attribute()

2016-10-19 Thread Django 
#27299: Document Widget.use_required_attribute()
-+-
 Reporter:  Tim Graham   |Owner:  Jon
 Type:   |  Dufresne
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jon Dufresne):

 * owner:  nobody => Jon Dufresne
 * status:  new => assigned


Comment:

 I will try to find some time for this.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.b508c75813494ce53934654aeea6bed2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27362: Omitting default_app_config in __init__.py happens to easily.

2016-10-19 Thread Django 
#27362: Omitting default_app_config in __init__.py happens to easily.
+--
 Reporter:  Thomas Güttler  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Uncategorized   |  Version:  1.10
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Aymeric Augustin):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Yes, I can see the problem.

 That's one of the reasons why I'm against `default_app_config`. It's only
 there for backwards compatibility and should only be used by pluggable
 apps that predate Django 1.7, need a custom app config and don't want to
 ask their users to update their `INSTALLED_APPS` setting.

 Unfortunately, even if `default_app_config` was removed, we'd still be
 stuck with two kinds of apps: those that provide a custom AppConfig and
 those that don't. This results in a mixed style in `INSTALLED_APPS`, and
 then it's easy to reference an app by its package name and load it with
 the base `AppConfig` class instead of its custom `MyAppConfig` class.

 Like you I'm not really coming up with great ideas to improve the
 situation...

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f103feb7f70227488520d11fa72b585f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27362: Omitting default_app_config in __init__.py happens to easily.

2016-10-19 Thread Django 
#27362: Omitting default_app_config in __init__.py happens to easily.
+
 Reporter:  Thomas Güttler  |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Component:  Uncategorized   |Version:  1.10
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Up to now it is likely that the programmer forgets to add
 "default_app_config = 'myapp.apps.AppConfig" in `__init__.py`.

 It took too much time to debug why the signal handled of a reusable app
 was not called on one system (INSTALLED_APPS=[... 'myapp'])
 and called on another system (INSTALLED_APPS=[...,
 'myapp.apps.AppConfig']).

 I have no clue how to solve this at the moment.

 But I hope you can understand that "pain".

 What can be done to assist the programmer?

 Related docs: https://docs.djangoproject.com/en/1.10/ref/applications
 /#configuring-applications

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.b1a7b55df8b28a4e593e4abe621a5f81%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27090: pg_get_serial_sequence is broken on postgres, use a lookup in information_schema.columns instead

2016-10-19 Thread Django 
#27090: pg_get_serial_sequence is broken on postgres, use a lookup in
information_schema.columns instead
-+-
 Reporter:  Hanne Moa|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres sequence| Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Hanne Moa):

 The postgres-general list has some very interesting spam filters, took a
 while to get through. (Don't have a line in the body of the email starting
 with the word "which"...)

 https://www.postgresql.org/message-id/nu7ebq%24a2h%241%40blaine.gmane.org

 A different query is suggested, the result need not be parsed:

 "Personally, I'd try looking in pg_depend to see if the column's default
 expression has a dependency on a relation of type sequence.  That avoids
 all the fun of parsing the expression and turns it into a simple SQL
 join problem." -- Tom Lane

 It's a very simple join =):

 {{{
 select sn.nspname as sequence_schema, s.relname as sequence_name,
 col.attname
 from pg_class s
   join pg_namespace sn on sn.oid = s.relnamespace
   join pg_depend d on d.refobjid = s.oid and
 d.refclassid='pg_class'::regclass
   join pg_attrdef ad on ad.oid = d.objid and d.classid =
 'pg_attrdef'::regclass
   join pg_attribute col on col.attrelid = ad.adrelid and col.attnum =
 ad.adnum
   join pg_class tbl on tbl.oid = ad.adrelid
   join pg_namespace n on n.oid = tbl.relnamespace
 where s.relkind = 'S'
   and d.deptype in ('a', 'n')
   and n.nspname = 'public'
   and tbl.relname = 'THE_TABLE_NAME'
   and col.attname = 'THE_COLUMN_NAME'
 }}}

 Anyway, even using the information_schema, it might return a schema in
 addition to the name so adjustments need to be made to my existing code.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.ecf9be32e04e664302590ccd5a9d6802%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26401: Allow auth machinery to be used without installing auth app

2016-10-19 Thread Django 
#26401: Allow auth machinery to be used without installing auth app
--+-
 Reporter:  Matt Johnson  |Owner:  Andrew Konoff
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  auth 1.11 | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by Jon Dufresne):

 * has_patch:  0 => 1


Comment:

 I'm unable to think of a sensible solution to the `ContentType`
 `auth.Permission` dependency issue. Therefore, I'm suggesting to revert my
 previous PR as using auth without migrations will not fully work.

 [https://github.com/django/django/pull/7410 PR to revert]

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.569454b0c1ac318ff63511cc99412595%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27360: Make it easier to track down the offending models for AlreadyRegistered exceptions

2016-10-19 Thread Django 
#27360: Make it easier to track down the offending models for AlreadyRegistered
exceptions
--+
 Reporter:  Ed Morley |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Keryn Knight):

 * cc: django@… (added)


Comment:

 I'd think that providing the ModelAdmin label would be useful - the model
 is always going to be the one you're trying to register the "current"
 ModelAdmin for, so showing it's module or path is only going to be truly
 useful with multiple models of the same name?

 Perhaps something like:
 {{{AlreadyRegistered: Cannot use myapp.admin.SecondModelAdmin for
 myotherapp.MyModel, because myotherapp.admin.MyModelAdmin is already
 registered}}}

 Wording isn't perfect (for one thing, all of them say "AlreadyRegistered:
 ... already registered"), but you probably get the idea about surfacing as
 much information as possible.
 The previously registered ModelAdmin would have to be extracted from the
 `_registry` to get it's label, but that ought to be simple enough.

 I don't know whether shortening the model to {{{applabel.modelname}}} is
 better or worse than including it's actual module -- models are routinely
 referred to that way everywhere else, but given a ModelAdmin doesn't
 really have an applabel, that would ''have'' to show the full class
 name/module, so it might be inconsistent and confusing if the Model were
 shortened.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.b18cb4bf1808aa351a0cf7b907a88f0b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27361: Small clean up on forms api documentation

2016-10-19 Thread Django 
#27361: Small clean up on forms api documentation
-+-
 Reporter:  Zach Borboa  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Zach Borboa:

Old description:

> PR

New description:



--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.1ff58489b4ff7ae94f254d3807bc9922%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27361: Small clean up on forms api documentation

2016-10-19 Thread Django 
#27361: Small clean up on forms api documentation
-+-
 Reporter:  Zach Borboa  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Zach Borboa):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:



New description:

 PR

--

Comment:

 PR https://github.com/django/django/pull/7407

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.2f99a9a55232e94b639d946d5b0bd0ee%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27361: Small clean up on forms api documentation

2016-10-19 Thread Django 
#27361: Small clean up on forms api documentation
--+
 Reporter:  Zach Borboa   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Uncategorized |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.41268127be14e014a5f082fccecffd35%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.