Re: [Django] #25897: Managers defined on non-abstract base classes are in fact inherited by child classes.

[Django]

#25897: Managers defined on non-abstract base classes are in fact inherited by
child classes.
-+-
 Reporter:  poleha   |Owner:  poleha
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  manager, | Triage Stage:  Accepted
  inheritance|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by poleha):

 Replying to [comment:4 timgraham]:
 > Is there any indication this is a regression such that the fix should be
 backported or should we instead correct older versions of the
 documentation?
 I found mentioning this:
 >Managers defined on non-abstract base classes are not inherited by child
 classes
 in documentation since version 1.4:

 https://docs.djangoproject.com/en/1.4/topics/db/managers/#custom-managers-
 and-model-inheritance

 And this bug exists in all versions since 1.4.

 I think that fixing this bug in current version without fixing the
 documentation would be enough. But I am ready to provide path for all
 versions since 1.4. And I don't think that fixing old versions of
 documentation would be correct in this case.

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

Re: [Django] #25882: Deletion on ForeignKey raises TypeError

[Django]

#25882: Deletion on ForeignKey raises TypeError
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   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 gerricom):

 Replying to [comment:3 raphaelmerx]:
 > In your example, `ReaderHasMedia` does not have a FK to `Catalog`, so
 `ReaderHasMedia.objects.filter(catalog=Catalog.objects.get(pk=123)).delete()`
 isn't valid.

 Ah! Sorry - I meant:
 
`ReaderHasMedia.objects.filter(reader__catalog=Catalog.objects.get(pk=123)).delete()`

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

Re: [Django] #25905: Unsafe usage of urljoin() within FileStorageSystem

[Django]

#25905: Unsafe usage of urljoin() within FileStorageSystem
---+--
 Reporter:  free-Runner|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Core (Other)   |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords:  file, storage  | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by free-Runner):

 * cc: aman.ali@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> It may be possible to override the hostname when displaying a link to a
