date:20141201

Re: [Django] #5986: Easy way to customize ordering of fields on forms that use inheritance

2014-12-01 Thread Django

* cc: loic (added)

Comment:

Replying to [comment:30 carljm]:
> Hmm, I always thought that relying on ordering of `clean_`
calls was unsupported; a `clean_` method should only deal with
its field and nothing else, if you need to validate multiple fields it
should be done in `clean`.

+1, especially now that `add_error()` makes it very easy to do.

> I think that in most cases forms are better rendered explicitly in the
template, and that's where field-ordering belongs. But there are use cases
(more generic applications such as the admin) where that's not practical.
The fact that we reorder form fields ourselves in Django is a pretty
strong argument that there should be a public API for it.

Quoting from the PR regarding `Form.field_order`: "Fields missing in the
list are removed". I'm worried this adds yet another way of excluding
fields, `ModelForm` is already pretty confusing with both `fields` and
`exclude` (and the possible overlap of the two). There is also the
interaction with `ModelAdmin` that already supports fields ordering
through `fields` and `fieldsets`.

Finally I'd like to point out that the proposed API doesn't play well with
inheritance. We wouldn't be able to use it in `PasswordChangeForm` for
instance as it would break any subclasses with extra fields.

Doesn't sorting `self.fields` in `__init__()` achieves the same result
anyway?

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

Re: [Django] #9025: Nested Inline Support in Admin

2014-12-01 Thread Django

#9025: Nested Inline Support in Admin
---+
 Reporter:  pixelcort  |Owner:
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  Bug?   | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  1
---+

Comment (by rkjdid):

 up o/

 currently using silverfix fork, pretty cool but has some limitations/bugs

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

Re: [Django] #23934: A bug in _create_formsets causes ModelAdmin methods to receive wrong argument values

2014-12-01 Thread Django

#23934: A bug in _create_formsets causes ModelAdmin methods to receive wrong
argument values
-+-
 Reporter:  kbr- |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:  ModelAdmin admin | Triage Stage:  Accepted
  add_view   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timgraham):

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

Re: [Django] #23945: Use configured SITE_ID when creating the default site

2014-12-01 Thread Django

#23945: Use configured SITE_ID when creating the default site
---+
 Reporter:  wrwrwr |  Owner:  nobody
 Type:  New feature| Status:  closed
Component:  contrib.sites  |Version:  master
 Severity:  Normal | Resolution:  fixed
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
UI/UX:  0  |
---+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"bfc75996f9b7486929f0c4340bca54a8afa7ecfb"]:
 {{{
 #!CommitTicketReference repository=""
 revision="bfc75996f9b7486929f0c4340bca54a8afa7ecfb"
 Fixed #23945 -- Made default site use the configured SITE_ID.
 }}}

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

Re: [Django] #23934: A bug in _create_formsets causes ModelAdmin methods to receive wrong argument values

2014-12-01 Thread Django

#23934: A bug in _create_formsets causes ModelAdmin methods to receive wrong
argument values
-+-
 Reporter:  kbr- |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:  ModelAdmin admin | Triage Stage:  Accepted
  add_view   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by kbr-):

 Done. Check out the pull request.

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

Re: [Django] #23807: Postgres backend throws error when coercing psycopg2 version string to int when version contains non-numeric characters

2014-12-01 Thread Django

#23807: Postgres backend throws error when coercing psycopg2 version string to 
int
when version contains non-numeric characters
-+-
 Reporter:  ryanbagwell  |Owner:  coldmind
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"1739ae9edc6e6c07ca20cad36dd15316f18f3f8e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1739ae9edc6e6c07ca20cad36dd15316f18f3f8e"
 Fixed #23807 -- Ignored non-digits in psycopg2 version
 }}}

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

Re: [Django] #23577: CREATE INDEX-related OperationalError on migrating renamed models with colliding field names

2014-12-01 Thread Django

#23577: CREATE INDEX-related OperationalError on migrating renamed models with
colliding field names
+
 Reporter:  CrimsonZen  |Owner:
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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 tomviner):

 * owner:  tomviner =>
 * status:  assigned => new


