date:20181003

Re: [Django] #29820: Remove unused, undocumented, and unnecessary dummy template backend

2018-10-03 Thread Django

#29820: Remove unused, undocumented, and unnecessary dummy template backend
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  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
-+-

Comment (by Jon Dufresne):

 > ensuring consistency with other pluggable backends, as explained by
 Adam; if we're going to remove it, we should also remove other dummy
 backends;

 These other dummy backends are currently either documented or used.

 The dummy cache backend is documented at:

 {{{
 ./docs/ref/settings.txt:151:*
 ``'django.core.cache.backends.dummy.DummyCache'``
 ./docs/topics/cache.txt:336:Dummy caching (for development)
 }}}

 On these pages the backend is recommended for use in development/testing.
 Personally, I'm a bit unconvinced that using a different cache backend for
 development/testing is the best idea -- for the same reasons that using a
 different database backend is bad idea -- as subtle implementation
 differences won't be noticed until deployed to production. I guess that is
 besides the point. However, I think this development/testing use case
 could easily be replaced by the locmem backend in the documentation.
 Therefore, if its removal is also desired, I think it could be safely
 deprecated and removed in time.


 The dummy email backend is documented at:

 {{{
 ./docs/topics/email.txt:552:Dummy backend
 }}}

 Upon inspection, its purpose seems mostly -- if not entirely -- a
 duplicate of the locmem backend. Therefore, if its removal is also
 desired, I think it could be safely deprecated and removed in time.


 The dummy database backend is used at:

 {{{
 ./django/db/utils.py:151:'ENGINE':
 'django.db.backends.dummy',
 ./django/db/utils.py:155:
 self._databases[DEFAULT_DB_ALIAS]['ENGINE'] = 'django.db.backends.dummy'
 ./django/db/utils.py:173:conn.setdefault('ENGINE',
 'django.db.backends.dummy')
 ./django/db/utils.py:175:conn['ENGINE'] =
 'django.db.backends.dummy'
 }}}

 The dummy database backend looks to be used to replace a configuration of
 no databases. I could investigate what removing this would mean. I would
 have to dive deeper before knowing if this is viable.


 So, after that quick research, I'm open to the idea of deprecating and
 removing these other dummy backends. WDYT? I can investigate what the
 concrete code changes will mean first if that'll help make a decision.

 > 2. providing a good starting point for people wanting to understand how
 template backends work; of course it's hard to say if it actually helped
 contributors.

 I think there is some value here, but I think it would ultimately be
 better served through documentation. The current version is:

 https://docs.djangoproject.com/en/dev/topics/templates/#custom-backends

 Is this known to be lacking anywhere? If so, I can try to improve it.


 > In addition, the dummy backend made it possible to test multiple
 template engines without external dependencies ...

 I find this to be the most convincing reason to keep it. If we feel test
 dependencies should be reduced or kept to a minimum, I understand. On the
 other hand, is there an expectation that developers will install
 `test/requirements/py3.txt` before running tests? The
 [https://docs.djangoproject.com/en/2.1/internals/contributing/writing-code
 /unit-tests/#running-the-unit-tests documentation suggests this is so].

 > I'm not seeing a lot of value in removing this bit of code ...

 Ok, no worries. I wanted to highlight undocumented and unused code
 (outside of tests). I think there is value in removing unused code and
 shifting the tests towards the more representative configuration scenarios
 of mixing Jinja2 with Django templates. If the decision is to keep it,
 that is fine.

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

Re: [Django] #27801: Make createsuperuser inspect environment variables for username and password

2018-10-03 Thread Django

#27801: Make createsuperuser inspect environment variables for username and
password
---+-
 Reporter:  Markus Holtermann  |Owner:  James Pic
 Type:  New feature|   Status:  assigned
Component:  contrib.auth   |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+-
Changes (by James Pic):

 * owner:  lsmag => James Pic
 * cc: James Pic (added)
 * has_patch:  0 => 1
 * easy:  0 => 1


Comment:

 For our use case, SUPERUSER_PASSWORD works to drop the dependency to
 expect in automation 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/065.5c0b10bebf1a96e7c4e7253ad7d18556%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29818: ValueError when parsing querydata to autofill a Django admin form

2018-10-03 Thread Django

#29818: ValueError when parsing querydata to autofill a Django admin form
---+--
 Reporter:  NastuzziSamy   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords:  django admin   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Herbert Fortes):

 Replying to [comment:2 Herbert Fortes]:
 > I also tried to reproduce.
 >
 > [03/Oct/2018 13:36:58] "POST
 /admin/core/course/add/?_to_field=id&_popup=1=plsbreak HTTP/1.1" 200
 10098
 >

 I am sorry for the "POST". Copy and Paste the wrong line.
 But I can not reproduce the ticket.