> static/media file with an attacker-controlled filename. The url() method
> in FileStorageSystem uses urljoin(base,url) to combine the base_url
> (typically STATIC_URL or MEDIA_URL) to the filename. The urljoin function
> has an edge case where if the url parameter starts with "//", the
> base_url value is overwritten. Thus, if an attacker can set the name
> variable of a FileStorageSystem instance to "//www.evil.com", any url
> method call on that instance will return an external link pointing to the
> attacker's site. Creating a file of the name "\\www.evil.com" is also
> acceptable as the filepath_to_uri function (that is called on the
> filename before the urljoin call) converts all backslashes to forward-
> slashes. The latter example works better as it is a completely valid
> Linux file name.
>
> This issue can't be exploited using framework-provided upload techniques
> (FileFields, ImageFields, etc) as they properly escape the filename.
> However, an application may directly initialize a FileStorageSystem using
> user-controlled data or allow users to modify the name attribute of an
> existing FileStorageSystem instance. In such cases, an attacker could
> convert the expected relative paths into absolute external URLs.
>
> This issue can simply be patched by modifying the line found
> here[https://github.com/django/django/blob/master/django/core/files/storage.py#L302]
> as follows:
>
> return urljoin(self.base_url,
> filepath_to_uri(get_valid_filename(name)))
>
> This change filters the filename provided through the get_valid_filename
> function from django.utils.text. This function does a sufficient of
> eliminating the ability to override the base_url.
>
> Note: This issue was initially disclosed to the Django security team and
> was decided not to be treated as a security issue, but instead a bug.

New description:

 It may be possible to override the hostname when displaying a link to a
 static/media file with an attacker-controlled filename. The url() method
 in FileStorageSystem uses urljoin(base,url) to combine the base_url
 (typically STATIC_URL or MEDIA_URL) to the filename. The urljoin function
 has an edge case where if the url parameter starts with "//", the base_url
 value is overwritten. Thus, if an attacker can set the name variable of a
 FileStorageSystem instance to "//www.evil.com", any url method call on
 that instance will return an external link pointing to the attacker's
 site. Creating a file of the name "\\www.evil.com" is also acceptable as
 the filepath_to_uri function (that is called on the filename before the
 urljoin call) converts all backslashes to forward-slashes. The latter
 example works better as it is a completely valid Linux file name.

 This issue can't be exploited using framework-provided upload techniques
 (FileFields, ImageFields, etc) as they properly escape the filename.
 However, an application may directly initialize a FileStorageSystem using
 user-controlled data or allow users to modify the name attribute of an
 existing FileStorageSystem instance. In such cases, an attacker could
 convert the expected relative paths into absolute external URLs.

 This issue can simply be patched by modifying the line found
 
here[https://github.com/django/django/blob/master/django/core/files/storage.py#L302]
 as follows:

 return urljoin(self.base_url,
 filepath_to_uri(get_valid_filename(name)))

 This change filters the filename provided through the get_valid_filename
 function from django.utils.text. This function does a sufficient job of
 eliminating the ability to override the base_url.

 Note: This issue was initially disclosed to the Django security team and
 was decided not to be treated as a security issue, but instead a bug.

--

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

[Django] #25905: Unsafe usage of urljoin() within FileStorageSystem

[Django]

#25905: Unsafe usage of urljoin() within FileStorageSystem
--+---
 Reporter:  free-Runner   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Core (Other)  |Version:  1.9
 Severity:  Normal|   Keywords:  file, storage
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+---
 It may be possible to override the hostname when displaying a link to a
 static/media file with an attacker-controlled filename. The url() method
 in FileStorageSystem uses urljoin(base,url) to combine the base_url
 (typically STATIC_URL or MEDIA_URL) to the filename. The urljoin function
 has an edge case where if the url parameter starts with "//", the base_url
 value is overwritten. Thus, if an attacker can set the name variable of a
 FileStorageSystem instance to "//www.evil.com", any url method call on
 that instance will return an external link pointing to the attacker's
 site. Creating a file of the name "\\www.evil.com" is also acceptable as
 the filepath_to_uri function (that is called on the filename before the
 urljoin call) converts all backslashes to forward-slashes. The latter
 example works better as it is a completely valid Linux file name.

 This issue can't be exploited using framework-provided upload techniques
 (FileFields, ImageFields, etc) as they properly escape the filename.
 However, an application may directly initialize a FileStorageSystem using
 user-controlled data or allow users to modify the name attribute of an
 existing FileStorageSystem instance. In such cases, an attacker could
 convert the expected relative paths into absolute external URLs.

 This issue can simply be patched by modifying the line found
 
here[https://github.com/django/django/blob/master/django/core/files/storage.py#L302]
 as follows:

 return urljoin(self.base_url,
 filepath_to_uri(get_valid_filename(name)))

 This change filters the filename provided through the get_valid_filename
 function from django.utils.text. This function does a sufficient of
 eliminating the ability to override the base_url.

 Note: This issue was initially disclosed to the Django security team and
 was decided not to be treated as a security issue, but instead a bug.

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

Re: [Django] #25882: Deletion on ForeignKey raises TypeError

[Django]

#25882: Deletion on ForeignKey raises TypeError
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   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 raphaelmerx):

 * cc: raphael.merx@… (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/066.20ccb4bde79adc14824a745e22b29f6d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25882: Deletion on ForeignKey raises TypeError

[Django]

#25882: Deletion on ForeignKey raises TypeError
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   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 raphaelmerx):

 In your example, `ReaderHasMedia` does not have a FK to `Catalog`, so
 `ReaderHasMedia.objects.filter(catalog=Catalog.objects.get(pk=123)).delete()`
 isn't valid.

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

Re: [Django] #25896: SeparateDatabaseAndState.database_backwards() applies state incorrectly

[Django]

#25896: SeparateDatabaseAndState.database_backwards() applies state incorrectly
+
 Reporter:  amosonn |Owner:  amosonn
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by Shai Berger ):

 In [changeset:"02c049ab1ab5273d4212890635f94cc7eac7b158" 02c049ab]:
 {{{
 #!CommitTicketReference repository=""
 revision="02c049ab1ab5273d4212890635f94cc7eac7b158"
 [1.8.x] Refs #25896 -- Fixed migration test failure on Oracle

 The test creates and deletes a model in the same migration, and the model
 had an AutoField. On Oracle, AutoField's are set up using deferred SQL,
 which
 in this case was trying to modify a table after it had dbeen removed.

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

Re: [Django] #25896: SeparateDatabaseAndState.database_backwards() applies state incorrectly

[Django]

#25896: SeparateDatabaseAndState.database_backwards() applies state incorrectly
+
 Reporter:  amosonn |Owner:  amosonn
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by Shai Berger ):

 In [changeset:"f1964bc7e2a1be675ed19ab302362311df67e3eb" f1964bc]:
 {{{
 #!CommitTicketReference repository=""
 revision="f1964bc7e2a1be675ed19ab302362311df67e3eb"
 [1.9.x] Refs #25896 -- Fixed migration test failure on Oracle

 The test creates and deletes a model in the same migration, and the model
 had an AutoField. On Oracle, AutoField's are set up using deferred SQL,
 which
 in this case was trying to modify a table after it had dbeen removed.

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

Re: [Django] #25896: SeparateDatabaseAndState.database_backwards() applies state incorrectly

[Django]

#25896: SeparateDatabaseAndState.database_backwards() applies state incorrectly
+
 Reporter:  amosonn |Owner:  amosonn
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by Shai Berger ):

 In [changeset:"c8b3fbe21b09937b57e96dbddcc71946da246a2f" c8b3fbe2]:
 {{{
 #!CommitTicketReference repository=""
 revision="c8b3fbe21b09937b57e96dbddcc71946da246a2f"
 Refs #25896 -- Fixed migration test failure on Oracle

 The test creates and deletes a model in the same migration, and the model
 had an AutoField. On Oracle, AutoField's are set up using deferred SQL,
 which
 in this case was trying to modify a table after it had dbeen removed.
 }}}

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

Re: [Django] #25903: ModelAdmin popups won't close

[Django]

#25903: ModelAdmin popups won't close
--+--
 Reporter:  Crzel |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.admin |  Version:  1.9
 Severity:  Normal|   Resolution:  worksforme
 Keywords:  modeladmin popup  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by timgraham):

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


Comment:

 Okay, it works for me -- so I'll close this for now. If you can reproduce
 without those other apps, please reopen.

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

Re: [Django] #25899: manage.py tests requires database creation privileges

[Django]

#25899: manage.py tests requires database creation privileges
---+--
 Reporter:  JorisBenschop  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  1.9
 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
---+--

Comment (by shaib):

 There are `TEST` parameters for this -- Everything from
 [https://docs.djangoproject.com/en/1.8/ref/settings/#create-db CREATE_DB]
 onwards is essentially serving the need you raise here. Note that settings
 are much more appropriate than command arguments for this use-case.

 Can you offer a documentation change that will make these settings easier
 to find?

 (`NAME`, specifically, has a very different meaning on Oracle -- it
 selects the service to connect to, rather than a database on that service
 like it does for other backends.)

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

Re: [Django] #25872: Title attribute for related widget links lacks escaping (and breaks html)

[Django]

#25872: Title attribute for related widget links lacks escaping (and breaks 
html)
-+
 Reporter:  a1tus|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.8
 Severity:  Release blocker  |   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 a1tus):

 Ok! I'll try to inspect admin templates tomorrow to find out if there some
 other places that need escaping.

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

Re: [Django] #25903: ModelAdmin popups won't close

[Django]

#25903: ModelAdmin popups won't close
--+--
 Reporter:  Crzel |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  modeladmin popup  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by Crzel):

 Third Party applications are django object actions, django rest framework
 and django wpadmin.
 http://www.django-rest-framework.org/
 https://github.com/barszczmm/django-wpadmin
 https://github.com/crccheck/django-object-actions

 But the likely culprit is django wpadmin, which I forked long ago, and
 used with Django 1.7.
 After upgrading to Django 1.9, Django WpAdmin had some issues, but I
 thought I fixed everything.
 If the error is not replicable by anyone, this might be the cause.

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

Re: [Django] #25903: ModelAdmin popups won't close

[Django]

#25903: ModelAdmin popups won't close
--+--
 Reporter:  Crzel |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  modeladmin popup  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by timgraham):

 Are you using any third-party apps that might be interfering?

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

Re: [Django] #25903: ModelAdmin popups won't close

[Django]

#25903: ModelAdmin popups won't close
--+--
 Reporter:  Crzel |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  modeladmin popup  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by Crzel):

 Sorry for not doing this before.
 In the "Popup Closing..." page there is a JS error.

 Chrome :
 Uncaught TypeError: Cannot read property 'dismissAddRelatedObjectPopup' of
 null

 Firefox :
 TypeError: opener is null

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