Comment:

 After [https://groups.google.com/forum/#!topic/django-
 developers/7pMxh2JF1lo a discussion on django-dev] it makes sense to leave
 the resolution of this issue to
 [https://github.com/django/deps/blob/indexes/drafts/indexes.rst Marc
 Tamlyn's Advanced indexes DEP], which he says will involve user
 specified/reproducible index names, as well as index renaming.

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

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

Re: [Django] #23931: db_manager() method doesn't increment creation_counter

2014-12-01 Thread Django

Comment (by rhettg):

I think it does make sense to allow creation of a manager with db or hints
directly rather than relying on the copy behavior.

However,

1. That's obviously a bit more involved since BaseManager doesn't
currently take any arguments and sub-classing is a really popular pattern.
It could conceivable cause problems for people.
1. That doesn't mean this patch isn't also correct. I don't think it's
appropriate to have any 'copy' patterns that don't increment the
creation_counter.

So maybe this patch is appropriate for backporting (since not incrementing
the counter is a bug), while adding arguments to init would be a valid for
a release?

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

Re: [Django] #23943: Audit tests decorated with unittest.expectedFailure

2014-12-01 Thread Django

Comment (by mjtamlyn):

1 is a moot point - an expected failure test is run, and is reported as an
"unexpected success" if it passes. In python 3.4 at least I think this is
considered the same as a fail.

I have used expected failure a few times in the postgres array tests where
I expect a query to fail with a database error. If this starts passing,
I'd like to know about it and update the documentation. I could catch and
inspect the error instead, but I feel saying "run this and I expect it to
fail" is better than "run this and expect a given error from outside our
code" - I'd use `assertRaises` to check my own `raise` statements only.

I don't mind if this is changed (or at least more clearly commented).

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

Re: [Django] #23913: = comparison does work in templates although it shouldn't

2014-12-01 Thread Django

#23913: = comparison does work in templates although it shouldn't
-+-
 Reporter:  googol7  |Owner:
 Type:   |  olasitarska
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  Version:  master
 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 olasitarska):

 * has_patch:  0 => 1


Comment:

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

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

Re: [Django] #12118: in-memory test database does not work with threads

2014-12-01 Thread Django

#12118: in-memory test database does not work with threads
-+-
 Reporter:  bluebird75   |Owner:  coldmind
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  threads  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by coldmind):

 * status:  new => assigned
 * owner:  nobody => coldmind


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

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

Re: [Django] #23944: Django should use custom exceptions for errors thrown by send_mail (etc.), not smtplib.SMTPException

2014-12-01 Thread Django

#23944: Django should use custom exceptions for errors thrown by send_mail
(etc.),
not smtplib.SMTPException
---+--
Reporter: jordanreiter |Owner: nobody
Type: Uncategorized | Status: new
Component: Core (Mail)| Version: 1.7
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 jordanreiter):

> If you have ideas on how you would implement this, sketching that out a
bit more would be helpful.

Sure. I was thinking that `django.core.mail.backends.smtp.SMTPException`
et al would subclass ''both'' `django.core.mail.exceptions.EmailError`
''and'' `smtplib.SMTPException`. That way existing code that caught
`smtplib.SMTPException` would behave the same as it does now, but newer
code could catch `EmailException` instead.