-- 
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/070.8b3e9936366a0832517fc37e3425cba5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29822: Timezone-aware widget for admin site

2018-10-03 Thread Django

Comment (by Simon Charette):

> ... because everything in the admin site operates in the server's time.

Not exactly true, everything operates in
`django.utils.timezone.get_current_timezone()` which defaults to
`settings.TIME_ZONE` unless you've defined a middleware that overrides it.

> The ideal behaviour (I believe) would be localizing the timezones in the
browser to the user's own time zone, and submitting back to the app using
TZ-aware timestamp strings.

That's the pattern we use for translations based off the `Accept-Language`
header.

> t's possible to pull the TZ unambiguously from a modern browser:
https://developer.mozilla.org/en-

US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/resolvedOptions#Browser_compatibility#Description.

The main issue I see here is that we'd have to figure out a way to send
this data to the server. Maybe at admin login?
[https://github.com/charettes/django-sundial Another pattern is to allow
users to define their own timezone through the admin using a field defined
on their user model] or to base it off geoip.

As Tim said this should be discussed on developer mailing list from now on
but I believe Django should definitively make a better job at providing
batteries to deal with timezone localization.

--
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/069.1c6d0208a231cc3bb6769a133792297e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29775: custom url converters are not picked up on reverse when part of included patterns with namespace

2018-10-03 Thread Django

#29775: custom url converters are not picked up on reverse when part of included
patterns with namespace
-+-
 Reporter:  Eric Brandwein   |Owner:  Eric
 |  Brandwein
 Type:  Bug  |   Status:  assigned
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  converter,   | Triage Stage:  Accepted
  namespace, reverse, include|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/10475 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/071.450ff24f1ffd5441555afdaef00949cf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28034: Update the contributing tutorial to use a more recent patch

2018-10-03 Thread Django

#28034: Update the contributing tutorial to use a more recent patch
-+-
 Reporter:  Mateusz Jankowski|Owner:  Joe
 Type:   |  Krzystan
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"18e4ade79ef145401b899ab539322c95d2a64266" 18e4ade7]:
 {{{
 #!CommitTicketReference repository=""
 revision="18e4ade79ef145401b899ab539322c95d2a64266"
 Fixed #28034 -- Updated the contributing tutorial to use an imaginary
 ticket.
 }}}

-- 
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/070.37a7f2a53910a8de4de9350785b15389%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28034: Update the contributing tutorial to use a more recent patch

2018-10-03 Thread Django