[Django] #25904: --fake-initial does not work for ManyToMany with through Model

[Django]

#25904: --fake-initial does not work for ManyToMany with through Model
+
 Reporter:  maciej-pawlisz  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.9
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 I came across this issue when migrating from django 1.6.11 and south. When
 model has ManyToMany field then automatic initial migration contains
 `AddField` operation for this field, which of course is not present in
 database, so django thinks that it cannot fake this migration.

 How to reproduce:
 `fake_through.models.py`:
 {{{
 from django.db import models
 class A(models.Model):
 b = models.ManyToManyField('B', through="C")

 class B(models.Model):
 pass

 class C(models.Model):
 a = models.ForeignKey('A')
 b = models.ForeignKey('B')
 }}}
 commands:
 {{{
 python manage.py makemigrations fake_through
 python manage.py migrate fake_through
 python manage.py migrate fake_through zero --fake
 python manage.py migrate fake_through --fake-initial
 django.db.utils.OperationalError: table "fake_through_a" already exists
 }}}

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

Re: [Django] #25903: ModelAdmin popups won't close (was: ModelAdmin popups wont'close)

[Django]

#25903: ModelAdmin popups won't close
--+--
 Reporter:  Crzel |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  modeladmin popup  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by timgraham):

 * type:  Uncategorized => Bug


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