I think it's necessary because there are '''tons''' of third party apps
that use `send_mail` and if you write your own backend (or use another
library) then you can run into problems.

Obviously until most apps use `EmailException` they will still fall flat,
but right now it's pretty much enshrined that they will break if you're
using a non-smtplib-based library.

For example, if you use are using Amazon SES (via boto) as the backend,
the exception that comes back is likely to be
`boto.SESConnection.ResponseError`.

Establishing custom exceptions would have two benefits:

- establishing a standard that developers of non-SMTP mail backends can
use when raising exceptions
- decoupling exceptions from the smtp library altogether

I was thinking that the exceptions that would be available in
`django.core.mail.exceptions` would be `EmailError`,
`EmailAuthenticationError`, `EmailConnectError`, `RecipientsRefused`, and
`SenderRefused`. It seems like these are all functions that most backends
would implement and, if they don't, then they wouldn't throw those
exceptions and so they don't need to be implemented for that backend.

For the Amazon SES example, failing to send correct API credentials would
result in `SESAuthenticationError` which subclasses
`EmailAuthenticationError` while encountering a situation where for some
reason the API was failing to respond correctly would result in
`SESConnectError` which subclasses `EmailConnectError`. And so on.

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

[Django] #23945: Use configured SITE_ID when creating the default site

2014-12-01 Thread Django

#23945: Use configured SITE_ID when creating the default site
---+
Reporter: wrwrwr | Owner: nobody
Type: New feature| Status: new
Component: contrib.sites |Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 1
Easy pickings: 0 | UI/UX: 0
---+
Consider the following steps:
* start a new project;
* edit settings adding `SITE_ID = 26` and `'django.contrib.sites'`;
* migrate.

The default "example.com" site will be created with the primary key equal
to 1 not 26.

Fixing it in general doesn't seem to cause any harm, but it probably only
matters with some nonrel backends. For instance, in MongoDB automatic
primary keys are [http://docs.mongodb.org/manual/reference/object-id/
certain bytestings] ^[#f1 1]^ and mongo backend [https://github.com
/django-nonrel/mongodb-
engine/blob/master/django_mongodb_engine/base.py#L99 doesn't support]
anything else as keys.

''![1][[=#f1]] Supporting such keys requires some black magic, but that's
another story.''

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

Re: [Django] #23944: Django should use custom exceptions for errors thrown by send_mail (etc.), not smtplib.SMTPException

2014-12-01 Thread Django

Comment (by timgraham):

It seems to me that applications may want to handle different email
exceptions in a particular way. If we start hiding the original exception,
that's no longer possible (or at least more difficult). I think having to
update the exceptions that your application handles if you switch email
backends is reasonable. On the other hand, that might not be feasible for
third-party apps. If you have ideas on how you would implement this,
sketching that out a bit more would be helpful.

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

Re: [Django] #23944: Django should use custom exceptions for errors thrown by send_mail (etc.), not smtplib.SMTPException

2014-12-01 Thread Django

#23944: Django should use custom exceptions for errors thrown by send_mail 
(etc.),
not smtplib.SMTPException
---+--
 Reporter:  jordanreiter   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Core (Mail)|  Version:  1.7
 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 jordanreiter):

 * needs_better_patch:   => 0
 * type:  New feature => Uncategorized
 * 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/070.e30a94947da4be19677aecb60dfd4dba%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23944: Django should use custom exceptions for errors thrown by send_mail (etc.), not smtplib.SMTPException

2014-12-01 Thread Django

#23944: Django should use custom exceptions for errors thrown by send_mail 
(etc.),
not smtplib.SMTPException
--+
 Reporter:  jordanreiter  |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Core (Mail)   |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Since Django allows all kinds of backends — not just SMPT — for sending
 mail, it should have its own exceptions that different mail backends can
 subclass.

 Otherwise, if you have code like this:

 {{{
 try:
 send_mail(...)
 except smptlib.SMTPException:
 # do something
 }}}

 And then switch to a backend that doesn't use smtplib, you won't catch the
 error.

 I think the exceptions should be available from
 `django.core.mail.exceptions` and then subclassed within each backend.

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

Re: [Django] #23289: Make mock library available for testing in Django

2014-12-01 Thread Django

#23289: Make mock library available for testing in Django
-+-
 Reporter:  claudep  |Owner:  timgraham
 Type:  New feature  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"82e4f956e3faa4a48fe3c90e02673c1a916d6943"]:
 {{{
 #!CommitTicketReference repository=""
 revision="82e4f956e3faa4a48fe3c90e02673c1a916d6943"
 Fixed #23289 -- Added mock as a test dependency.
 }}}

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

Re: [Django] #23768: Rewrite template_tag.tests.TemplateTests as individual test cases

2014-12-01 Thread Django

Comment (by prestontimmons):

I updated my pull request to include the remainder of the template tests.
I'm going to do a final check through everything before unchecking patch
needs improvement.

For ease of auditing, I kept all the test methods named the same as
before, i.e. include01, include02, etc. I think it would be good to add
meaningful names in a separate patch.

The new suite adds 640 tests, including the additional test for the setup
function. The previous suite had 641 tests, two of which weren't really
tests themselves: `include 05` and `include-cycle`. I verified this with
this script:

https://gist.github.com/prestontimmons/01ed288aaa2083afa2d4

I didn't update the filter tests yet. I think these should also be done in
a separate patch.

I have a couple specific questions:

1) There are two tests that seem to have wrong comments:

* filter-syntax25
* if-tag-shortcircuit02

In both cases, the tests do the opposite of what the comment says. For
`filter-syntax25` I believe the comment is wrong. For `if-tag-
shortcircuit02`, I think the test is wrong.

Does anyone else agree?

2) I added a warnings filter for the url tag tests to the setup function.
Is this done right? I'm not too familiar with how warnings work.

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

Re: [Django] #23880: SQLite's schema editor doesn't handle index_together

2014-12-01 Thread Django

#23880: SQLite's schema editor doesn't handle index_together
-+-
 Reporter:  MarkusH  |Owner:  MarkusH
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Ready for
 Keywords:   |  checkin
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:"ba3e97618696bdd68e4ac9b2220f58e6b3d15bd4"]:
 {{{
 #!CommitTicketReference repository=""
 revision="ba3e97618696bdd68e4ac9b2220f58e6b3d15bd4"
 [1.7.x] Fixed #23880 -- Added missing index_together handling for SQLite

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

Re: [Django] #7361: Add back button to admin delete page

2014-12-01 Thread Django

#7361: Add back button to admin delete page
-+-
 Reporter:  simon|Owner:  barbuza
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  usability nfa-   | Triage Stage:  Accepted
  someday feature|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-

Comment (by Tim Graham ):

 In [changeset:"43fcf3505eb8f551ab03122f99b3d40f38ed"]:
 {{{
 #!CommitTicketReference repository=""
 revision="43fcf3505eb8f551ab03122f99b3d40f38ed"
 Fixed admin_views test from refs #7361 (name was too long).
 }}}

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

Re: [Django] #23939: SessionAuthenticationMiddleware causes "Vary: Cookie" header no matter what

2014-12-01 Thread Django

Comment (by carljm):

A couple ideas, but I don't think either one is better than adding a
setting:

1. Could have a new version of `AuthenticationMiddleware` which does the
session validation, and deprecate the current `AuthenticationMiddleware`.
But this is more churn for everyone, and means the new
`AuthenticationMiddleware` would have a less obvious name. Bad idea.

2. Could keep `SessionAuthenticationMiddleware`, and have it re-wrap
`request.user` in a second level of lazy object. But - yuck.

The problem with just reverting to your original approach and adding a
setting to enable it, is that it would have the effect of silently
disabling session validation for all projects created using already-
released versions of Django 1.7 (since they wouldn't have that setting).

Is there a use case for a long-term simple way to disable this behavior?
Or is it just a way to preserve sessions across the upgrade that we need?
Personally I think we should be on a deprecation path to making this
always-on; I think it's fine if you have to write your own
`AuthenticationMiddleware` if you don't want 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/068.ffd2c3370c14ec19fa1fafebba0ea563%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23326: DatabaseCache must implement incr to guarantee atomic increment

2014-12-01 Thread Django

* needs_better_patch: 0 => 1

Comment:

My initial patch and pull request will not work as desired. Wrapping the
get/set in an atomic block will only work for database isolation levels
higher than Postgresql's default. There are two possible ways of ensuring
an atomic incr, (1) control the locking from python, or (2) use
select_for_update. Select_for_update would be the ideal solution, except
DatabaseCache doesn't use the ORM and would need to expose an API for each
database backend to provide SQL.

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

Re: [Django] #23939: SessionAuthenticationMiddleware causes "Vary: Cookie" header no matter what

2014-12-01 Thread Django

#23939: SessionAuthenticationMiddleware causes "Vary: Cookie" header no matter 
what
-+-
 Reporter:  andrewbadr   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:  cookies  | 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):

 * owner:  nobody => timgraham
 * status:  new => assigned


Comment:

 That approach is actually what I implemented originally in
 [https://github.com/django/django/pull/2113 this pull request]. In #21649,
 however, the concern about users losing their session when Django was
 upgraded was raised. If we revert to the original approach, it seems like
 we may need a setting to disable the behavior for users who don't want it.
 Any other ideas?

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

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

Re: [Django] #23289: Make mock library available for testing in Django

2014-12-01 Thread Django

#23289: Make mock library available for testing in Django
-+-
 Reporter:  claudep  |Owner:  timgraham
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by claudep):

 * stage:  Accepted => 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/065.9342e2812bec5270a309d24923a211b3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #16828: Upgrade from 1.3 to 1.3.1 breaks manage.py test with multiple databases

2014-12-01 Thread Django

#16828: Upgrade from 1.3 to 1.3.1 breaks manage.py test with multiple databases
---+--
 Reporter:  aaugustin  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.3
 Severity:  Release blocker|   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tim Graham ):

 In [changeset:"1f98ec2e53e4636863396ab54f671f4546f9ba4c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1f98ec2e53e4636863396ab54f671f4546f9ba4c"
 Fixed #23929 -- Added more tests for create_default_site.

 Refs: #15346, #15573, #16353, #16828.
 }}}

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

Re: [Django] #15573: runtests.py sets incorrect SITE_ID when using Oracle

2014-12-01 Thread Django

#15573: runtests.py sets incorrect SITE_ID when using Oracle
---+
 Reporter:  ikelly |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords:  oracle site_id | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |
---+

Comment (by Tim Graham ):

 In [changeset:"1f98ec2e53e4636863396ab54f671f4546f9ba4c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1f98ec2e53e4636863396ab54f671f4546f9ba4c"
 Fixed #23929 -- Added more tests for create_default_site.

 Refs: #15346, #15573, #16353, #16828.
 }}}

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

Re: [Django] #23929: More tests for create_default_site

2014-12-01 Thread Django

#23929: More tests for create_default_site
-+-
 Reporter:  wrwrwr   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.sites|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"1f98ec2e53e4636863396ab54f671f4546f9ba4c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1f98ec2e53e4636863396ab54f671f4546f9ba4c"
 Fixed #23929 -- Added more tests for create_default_site.

 Refs: #15346, #15573, #16353, #16828.
 }}}

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

Re: [Django] #16353: With multi-databases, if django.contrib.sites.models.Site is not synchronized on all databases, Django's tests fail

2014-12-01 Thread Django

#16353: With multi-databases, if django.contrib.sites.models.Site is not
synchronized on all databases, Django's tests fail
---+
 Reporter:  aaugustin  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.3
 Severity:  Release blocker|   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:"1f98ec2e53e4636863396ab54f671f4546f9ba4c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1f98ec2e53e4636863396ab54f671f4546f9ba4c"
 Fixed #23929 -- Added more tests for create_default_site.

 Refs: #15346, #15573, #16353, #16828.
 }}}

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

Re: [Django] #15346: SITE_ID default value is wrong

2014-12-01 Thread Django

#15346: SITE_ID default value is wrong
+--
   Reporter:  depaolim  |Owner:  nobody
   Type:|   Status:  closed
  Component:  Contrib apps  |  Version:  1.2
   Severity:|   Resolution:  worksforme
   Keywords:  SITE_ID   | Triage Stage:  Unreviewed
  Has patch:  0 |  Needs documentation:  0
Needs tests:  0 |  Patch needs improvement:  0
+--

Comment (by Tim Graham ):

 In [changeset:"1f98ec2e53e4636863396ab54f671f4546f9ba4c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1f98ec2e53e4636863396ab54f671f4546f9ba4c"
 Fixed #23929 -- Added more tests for create_default_site.

 Refs: #15346, #15573, #16353, #16828.
 }}}

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

Re: [Django] #23909: RunSQL calls execute with params None, params used in map

2014-12-01 Thread Django

#23909: RunSQL calls execute with params None, params used in map
-+-
 Reporter:  yarbelk  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  migrations   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"e11c6fd2184a9e7b23c777e5824f9ded6221d905"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e11c6fd2184a9e7b23c777e5824f9ded6221d905"
 Fixed #23909 -- Prevented crash when collecting SQL for RunSQL

 Thanks James Rivett-Carnac for the report and Markus Holtermann
 for the review.
 }}}

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

Re: [Django] #23718: TEST_MIRROR setting doesn't work as expected (and has no tests)

2014-12-01 Thread Django

#23718: TEST_MIRROR setting doesn't work as expected (and has no tests)
---+
 Reporter:  coagulant  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords:  replica testing| Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Atala):

 Ran into the same issue, I think both the old (TEST_MIRROR) and new (TEST:
 {MIRROR:) settings are not working. I had the issue running raw sql with
 the connection cursor.

 I am new in this part of the codebase & in databases connections, so I am
 not really sure what's going on. In this gist:
 https://gist.github.com/Atala/d5420ac426c79b45d4db , it's clear that the
 two connections returned are not the same object (they should have same ID
 no?)  but are pointing to the same DB name. However a SELECT statement
 will work only on the 'default' db, a SELECT against 'prestashop' will
 return nothing (but the tables are correctly created).

 I would be glad to help if you had some hints,

 Aloïs

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

Re: [Django] #23939: SessionAuthenticationMiddleware causes "Vary: Cookie" header no matter what

2014-12-01 Thread Django

#23939: SessionAuthenticationMiddleware causes "Vary: Cookie" header no matter 
what
-+
 Reporter:  andrewbadr   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:  cookies  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by carljm):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Marking as release blocker -- this is a serious regression in 1.7 which
 should be backported to 1.7.x. Unfortunately, we'll have to keep
 `SessionAuthenticationMiddleware` around as a no-op middleware, deprecated
 in 1.8.

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

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

Re: [Django] #23939: SessionAuthenticationMiddleware causes "Vary: Cookie" header no matter what

2014-12-01 Thread Django

Comment (by carljm):

I don't think "document the limitation" is an acceptable answer here.
Adding `Vary: Cookie` unconditionally to all requests has massive
implications for caching of requests that otherwise would not vary per-
user. I know some large sites work hard to avoid `Vary: Cookie` on certain
responses in order to make them cacheable without having to cache
separately per-client.

I think `SessionAuthenticationMiddleware` should be implemented quite
differently, probably not as a middleware at all, but rather as code that
runs lazily when `request.user` is first used (that is, in the `get_user`
helper function).

We should also add a simple test somewhere in the test suite that sets up
a view which never accesses the session (or `request.user`, which
implicitly accesses the session), and then calls that view with an end-to-
end test passing through all the default middleware, and asserts that
`Vary: Cookie' is not added to its responses. These bugs are way too easy
to introduce, and we need a general test like that to prevent regressions
of this type.

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

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

Re: [Django] #23879: We should use test-skipping, not conditional discovery in runtests.py

2014-12-01 Thread Django

#23879: We should use test-skipping, not conditional discovery in runtests.py
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  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 timgraham):

 That looks interesting. It would probably be worth discussing the issue of
 database vendor specific migrations on the DevelopersMailingList. If it's
 been discussed before I'm not aware of 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/064.71bc74f8c4bb64ecce5b7cce9299fc49%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23929: More tests for create_default_site

2014-12-01 Thread Django

#23929: More tests for create_default_site
-+-
 Reporter:  wrwrwr   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.sites|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by timgraham):

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

Re: [Django] #23934: A bug in _create_formsets causes ModelAdmin methods to receive wrong argument values

2014-12-01 Thread Django

#23934: A bug in _create_formsets causes ModelAdmin methods to receive wrong
argument values
-+-
 Reporter:  kbr- |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:  ModelAdmin admin | Triage Stage:  Accepted
  add_view   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timgraham):

 * severity:  Normal => Release blocker
 * needs_tests:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 I guess the regression was introduced in
 402b4a7a20a4f00fce0f01cdc3f5f97967fdb935. If you can add a test and
 release notes in docs/releases/1.7.2.txt we can backport the fix and
 include it on the next minor release.

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

Re: [Django] #19698: Deleting Sites through a manager does not clear cache

2014-12-01 Thread Django

#19698: Deleting Sites through a manager does not clear cache
-+-
 Reporter:  ddavies@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.sites|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"777b4c26e343d07764a35132462e92c07e4b0aec"]:
 {{{
 #!CommitTicketReference repository=""
 revision="777b4c26e343d07764a35132462e92c07e4b0aec"
 Removed a clear_cache statement in contrib.sites.create_default_site.

 It was originally added to fix a test (refs #7514); but Site now has a
 pre_save signal handler (refs #19698) to clear the cache which makes
 this call redundant.
 }}}

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

Re: [Django] #7514: Test failure after r7716

2014-12-01 Thread Django

#7514: Test failure after r7716
+-
   Reporter:  Alex  |Owner:  telenieko
   Type:|   Status:  closed
  Component:  Contrib apps  |  Version:  master
   Severity:|   Resolution:  fixed
   Keywords:| Triage Stage:  Ready for checkin
  Has patch:  1 |  Needs documentation:  0
Needs tests:  0 |  Patch needs improvement:  0
+-

Comment (by Tim Graham ):

 In [changeset:"777b4c26e343d07764a35132462e92c07e4b0aec"]:
 {{{
 #!CommitTicketReference repository=""
 revision="777b4c26e343d07764a35132462e92c07e4b0aec"
 Removed a clear_cache statement in contrib.sites.create_default_site.

 It was originally added to fix a test (refs #7514); but Site now has a
 pre_save signal handler (refs #19698) to clear the cache which makes
 this call redundant.
 }}}

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

Re: [Django] #18586: Rewrite unit tests migrated from doctests

2014-12-01 Thread Django

#18586: Rewrite unit tests migrated from doctests
-+-
 Reporter:  konk |Owner:
 Type:   |  ChillarAnand
  Cleanup/optimization   |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  unit tests   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Woops, should have been "refs #" in the commit message of that last one so
 this didn't get closed as there is still more work to do in the other
 tests.

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

Re: [Django] #18586: Rewrite unit tests migrated from doctests

2014-12-01 Thread Django

#18586: Rewrite unit tests migrated from doctests
-+-
 Reporter:  konk |Owner:
 Type:   |  ChillarAnand
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  unit tests   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"e1513a7960399054d6686efb287f3887ad84b73f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e1513a7960399054d6686efb287f3887ad84b73f"
 Fixed #18586 -- Split up model_package.ModelPackageTests.
 }}}

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

Re: [Django] #23935: DecimalField in admin can show up as Scientific Notation

2014-12-01 Thread Django

#23935: DecimalField in admin can show up as Scientific Notation
+--
 Reporter:  xblitz  |Owner:  xblitz
 Type:  Bug |   Status:  assigned
Component:  contrib.admin   |  Version:  1.7
 Severity:  Normal  |   Resolution:
 Keywords:  DecimalField admin  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+--
Changes (by xblitz):

 * status:  new => assigned
 * owner:  nobody => xblitz


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

Re: [Django] #23937: Templates: control characters should be filtered out

2014-12-01 Thread Django

#23937: Templates: control characters should be filtered out
-+-
 Reporter:  jogc |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.6
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  control charcaters   | Triage Stage:
  c0 codes templates |  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:   => wontfix


Comment:

 That was my thought as well. I'll close the ticket for now until the
 reporter provides additional information.

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

Re: [Django] #23941: Aggregating over decimal field regression

2014-12-01 Thread Django

#23941: Aggregating over decimal field regression
-+-
 Reporter:  jarshwah |Owner:  jarshwah
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timgraham):

 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


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

[Django] #23943: Audit tests decorated with unittest.expectedFailure

2014-12-01 Thread Django

#23943: Audit tests decorated with unittest.expectedFailure
+
   Reporter:  timgraham |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (Other)  |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 There are less than 10 tests in our test suite that use
 `@unittest.expectedFailure`. We should check to make sure these tests are
 still valid.

 1. Does the test still fail? If not, remove the decorator.
 2. Is there a plan/ticket to fix the issue? If so, add a comment with the
 ticket number with the and make sure the test is linked to in the ticket.
 If not, create a ticket for the issue.

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

Re: [Django] #5986: Easy way to customize ordering of fields on forms that use inheritance

2014-12-01 Thread Django

Comment (by carljm):

Hmm, I always thought that relying on ordering of `clean_`
calls was unsupported; a `clean_` method should only deal with
its field and nothing else, if you need to validate multiple fields it
should be done in `clean`.

I think that in most cases forms are better rendered explicitly in the
template, and that's where field-ordering belongs. But there are use cases
(more generic applications such as the admin) where that's not practical.
The fact that we reorder form fields ourselves in Django is a pretty
strong argument that there should be a public API for 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/062.535d7835d085efe46216f0f7e3a4626b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #5986: Easy way to customize ordering of fields on forms that use inheritance

2014-12-01 Thread Django

#5986: Easy way to customize ordering of fields on forms that use inheritance
-+-
 Reporter:  emes |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  field order weight   | Triage Stage:  Accepted
  form newforms  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by charettes):

 * cc: charettes (added)


Comment:

 Replying to [comment:27 loic]:
 > Can't say I'm convinced with this ticket, IMO ordering fields belongs in
 the templates.

 The thing is field ordering also affects the order of `clean_`
 calls.

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

Re: [Django] #23933: Override_settings with DATABASE_ROUTERS

2014-12-01 Thread Django

#23933: Override_settings with DATABASE_ROUTERS
---+
 Reporter:  wrwrwr |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  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:"9136ceb6fb8225625631671147ff70c1fcfbbcdc"]:
 {{{
 #!CommitTicketReference repository=""
 revision="9136ceb6fb8225625631671147ff70c1fcfbbcdc"
 Replaced router.routers usage with override_settings(DATABASE_ROUTERS);
 refs #23933.
 }}}

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

Re: [Django] #23933: Override_settings with DATABASE_ROUTERS

2014-12-01 Thread Django

#23933: Override_settings with DATABASE_ROUTERS
---+
 Reporter:  wrwrwr |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  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:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"e6f19ec3223ba7c398aea515c5e0f8b93e6f4359"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e6f19ec3223ba7c398aea515c5e0f8b93e6f4359"
 Fixed #23933 -- Made override_settings(DATABASE_ROUTERS) affect the master
 router.
 }}}

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

Re: [Django] #5986: Easy way to customize ordering of fields on forms that use inheritance

2014-12-01 Thread Django

Comment (by alasdairnicol):

Replying to [comment:27 loic]:
> Can't say I'm convinced with this ticket, IMO ordering fields belongs in
the templates.

I used `self.field.keyOrder` in previous versions of Django, and would
find an official API useful. If you render the form in the template with
`{{ form }}` or `{{ form.ul }}`, then it's much easier to change the field
order in the form than the template.

The
[https://github.com/django/django/blob/1.7/django/contrib/auth/forms.py#L338
PasswordChangeForm] in the contrib.auth app changes the field order by
changing base_fields. I think it's much better to change it there than to
tell users to put 'old password' before 'new password' in their template.
It would be even better if we used a public API to change the field order.

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

Re: [Django] #18586: Rewrite unit tests migrated from doctests

2014-12-01 Thread Django

#18586: Rewrite unit tests migrated from doctests
-+-
 Reporter:  konk |Owner:
 Type:   |  ChillarAnand
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  unit tests   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by alexanderad):

 PR for model_package.ModelPackageTests.test_models_packages:
 https://github.com/django/django/pull/3657

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

Re: [Django] #6148: Add generic support for database schemas

2014-12-01 Thread Django

#6148: Add generic support for database schemas
-+-
 Reporter:  ikelly   |Owner:  akaariai
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  oracle postgresql|  Needs documentation:  1
  mysql schemas  |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by pombredanne):

 FWIW, I compiled a list of various implementations of multitenancy in
 Django, several of which are schema-based:
 https://github.com/pombredanne/django-simple-
 multitenant/blob/master/README.rst

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

Re: [Django] #23939: SessionAuthenticationMiddleware causes "Vary: Cookie" header no matter what

2014-12-01 Thread Django

#23939: SessionAuthenticationMiddleware causes "Vary: Cookie" header no matter 
what
--+--
 Reporter:  andrewbadr|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:  cookies   | 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):

 I am not sure how to address this other than to document the limitation.
 We cannot perform the middleware's purpose of verifying the session
 without accessing the session. Do you have any suggestions?

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

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

Re: [Django] #23942: fastcgi with fork method got db error

2014-12-01 Thread Django

#23942: fastcgi with fork method got db error
--+--
 Reporter:  SmiteChow |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  1.6
 Severity:  Normal|   Resolution:  wontfix
 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 timgraham):

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


Comment:

 I am not familiar with FastCGI, but we've
 [https://docs.djangoproject.com/en/1.7/releases/1.7/#fastcgi-support
 deprecated support for it] starting in Django 1.7 so I think there will be
 little interest in fixing this issue (assuming the problem is indeed in
 Django). Hopefully deploying your project using WSGI will fix your issue.

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

Re: [Django] #23909: RunSQL calls execute with params None, params used in map

2014-12-01 Thread Django

#23909: RunSQL calls execute with params None, params used in map
-+-
 Reporter:  yarbelk  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  migrations   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/3656

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

Re: [Django] #23909: RunSQL calls execute with params None, params used in map

2014-12-01 Thread Django

#23909: RunSQL calls execute with params None, params used in map
-+-
 Reporter:  yarbelk  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  migrations   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by claudep):

 To reproduce the error in current tests:
 {{{
 diff --git a/tests/migrations/test_operations.py
 b/tests/migrations/test_operations.py
 index 32f70e8..08a5600 100644
 --- a/tests/migrations/test_operations.py
 +++ b/tests/migrations/test_operations.py
 @@ -1292,7 +1292,7 @@ class OperationTests(OperationTestBase):
  # Make sure there's no table
  self.assertTableNotExists("i_love_ponies")
  # Test the database alteration
 -with connection.schema_editor() as editor:
 +with connection.schema_editor(collect_sql=True) as editor:
  operation.database_forwards("test_runsql", editor,
 project_state, new_state)
  self.assertTableExists("i_love_ponies")
  # Make sure all the SQL was processed
 }}}

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

Re: [Django] #16732: Unable to have abstract model with unique_together

2014-12-01 Thread Django

#16732: Unable to have abstract model with unique_together
-+-
 Reporter:  mitar|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by direx):

 * cc: direx (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/063.e152ba166729e1c65c052b3f3a2a1d08%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23942: fastcgi with fork method got db error

2014-12-01 Thread Django

#23942: fastcgi with fork method got db error
--+
 Reporter:  SmiteChow |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Core (Other)  |Version:  1.6
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 we use sqlalchemy + postgres in our app.

 when we start server on fastcgi model with fork method, the db connection
 got error:SSL error: decryption failed or bad record mac

 but, if we use fastcgi with thread method, everything is fine.

 so, i guess there must a issue on django.

 i initialnize my db connection in middleware class that design with
 singleton model.

 sorry about my poor english.

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

57 matches

Mail list logo