#28034: Update the contributing tutorial to use a more recent patch
-+-
 Reporter:  Mateusz Jankowski|Owner:  Joe
 Type:   |  Krzystan
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"173e242d715da1eedce2540f8531b9c446177a16" 173e242d]:
 {{{
 #!CommitTicketReference repository=""
 revision="173e242d715da1eedce2540f8531b9c446177a16"
 [2.1.x] Fixed #28034 -- Updated the contributing tutorial to use an
 imaginary ticket.

 Backport of 18e4ade79ef145401b899ab539322c95d2a64266 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/070.612689eccd09dae5ef6e9d70f4826e3c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29775: custom url converters are not picked up on reverse when part of included patterns with namespace

2018-10-03 Thread Django

#29775: custom url converters are not picked up on reverse when part of included
patterns with namespace
-+-
 Reporter:  Eric Brandwein   |Owner:  Eric
 |  Brandwein
 Type:  Bug  |   Status:  assigned
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  converter,   | Triage Stage:  Accepted
  namespace, reverse, include|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Eric Brandwein):

 * owner:  nobody => Eric Brandwein
 * status:  new => assigned


-- 
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/071.811179279eb940ab4c9c20de5c8cfb99%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29822: Timezone-aware widget for admin site

2018-10-03 Thread Django

#29822: Timezone-aware widget for admin site
---+-
 Reporter:  Paul Tiplady   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Someday/Maybe
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 => Someday/Maybe


Comment:

 It would be better to make your proposal on the DevelopersMailingList
 where it'll reach a wider audience.

-- 
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/069.1292b00e2c1f5e37fa81684537d81dec%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29822: Timezone-aware widget for admin site

2018-10-03 Thread Django

#29822: Timezone-aware widget for admin site
-+
Reporter: Paul Tiplady | Owner: nobody
Type: New feature| Status: new
Component: contrib.admin |Version: 2.1
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 |
-+
Timezone handling in the Django admin is quite confusing for users when
the users are in multiple timezones, because everything in the admin site
operates in the server's time.

Assuming USE_TZ=True, TIME_ZONE='UTC', USE_I18N, USE_L10N, when viewing a
datetime field, users see the UTC time, with a note below saying "Note:
You are 7 hours behind server time". This is better than nothing, but with
a modern browser I believe it's possible to improve the situation.

The ideal behaviour (I believe) would be localizing the timezones in the
browser to the user's own time zone, and submitting back to the app using
TZ-aware timestamp strings. It's possible to pull the TZ unambiguously
from a modern browser: https://developer.mozilla.org/en-

US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/resolvedOptions#Browser_compatibility#Description.

`Intl.DateTimeFormat().resolvedOptions().timeZone`

Would this approach be acceptable? It seems that we'd want to default to
the normal behaviour, and perhaps have this as config on the AdminSite
object (since we want a way to enable this globally for sites that wish to
use this feature).

--
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/054.e902bbd2ed7cb32441f0e97011ec0eb0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29820: Remove unused, undocumented, and unnecessary dummy template backend

2018-10-03 Thread Django

Comment (by Aymeric Augustin):

I added the dummy backend for two reasons:

1. ensuring consistency with other pluggable backends, as explained by
Adam; if we're going to remove it, we should also remove other dummy
backends;
2. providing a good starting point for people wanting to understand how
template backends work; of course it's hard to say if it actually helped
contributors.

In addition, the dummy backend made it possible to test multiple template
engines without external dependencies — when we were still trying to keep
a good chunk of Django functionality without dependencies. I think that
argument has weakened since then.

I'm not seeing a lot of value in removing this bit of code, but if there's
a strong desire to ship 42 fewer low-maintenance SLoCs, why not, I'm not
married to this 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/067.68062b11865d91b1a55a1684c73c2cac%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29819: ManyToManyField needs "through" argument (and its link table) when working with a legacyDB

2018-10-03 Thread Django

#29819: ManyToManyField needs "through" argument (and its link table) when 
working
with a legacyDB
-+-
 Reporter:  Elaci0   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  ManyToManyField, | Triage Stage:
  legacyDB, "through"|  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:

 I'll close it as "needsinfo" for now, but you can reopen if you can
 explain why Django is at fault. Thanks!

-- 
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/064.39117ace0b3ca1b48fc5cbc5866dc545%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29819: ManyToManyField needs "through" argument (and its link table) when working with a legacyDB

2018-10-03 Thread Django

Comment (by Elaci0):

Replying to [comment:3 Tim Graham]:
> I didn't realize that the many to many relation works except for
`--fake-initial`. Maybe there's some bug there. Can you

[https://github.com/django/django/blob/bdae19cf6395d6bfee80864d9e87c4aec241eceb/django/db/migrations/executor.py#L291-L369
debug it] to figure out the reason?

sure, but I'm quite busy now to try to build my first little site with
Django and I'm slow to understand things...
Does this ticket expires or should I open a new one later?

--
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/064.af91b067f0deea72152332c23c008b30%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29821: Oracle Native JSON Field

2018-10-03 Thread Django

I've provided a reference implementation [here
https://github.com/Exscientia/oracle-json-field] and made it available via
[pip https://pypi.org/project/oracle-json-field/]. It is based heavily on
the Postgres implementation.

Note: In the reference implementation I have added a ```.filter_json()```
method whose only purpose is to ensure that table names are aliased - an
Oracle requirement for Json queries. If there is a cleaner way to force
table names to be aliased then this can be removed, and give 100% feature
parity with Django's core query API i.e. just use
```MyModel.objects.filter(...)```

Is this something that you would consider adding to the official Django
project. If so please feel free to re-use any of the code from the
reference implementation. Additionally I would be happy to create a pull-
request if it makes integration easier.

--
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/054.75791d737e7e4e7763f8e3c15a48c9aa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29820: Remove unused, undocumented, and unnecessary dummy template backend

2018-10-03 Thread Django

#29820: Remove unused, undocumented, and unnecessary dummy template backend
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  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
-+-

Comment (by Adam (Chainz) Johnson):

 We have dummy backends for all the other swappable backends such as cache,
 db, and mail. But I guess since this was only in the DEP, and there don't
 seem to be many alternative template backends being made, it's not
 providing much value and removing it is simpler.

-- 
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.75aa3f150643cfc2586879e6b17e1572%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29819: ManyToManyField needs "through" argument (and its link table) when working with a legacyDB

2018-10-03 Thread Django

#29819: ManyToManyField needs "through" argument (and its link table) when 
working
with a legacyDB
-+-
 Reporter:  Elaci0   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  ManyToManyField, | Triage Stage:
  legacyDB, "through"|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I didn't realize that the many to many relation works except for `--fake-
 initial`. Maybe there's some bug there. Can you
 
[https://github.com/django/django/blob/bdae19cf6395d6bfee80864d9e87c4aec241eceb/django/db/migrations/executor.py#L291-L369
 debug it] to figure out the reason?

-- 
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/064.f9d2f9d196c04c9be38f15d1fe3d25e0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29819: ManyToManyField needs "through" argument (and its link table) when working with a legacyDB

2018-10-03 Thread Django

#29819: ManyToManyField needs "through" argument (and its link table) when 
working
with a legacyDB
-+-
 Reporter:  Elaci0   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  ManyToManyField, | Triage Stage:
  legacyDB, "through"|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Elaci0):

 Replying to [comment:1 Tim Graham]:
 > I think it's natural to expect that if your table names don't match your
 models, then Django won't work as expected. Did I miss the point of your
 suggestion?

 It's natural when you know how Django works :-)
 I discovered that after some days of debugging the Django's code: I needed
 to translate my simple many-to-many relationship for my legacyDB, I read
 the docs and found that  ManyToManyField  was good and enough but instead
 my   fake-initial  migration always failed, until I created that
 'junction-table' model which I had to use with the 'through' declaration.

 Out of curiosity I tried with the model.py suggested at the
 ManyToManyField section into the Django's docs (Person/Group/Membership),
 it worked flawless starting from the scratch.
 Later I converted this model to a schema-DB (so I pre-created the
 tables/columns on a DB) , run the fake-initial migration and it worked
 again until I removed the 'through' declaration, then complained with the
 "already existing table"  error. Put again the 'through' declaration, it
 worked. I tried with other working examples on the internet with same
 results

 So going back to your kind replay, I can agree that it could be natural to
 expect this, but the documentation should warn me that **"fake-initial" +
 ManyToManyField - through**  doesn't work when a legacyDB is used. Or
 perhaps something is wrong into the migrations process during the fake-
 initial ?

-- 
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/064.7e4b87ce419c66fbd6450822911069a7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29820: Remove unused, undocumented, and unnecessary dummy template backend

2018-10-03 Thread Django

#29820: Remove unused, undocumented, and unnecessary dummy template backend
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  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
-+-

Comment (by Jon Dufresne):

 [https://github.com/django/deps/pull/49 Multiple Template Engines DEP 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.6105c2498de8dc219f5fcb5e1b0d947d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29820: Remove unused, undocumented, and unnecessary dummy template backend

2018-10-03 Thread Django

#29820: Remove unused, undocumented, and unnecessary dummy template backend
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  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
-+-

Comment (by Tim Graham):

 It was added as part of
 [https://github.com/django/deps/blob/master/final/0182-multiple-template-
 engines.rst#dummy-backend Multiple Template Engines] project. I guess you
 would need to propose revising the DEP before making a proposal 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/067.3fe6fa8e85f7e269c837377a917f543a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29818: ValueError when parsing querydata to autofill a Django admin form

2018-10-03 Thread Django

#29818: ValueError when parsing querydata to autofill a Django admin form
---+--
 Reporter:  NastuzziSamy   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords:  django admin   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Herbert Fortes):

 * cc: Herbert Fortes (added)


-- 
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/070.394070ca0968632d6e46c7c5b1a7f2a2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29818: ValueError when parsing querydata to autofill a Django admin form

2018-10-03 Thread Django

#29818: ValueError when parsing querydata to autofill a Django admin form
---+--
 Reporter:  NastuzziSamy   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords:  django admin   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Herbert Fortes):

 I also tried to reproduce.

 [03/Oct/2018 13:36:58] "POST
 /admin/core/course/add/?_to_field=id&_popup=1=plsbreak HTTP/1.1" 200
 10098

 I do not sure if it is a valid try but no crash 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/070.63e758f9cf0a27175492a100f8717533%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29820: Remove unused, undocumented, and unnecessary dummy template backend

2018-10-03 Thread Django

#29820: Remove unused, undocumented, and unnecessary dummy template backend
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  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/10474 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.c52f1ba16a916b0411f9422bdc424e07%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29820: Remove unused, undocumented, and unnecessary dummy template backend

2018-10-03 Thread Django

#29820: Remove unused, undocumented, and unnecessary dummy template backend
+
   Reporter:  Jon Dufresne  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Template system   |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 |
+
 The dummy backend is undocumented.

 The dummy backend is unused except for testing multiple backend scenarios.
 For those testing purposes, can use the Jinja2 template engine as a 2nd
 engine.

 Further, the dummy backend isn't providing any other purpose such that the
 Django or Jinja2 engine wouldn't work as a replacement.

-- 
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.c1c13ca78915f5c59becf1d6e391a092%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29818: ValueError when parsing querydata to autofill a Django admin form

2018-10-03 Thread Django

#29818: ValueError when parsing querydata to autofill a Django admin form
---+--
 Reporter:  NastuzziSamy   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords:  django admin   | 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):

 * easy:  1 => 0


Comment:

 Can you give more specific steps to reproduce? At first glance, it seems
 like the problem is putting a string in a foreign key field but I tried
 with the URL `/admin/polls/choice/add/?question=xxx` (from the tutorial)
 and don't see a crash.

-- 
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/070.730d79dc3bf984ee0d9b13f3e63ce937%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27795: Audit force_text invocations

2018-10-03 Thread Django

#27795: Audit force_text invocations
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 Type:   |  Paroz
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  master
 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
-+-

Comment (by Carlton Gibson ):

 In [changeset:"5045f8af853c29830db5c028ad299663d96af82d" 5045f8af]:
 {{{
 #!CommitTicketReference repository=""
 revision="5045f8af853c29830db5c028ad299663d96af82d"
 Revert "[2.1.x] Refs #27795 -- Removed force_bytes() usage in sessions."

 This reverts commit f3f31b0fc26f772b198c9683a427f2f7fe208c37.
 }}}

-- 
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.4df95135cdedc8d540f5ac75f348a15b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27795: Audit force_text invocations

2018-10-03 Thread Django

#27795: Audit force_text invocations
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 Type:   |  Paroz
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  master
 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
-+-

Comment (by Carlton Gibson ):

 In [changeset:"54eedddb5084fb572516ad4d7266e13e290c3c8d" 54eedddb]:
 {{{
 #!CommitTicketReference repository=""
 revision="54eedddb5084fb572516ad4d7266e13e290c3c8d"
 Revert "[2.1.x] Refs #27795 -- Removed force_bytes() usage in MySQL
 backend."

 This reverts commit a47dd99cc6883fe3e35895e8c5d4bb53996bd184.
 }}}

-- 
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.5aed2bd43017a45f7759a02fa8801b6b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29819: ManyToManyField needs "through" argument (and its link table) when working with a legacyDB

2018-10-03 Thread Django

#29819: ManyToManyField needs "through" argument (and its link table) when 
working
with a legacyDB
-+-
 Reporter:  Elaci0   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  ManyToManyField, | Triage Stage:
  legacyDB, "through"|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I think it's natural to expect that if your table names don't match your
 models, then Django won't work as expected. Did I miss the point of your
 suggestion?

-- 
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/064.cf0a0490d4ad238833d811363f4d0a8d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29819: ManyToManyField needs "through" argument (and its link table) when working with a legacyDB

2018-10-03 Thread Django

#29819: ManyToManyField needs "through" argument (and its link table) when 
working
with a legacyDB
-+-
   Reporter:  Elaci0 |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  2.1
  Documentation  |   Keywords:  ManyToManyField,
   Severity:  Normal |  legacyDB, "through"
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Still working with an existing legacy database integration (I will stop, I
 promise) and the "--fake-initial" switch

 it seems to me that when I use a ''ManyToManyField '' inside a model I
 must include also a link-table  using the **''"through"''** argument,
 otherwise Django complies with an "already existing table" error. This
 happen only with an existing DB, if I start from the scratch no problem at
 all because all tables are created on-the-fly

 (I guess that without any "through" argument the migration process creates
 such join-table which name doesn't match any of the existing table)

 Maybe it's not a problem but I think that perhaps it should be stated into
 documentation of  "inspectDB"  ManytoManyField
 [https://docs.djangoproject.com/en/2.1/topics/db/models/#extra-fields-on-
 many-to-many-relationships]"

-- 
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/049.fda22202e938750580e55cd85705cf83%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29815: InlineModelAdmin ignores media files from widgets included in the used form

2018-10-03 Thread Django

#29815: InlineModelAdmin ignores media files from widgets included in the used
form
---+--
Reporter: Sławomir Domagała |Owner: nobody
Type: Bug| Status: closed
Component: contrib.admin | Version: 2.1
Severity: Normal | Resolution: invalid
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 Sławomir Domagała):

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

Comment:

Replying to [comment:3 Tim Graham]:
> Can you debug the issue to find where the problem is? It looks to me
like

[https://github.com/django/django/blob/bf8b625a3bb6c2cb5f1be3713f3bafe2c1050366/django/contrib/admin/options.py#L1597-L1599
media from inline formsets] is added correctly.

Sorry, I was incorrectly using css media (I was trying to assing array to
css media instead dictionary) and it was failing silently. I thought that
the bug is

https://github.com/django/django/blob/bf8b625a3bb6c2cb5f1be3713f3bafe2c1050366/django/contrib/admin/options.py#L1990

--
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.5066d0cb8167875a642bc3efa70e4bbc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29818: ValueError when parsing querydata to autofill a Django admin form

2018-10-03 Thread Django

#29818: ValueError when parsing querydata to autofill a Django admin form
-+--
   Reporter:  NastuzziSamy   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  2.1
   Severity:  Normal |   Keywords:  django admin
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+--
 When giving a pure string instead of an expected integer
 (ex:
 http://localhost:8002/admin/core/zone/add/?_to_field=id&_popup=1=plsbreak
 with event = 'plsbreak') , Django admin breaks

 "Error during template rendering

 In template /usr/local/lib/python3.6/site-
 packages/django/contrib/admin/templates/admin/includes/fieldset.html,
 error at line 19"

-- 
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/055.8332b62aff22570f447e8d67c8f63c71%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27795: Audit force_text invocations

2018-10-03 Thread Django

#27795: Audit force_text invocations
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 Type:   |  Paroz
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  master
 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
-+-

Comment (by Carlton Gibson ):

 In [changeset:"f3f31b0fc26f772b198c9683a427f2f7fe208c37" f3f31b0]:
 {{{
 #!CommitTicketReference repository=""
 revision="f3f31b0fc26f772b198c9683a427f2f7fe208c37"
 [2.1.x] Refs #27795 -- Removed force_bytes() usage in sessions.

 SessionBase.decode() is the inverse operation to SessionBase.encode().
 As SessionBase.encode() always returns a string, SessionBase.decode()
 should always be passed a string argument. Fixed the file backend, which
 was the only backend still passing a bytestring.

 Backport of bdae19cf6395d6bfee80864d9e87c4aec241eceb 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/065.a120d6f84e82bb3af1e9d26617974e52%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27795: Audit force_text invocations

2018-10-03 Thread Django

#27795: Audit force_text invocations
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 Type:   |  Paroz
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  master
 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
-+-

Comment (by Carlton Gibson ):

 In [changeset:"bdae19cf6395d6bfee80864d9e87c4aec241eceb" bdae19cf]:
 {{{
 #!CommitTicketReference repository=""
 revision="bdae19cf6395d6bfee80864d9e87c4aec241eceb"
 Refs #27795 -- Removed force_bytes() usage in sessions.

 SessionBase.decode() is the inverse operation to SessionBase.encode().
 As SessionBase.encode() always returns a string, SessionBase.decode()
 should always be passed a string argument. Fixed the file backend, which
 was the only backend still passing a bytestring.
 }}}

-- 
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.f153350d1f6522401b4a6808b382fbb4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29725: Inefficient SQL generated when counting a ManyToMany

2018-10-03 Thread Django

#29725: Inefficient SQL generated when counting a ManyToMany
-+-
 Reporter:  Gavin Wahl   |Owner:  oliver
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by oliver):

 * needs_better_patch:  1 => 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/067.a2ce28b7747b9ea3a0068d13303e3150%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27795: Audit force_text invocations

2018-10-03 Thread Django

#27795: Audit force_text invocations
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 Type:   |  Paroz
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  master
 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
-+-

Comment (by Carlton Gibson ):

 In [changeset:"a47dd99cc6883fe3e35895e8c5d4bb53996bd184" a47dd99]:
 {{{
 #!CommitTicketReference repository=""
 revision="a47dd99cc6883fe3e35895e8c5d4bb53996bd184"
 [2.1.x] Refs #27795 -- Removed force_bytes() usage in MySQL backend.

 The mysqlclient cursor attribute `_last_executed` is always stored as
 bytes. Decode it.

 TextField values are already type str. No need to decode.

 Backport of efd8a82e268a82b3ad0be77bd5b4548c30bcb4d7 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/065.2f5e9b2a96e5ef700e57a38f93d86afc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27795: Audit force_text invocations

2018-10-03 Thread Django

#27795: Audit force_text invocations
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 Type:   |  Paroz
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  master
 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
-+-

Comment (by Carlton Gibson ):

 In [changeset:"efd8a82e268a82b3ad0be77bd5b4548c30bcb4d7" efd8a82e]:
 {{{
 #!CommitTicketReference repository=""
 revision="efd8a82e268a82b3ad0be77bd5b4548c30bcb4d7"
 Refs #27795 -- Removed force_bytes() usage in MySQL backend.

 The mysqlclient cursor attribute `_last_executed` is always stored as
 bytes. Decode it.

 TextField values are already type str. No need to decode.
 }}}

-- 
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.2f0b3ed6e26ac4135fef3323fea3c06f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29817: Deprecate FILE_CHARSET setting

2018-10-03 Thread Django

#29817: Deprecate FILE_CHARSET setting
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 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 Carlton Gibson):

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


Comment:

 Initial feedback on the thread is that this probably **IS** needed. I'm
 going to close as `wontfix` on that basis, but **happy to reopen** if the
 discussion develops there.

-- 
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.8aca144850eb4a09144775b30769fe59%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29817: Deprecate FILE_CHARSET setting

2018-10-03 Thread Django

#29817: Deprecate FILE_CHARSET setting
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  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
-+-

Comment (by Carlton Gibson):

 This would be nice. Django-developers thread asking for input:
 https://groups.google.com/d/topic/django-developers/7bZbYVV6hg4/discussion
 — lets see if there are any issues raised.

-- 
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.62bdd0631d8d5bea6a61019b5c6da284%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29667: path converters don't handle spaces well.

2018-10-03 Thread Django

#29667: path converters don't handle spaces well.
-+-
 Reporter:  Keryn Knight |Owner:  Jeff
 Type:  Bug  |   Status:  assigned
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  converters path  | Triage Stage:  Accepted
  _route_to_regex|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Vishvajit Pathak):

 * cc: Vishvajit Pathak (added)


-- 
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.807409beba1e3a435eea7cddc52f7b7a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22270: Explain permissions on proxy models

2018-10-03 Thread Django

#22270: Explain permissions on proxy models
-+-
 Reporter:  Gert Steyn   |Owner:  Arthur
 Type:   |  Rio
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  proxy models | Triage Stage:  Accepted
  permissions|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Arthur Rio):

 * owner:  nobody => Arthur Rio
 * status:  new => assigned
 * has_patch:  0 => 1


-- 
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.45001a01d369035abb5d8599d12ea084%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

39 matches

Mail list logo