Re: [Django] #25903: ModelAdmin popups wont'close

[Django]

#25903: ModelAdmin popups wont'close
--+--
 Reporter:  Crzel |Owner:  nobody
 Type:  Uncategorized |   Status:  new
Component:  contrib.admin |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  modeladmin popup  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by timgraham):

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


Comment:

 Possibly you have some cached JavaScript in your browser? Could you try
 clearing your cache and also check the JavaScript console of your browser
 for any errors?

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

Re: [Django] #25878: APPEND_SLASH doesn't work with DEBUG=False when template/404.html is erroneous

[Django]

#25878: APPEND_SLASH doesn't work with DEBUG=False when template/404.html is
erroneous
---+--
 Reporter:  kuna   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords:  slash,debug| Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

 * cc: electricjay (added)


Comment:

 The change is bisected to 434d309ef6dbecbfd2b322d3a1da78aa5cb05fa8
 (#24720). As you said, I think something doesn't seem quite right if we
 have to render the 404 page before redirecting. Jay, as the author of the
 original patch could you let us know your thoughts?

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

[Django] #25903: ModelAdmin popups wont'close

[Django]

#25903: ModelAdmin popups wont'close
---+--
 Reporter:  Crzel  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  contrib.admin  |Version:  1.9
 Severity:  Normal |   Keywords:  modeladmin popup
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 I am referring to the popups you can use to creare a new record on-the-fly
 while editing an other record.
 After upgrade from Django 1.7 to 1.9 those popups aren't opening a popup
 in the web browser anymore, instead, the page will change, allowing to
 create a new record.
 After saving, a page saying "Closing Popup" will appear, but the page
 won't go back to the original one.

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

Re: [Django] #25872: Title attribute for related widget links lacks escaping (and breaks html)

[Django]

#25872: Title attribute for related widget links lacks escaping (and breaks 
html)
-+
 Reporter:  a1tus|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.8
 Severity:  Release blocker  |   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 claudep):

 I'm not against the `force_escape` solution proposed in the description.
 But we should first audit the current Django code to see if other parts
 would also need it, to be consistent. Could you try that?
 We can then also evaluate if adding some keyword to blocktrans to force
 escaping might make sense.

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

Re: [Django] #25711: The project template's URLconf doesn't follow the docs' convention for include()

[Django]

#25711: The project template's URLconf doesn't follow the docs' convention for
include()
---+
 Reporter:  EvilDMP|Owner:  EvilDMP
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.8
 Severity:  Normal |   Resolution:  fixed
 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 Tim Graham ):

 In [changeset:"2c6624a67397afc0f72a36559b53fb693e473bbc" 2c6624a]:
 {{{
 #!CommitTicketReference repository=""
 revision="2c6624a67397afc0f72a36559b53fb693e473bbc"
 [1.9.x] Fixed #25711 -- Updated the project template's include() example.

 Referencing URLs by dotted path is a stronger convention than
 importing the URLs.

 Backport of 179fbab7e05946b59ec9815d6e9b1901826ed610 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.8069227c8ee2fb2b82ee0a13cf5c26ef%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25711: The project template's URLconf doesn't follow the docs' convention for include()

[Django]

#25711: The project template's URLconf doesn't follow the docs' convention for
include()
---+
 Reporter:  EvilDMP|Owner:  EvilDMP
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.8
 Severity:  Normal |   Resolution:  fixed
 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 Tim Graham ):

 In [changeset:"4211f8c9d1cd543d9c6fe4b789aea7dddf07c44a" 4211f8c9]:
 {{{
 #!CommitTicketReference repository=""
 revision="4211f8c9d1cd543d9c6fe4b789aea7dddf07c44a"
 [1.8.x] Fixed #25711 -- Updated the project template's include() example.

 Referencing URLs by dotted path is a stronger convention than
 importing the URLs.

 Backport of 179fbab7e05946b59ec9815d6e9b1901826ed610 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.0edd9a9b317c4154f9a3ac2bf4e0d03b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25711: The project template's URLconf doesn't follow the docs' convention for include()

[Django]

#25711: The project template's URLconf doesn't follow the docs' convention for
include()
---+
 Reporter:  EvilDMP|Owner:  EvilDMP
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.8
 Severity:  Normal |   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"179fbab7e05946b59ec9815d6e9b1901826ed610" 179fbab7]:
 {{{
 #!CommitTicketReference repository=""
 revision="179fbab7e05946b59ec9815d6e9b1901826ed610"
 Fixed #25711 -- Updated the project template's include() example.

 Referencing URLs by dotted path is a stronger convention than
 importing the URLs.
 }}}

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

Re: [Django] #25896: SeparateDatabaseAndState.database_backwards() applies state incorrectly

[Django]

#25896: SeparateDatabaseAndState.database_backwards() applies state incorrectly
+
 Reporter:  amosonn |Owner:  amosonn
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by Tim Graham ):

 In [changeset:"0772bffd4a2feac3928924a8427f372ab3ec6919" 0772bffd]:
 {{{
 #!CommitTicketReference repository=""
 revision="0772bffd4a2feac3928924a8427f372ab3ec6919"
 [1.8.x] Fixed #25896 -- Fixed state bug in
 SeparateDatabaseAndState.database_backwards().

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

Re: [Django] #25896: SeparateDatabaseAndState.database_backwards() applies state incorrectly

[Django]

#25896: SeparateDatabaseAndState.database_backwards() applies state incorrectly
+
 Reporter:  amosonn |Owner:  amosonn
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by Tim Graham ):

 In [changeset:"f076cf07effe54af8a28f22431c3c76a8af61fc5" f076cf07]:
 {{{
 #!CommitTicketReference repository=""
 revision="f076cf07effe54af8a28f22431c3c76a8af61fc5"
 [1.9.x] Fixed #25896 -- Fixed state bug in
 SeparateDatabaseAndState.database_backwards().

 Backport of 542b7f6c50df18f2aa201cf1de81577c1bee643c 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.158a5a27b38927834629e8881359edbe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25897: Managers defined on non-abstract base classes are in fact inherited by child classes.

[Django]

#25897: Managers defined on non-abstract base classes are in fact inherited by
child classes.
-+-
 Reporter:  poleha   |Owner:  poleha
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  manager, | Triage Stage:  Accepted
  inheritance|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Is there any indication this is a regression such that the fix should be
 backported or should we instead correct older versions of the
 documentation?

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

Re: [Django] #24355: Cannot use Django 1.8a1 with mysql.connector.python (Oracle's official mysql connector.)

[Django]

#24355: Cannot use Django 1.8a1 with mysql.connector.python (Oracle's official
mysql connector.)
-+-
 Reporter:  ubill|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 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 gabn88):

 Thanks a bunch!

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

Re: [Django] #25896: SeparateDatabaseAndState.database_backwards() applies state incorrectly

[Django]

#25896: SeparateDatabaseAndState.database_backwards() applies state incorrectly
+
 Reporter:  amosonn |Owner:  amosonn
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"542b7f6c50df18f2aa201cf1de81577c1bee643c" 542b7f6c]:
 {{{
 #!CommitTicketReference repository=""
 revision="542b7f6c50df18f2aa201cf1de81577c1bee643c"
 Fixed #25896 -- Fixed state bug in
 SeparateDatabaseAndState.database_backwards().
 }}}

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

Re: [Django] #25897: Managers defined on non-abstract base classes are in fact inherited by child classes.

[Django]

#25897: Managers defined on non-abstract base classes are in fact inherited by
child classes.
-+-
 Reporter:  poleha   |Owner:  poleha
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  manager, | Triage Stage:  Accepted
  inheritance|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by sir-sigurd):

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

Re: [Django] #25902: Add system check for project-wide database table name conflicts (was: app names with underscore conflict with many-to-many tables)

[Django]

#25902: Add system check for project-wide database table name conflicts
--+
 Reporter:  amosonn   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (System checks)  |  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
--+
Changes (by timgraham):

 * type:  Uncategorized => New feature
 * component:  Database layer (models, ORM) => Core (System checks)
 * version:  1.9 => master
 * stage:  Unreviewed => Accepted


Comment:

 I guess we might be able to add a system check for these sort of clashes,
 but it might be a non-trivial amount of work for what I assume isn't a
 very common case. Also, such validation would need to account for the
 possibility that a user does want two models to use the same database
 table. Probably `Meta.db_table` would be set by the user in such cases. Do
 you have any other ideas? #12810 is another ticket about checks for
 clashing many-to-many tables.

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

Re: [Django] #25899: manage.py tests requires database creation privileges

[Django]

#25899: manage.py tests requires database creation privileges
---+--
 Reporter:  JorisBenschop  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  1.9
 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
---+--

Comment (by timgraham):

 A couple sentences after the one you quoted, "If you want to use a
 different database name, specify NAME in the TEST dictionary for any given
 database in DATABASES." Could you combine this with the `manage.py test
 --keepdb` option to get the desired result?

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

Re: [Django] #25900: CommonMiddleware's USE_ETAGS broken

[Django]

#25900: CommonMiddleware's USE_ETAGS broken
-+-
 Reporter:  derekjamescurtis |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  ETags| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * easy:  1 => 0
 * stage:  Unreviewed => Ready for checkin


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

Re: [Django] #25902: app names with underscore conflict with many-to-many tables

[Django]

#25902: app names with underscore conflict with many-to-many tables
-+-
 Reporter:  amosonn  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 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 amosonn):

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


Old description:

> If you have an app called X with a model called Y with a m2m field called
> Z, the default table name for the m2m is X_Y_Z.
> If you have an app called X_Y with a model called Z, the default table
> name for the model is also X_Y_Z.
> If you have both, django breaks when creating the tables.
> See a broken sample project at:

New description:

 If you have an app called X with a model called Y with a m2m field called
 Z, the default table name for the m2m is X_Y_Z.
 If you have an app called X_Y with a model called Z, the default table
 name for the model is also X_Y_Z.
 If you have both, django breaks when creating the tables.
 See a broken sample project at:
 https://github.com/amosonn/check_underscore

--

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

[Django] #25902: app names with underscore conflict with many-to-many tables

[Django]

#25902: app names with underscore conflict with many-to-many tables
--+
 Reporter:  amosonn   |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 If you have an app called X with a model called Y with a m2m field called
 Z, the default table name for the m2m is X_Y_Z.
 If you have an app called X_Y with a model called Z, the default table
 name for the model is also X_Y_Z.
 If you have both, django breaks when creating the tables.
 See a broken sample project at:

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

Re: [Django] #25898: test database creation on Oracle mistakes privilege error for existing database (was: manage.py test mistakes privilege error for existing database)

[Django]

#25898: test database creation on Oracle mistakes privilege error for existing
database
---+
 Reporter:  JorisBenschop  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords:  oracle test| Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timgraham):

 * stage:  Unreviewed => Accepted


Comment:

 Code in question:
 
https://github.com/django/django/blob/1aa8bf9b43bbc214770389b9b8d084552040fa44/django/db/backends/oracle/creation.py#L37-L48

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

Re: [Django] #25901: Pip install crashing at "Compiling" phase due to "Syntax error"

[Django]

#25901: Pip install crashing at "Compiling" phase due to "Syntax error"
---+--
 Reporter:  sreejithr  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Packaging  |  Version:  1.9
 Severity:  Normal |   Resolution:  invalid
 Keywords:  install, pip,  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

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


Comment:

 Please see ​https://docs.djangoproject.com/en/1.9/releases/1.9
 /#syntaxerror-when-installing-django-setuptools-5-5-x.

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

Re: [Django] #25900: CommonMiddleware's USE_ETAGS broken

[Django]

#25900: CommonMiddleware's USE_ETAGS broken
-+-
 Reporter:  derekjamescurtis |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  ETags| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by derekjamescurtis):

 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * 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/074.e97fbd1fe1181755b1ab882f6164d293%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25901: Pip install crashing at "Compiling" phase due to "Syntax error"

[Django]

#25901: Pip install crashing at "Compiling" phase due to "Syntax error"
+---
 Reporter:  sreejithr   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Packaging   |Version:  1.9
 Severity:  Normal  |   Keywords:  install, pip,
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+---
 To reproduce, do this inside a new virtualenv:

 {{{
 pip install Django==1.9
 }}}

 This is the output:

 {{{
 (test)~ ❯❯❯ pip install Django==1.9
 Downloading/unpacking Django==1.9
   Downloading Django-1.9-py2.py3-none-any.whl (6.6MB): 6.6MB downloaded
 Installing collected packages: Django
 Compiling
 /Users/sreejith/Envs/test/build/Django/django/conf/app_template/apps.py
 ...
   File
 "/Users/sreejith/Envs/test/build/Django/django/conf/app_template/apps.py",
 line 4
 class {{ camel_case_app_name }}Config(AppConfig):
   ^
 SyntaxError: invalid syntax

 Compiling
 /Users/sreejith/Envs/test/build/Django/django/conf/app_template/models.py
 ...
   File
 "/Users/sreejith/Envs/test/build/Django/django/conf/app_template/models.py",
 line 1
 {{ unicode_literals }}from django.db import models
  ^
 SyntaxError: invalid syntax

 Successfully installed Django
 Cleaning up...
 }}}

 I made a project in the virtualenv and tested. '''It works'''. Does anyone
 else have this problem?

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

[Django] #25900: CommonMiddleware's USE_ETAGS broken

[Django]

#25900: CommonMiddleware's USE_ETAGS broken
-+
 Reporter:  derekjamescurtis |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Core (Cache system)  |Version:  1.9
 Severity:  Normal   |   Keywords:  ETags
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  1|  UI/UX:  0
-+
 ETag support is broken in CommonMiddleware

 This appears to have been broken here:
 
https://github.com/django/django/commit/7a40fef17ab7918cbb1ddc3ba080f42b420f7a48
 #diff-1f8be0eae49a1bf37d52829eaeda6a4e

 django.utils.cache.**get_conditional_response**'s etag argument needs to
 be *unquoted*, however the etag passed by CommonMiddleware's make_response
 is quoted.

 Pull Request with Regression Test:
 https://github.com/django/django/pull/5803

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

Re: [Django] #25894: Paginator fails with QuerySet returning no values

[Django]

#25894: Paginator fails with QuerySet returning no values
-+--
 Reporter:  debnet   |Owner:  sir-sigurd
 Type:  Bug  |   Status:  assigned
Component:  Core (Other) |  Version:  1.9
 Severity:  Release blocker  |   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 debnet):

 Quick and dirty monkey patch.


 {{{
 # django monkey patch
 # https://code.djangoproject.com/ticket/25894
 try:
 from django.db.models.sql.compiler import SQLCompiler

 def _results_iter(self, results=None):
 if not hasattr(self, 'col_count'):
 self.col_count = 0
 self.select = []
 return self._results_iter(results)

 SQLCompiler._results_iter = SQLCompiler.results_iter
 SQLCompiler.results_iter = _results_iter
 except:
 pass
 }}}

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

Re: [Django] #25894: Paginator fails with QuerySet returning no values

[Django]

#25894: Paginator fails with QuerySet returning no values
-+--
 Reporter:  debnet   |Owner:  sir-sigurd
 Type:  Bug  |   Status:  assigned
Component:  Core (Other) |  Version:  1.9
 Severity:  Release blocker  |   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 sir-sigurd):

 Bisected to afe0bb7b13bb8dc4370f32225238012c873b0ee3.

 Minimal example to reproduce:
 {{{
 from django.contrib.contenttypes.models import ContentType
 list(ContentType.objects.values('model')[0: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/064.0ac899fd7948579d755dcfe9051978f5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25898: manage.py test mistakes privilege error for existing database

[Django]

#25898: manage.py test mistakes privilege error for existing database
---+--
 Reporter:  JorisBenschop  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords:  oracle test| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by aaugustin):

 As a workaround, you can try `manage.py test --keep-db`. I'm not saying
 this is the ideal resolution of this ticket. I'm just trying to give you a
 way forwards while we figure out a solution.

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

Re: [Django] #25898: manage.py test mistakes privilege error for existing database (was: manage.py test mistakes privilege error for existing databas)

[Django]

#25898: manage.py test mistakes privilege error for existing database
---+--
 Reporter:  JorisBenschop  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords:  oracle test| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by JorisBenschop):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 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/071.367d3ad7f67028542c56cff26727130c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25899: manage.py tests requires database creation privileges

[Django]

#25899: manage.py tests requires database creation privileges
---+--
 Reporter:  JorisBenschop  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  1.9
 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 JorisBenschop):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Testing framework
 * 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/071.9713d0087100a2ac69bf5902ae904beb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25899: manage.py tests requires database creation privileges

[Django]

#25899: manage.py tests requires database creation privileges
---+
 Reporter:  JorisBenschop  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 From
 {{{
 #https://docs.djangoproject.com/en/1.9/topics/testing/overview/#the-test-
 database
 By default the test databases get their names by prepending test_ to the
 value of the NAME settings for the databases defined in DATABASES.
 }}}

 I guess this works great on sqlite and my homegrown postgres machine, but
 I'm developing applications on Oracle RAC clusters, and I hope you can see
 this is not an environment I'd be allowed to create databases on. The
 database schemas are rather complex (using things like RAW(16) primary
 keys and reference-based partitioning) and I'm not allowing Django to make
 the tables itself.

 I have been unable to find a workaround in documentation (e.g. --use-this-
 database-instead-of-creating-one= and --assume-models-are-present ). If
 this exists, please change this ticket into a documentation request
 instead.

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

[Django] #25898: manage.py test mistakes privilege error for existing databas

[Django]

#25898: manage.py test mistakes privilege error for existing databas
---+-
 Reporter:  JorisBenschop  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  1.9
 Severity:  Normal |   Keywords:  oracle test
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+-
 If I run "manage.py test" on Oracle 12 the following occurs:
 {{{
 $ ./manage.py test
 Creating test database for alias 'default'...
 Failed (ORA-01031: insufficient privileges
 )
 Got an error creating the test database: ORA-01031: insufficient
 privileges

 It appears the test database, test_GFJOM_prada_, already exists. Type
 'yes' to delete it, or 'no' to cancel:
 }}}

 To me this seems that the error ('you are not allowed to create a db
 because you have no privs for that" is mistaken for "the db already exists
 thus you cannot make it"

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

Re: [Django] #25897: Managers defined on non-abstract base classes are in fact inherited by child classes.

[Django]

#25897: Managers defined on non-abstract base classes are in fact inherited by
child classes.
-+-
 Reporter:  poleha   |Owner:  poleha
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  manager, | Triage Stage:  Accepted
  inheritance|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by poleha):

 Pull request:
 https://github.com/django/django/pull/5797

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

Re: [Django] #25894: Paginator fails with QuerySet returning no values

[Django]

#25894: Paginator fails with QuerySet returning no values
-+--
 Reporter:  debnet   |Owner:  sir-sigurd
 Type:  Bug  |   Status:  assigned
Component:  Core (Other) |  Version:  1.9
 Severity:  Release blocker  |   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 sir-sigurd):

 * status:  new => assigned
 * owner:  nobody => sir-sigurd


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

Re: [Django] #25897: Managers defined on non-abstract base classes are in fact inherited by child classes.

[Django]

#25897: Managers defined on non-abstract base classes are in fact inherited by
child classes.
-+-
 Reporter:  poleha   |Owner:  poleha
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  manager, | Triage Stage:  Accepted
  inheritance|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by sir-sigurd):

 * needs_better_patch:   => 0
 * version:  master => 1.8
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 steps to reproduce:
 {{{
 class TestManager(models.Manager):
 pass

 class Test(models.Model):
 objects = TestManager()
 other_objects = TestManager()

 class TestInherited(Test):
 pass
 }}}

 {{{
 In [2]: TestInherited.objects
 Out[2]: 

 In [3]: TestInherited.other_objects
 Out[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/064.40b6fdba4c8778ad421db724f7b27fe6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.