date:20131120

Re: [Django] #21427: Clearly state the value range of all integer type fields in the model field documentation

2013-11-20 Thread Django

#21427: Clearly state the value range of all integer type fields in the model 
field
documentation
--+
 Reporter:  giuliettamasina   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  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 claudep):

 * stage:  Ready for checkin => Accepted


Comment:

 Sorry, but I'd like to know where do the new figures come from. Could you
 please document here your findings (with appropriate links to backends
 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/073.9ac151706e48f9073ec9ab3cc56f1e01%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20780: collectstatic --link causes IOError when dangling symlink exists

2013-11-20 Thread Django

#20780: collectstatic --link causes IOError when dangling symlink exists
-+
 Reporter:  vdboor   |Owner:  johngian
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  1.5
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by vajrasky):

 * needs_tests:  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.274f8783af34407f42fc568b7ab7fa8d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21476: Cache tests make an incorrect use of `HttpRequest`

2013-11-20 Thread Django

#21476: Cache tests make an incorrect use of `HttpRequest`
-+-
 Reporter:  unaizalakain |Owner:
 Type:  Bug  |  unaizalakain
Component:  Core (Cache system)  |   Status:  assigned
 Severity:  Normal   |  Version:  master
 Keywords:  tests, cache,|   Resolution:
  request| Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by unaizalakain):

 * has_patch:  0 => 1


Comment:

 PR sent: https://github.com/django/django/pull/1950

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

Re: [Django] #21476: Cache tests make an incorrect use of `HttpRequest`

2013-11-20 Thread Django

#21476: Cache tests make an incorrect use of `HttpRequest`
-+-
 Reporter:  unaizalakain |Owner:
 Type:  Bug  |  unaizalakain
Component:  Core (Cache system)  |   Status:  assigned
 Severity:  Normal   |  Version:  master
 Keywords:  tests, cache,|   Resolution:
  request| Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by unaizalakain):

 * owner:  nobody => unaizalakain
 * needs_docs:   => 0
 * status:  new => assigned
 * 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/070.756531d05aedf95272781a2b49b9655c%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21476: Cache tests make an incorrect use of `HttpRequest`

2013-11-20 Thread Django

#21476: Cache tests make an incorrect use of `HttpRequest`
-+---
 Reporter:  unaizalakain |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (Cache system)  |Version:  master
 Severity:  Normal   |   Keywords:  tests, cache, request
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+---
 Cache tests directly append the query string to the request path:

 {{{
 request = HttpRequest()
 request.META = {
 'SERVER_NAME': 'testserver',
 'SERVER_PORT': 80,
 }
 request.method = method
 request.path = request.path_info = "/cache/%s" % path
 return request
 }}}

 `HttpRequest.get_full_path()` uses the `HttpRequest.META['QUERY_STRING']`
 attribute to determine, escape and encode the query string.

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

Re: [Django] #21427: Clearly state the value range of all integer type fields in the model field documentation

2013-11-20 Thread Django

#21427: Clearly state the value range of all integer type fields in the model 
field
documentation
-+-
 Reporter:  giuliettamasina  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Documentation|   Resolution:
 Severity:  Normal   | 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
-+-
Changes (by timo):

 * has_patch:  0 => 1
 * stage:  Accepted => Ready for checkin


Comment:

 Assuming the ranges are correct, this looks good. Could you amend your PR
 to follow the
 [https://docs.djangoproject.com/en/dev/internals/contributing/committing-
 code/#committing-guidelines commit message guidelines]? Also, don't forget
 to check "Has patch" so the ticket appears in the review queue. Thanks!

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

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

Re: [Django] #21475: Choices Field is not shown in UserAdmin when an special sign is in the choices

2013-11-20 Thread Django

#21475: Choices Field is not shown in UserAdmin when an special sign is in the
choices
---+--
 Reporter:  marco.roose@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.admin  |  Version:  1.5
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timo):

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


Comment:

 Yes, it's an error in your app, not Django. Consider using
 [https://docs.djangoproject.com/en/dev/topics/python3/#unicode-literals
 unicode_literals].

-- 
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/083.0f88edc3d23d9483255aa0c1a9c31bdf%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21431: Django 1.6 GenericRelation admin list_filter regression

2013-11-20 Thread Django

#21431: Django 1.6 GenericRelation admin list_filter regression
-+
 Reporter:  stephenmcd   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.6
 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 stephenmcd):

 Thanks akaariai - I can confirm the above path resolves the issue in
 Mezzanine.

-- 
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.9893d9c80390cb47d1916ab3fa55e165%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14825: LocaleMiddleware should store language preferences if possible

2013-11-20 Thread Django

Comment (by dave@…):

This change has made multi-language testing much more difficult for
authenticated Django applications.

Prior to this commit, my QA team could follow this simple process to
switch languages during testing:

1. Switch language in browser settings
2. Refresh page
3. Test

Now, they must do this:

1. Switch language in browser settings.
2. Clear session cookie
3. Re-authenticate
4. Navigate to page under test
5. Test

This behavior seems ok for the average user (whose language doesn't change
minute to minute), but for a tester, this really makes things slow. Even
test automation suffers (e.g., Selenium).

Could we at least put this behavior being a setting? Something like
setting.STORE_LANGUAGE_IN_SESSION = True|False (default True)

--
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.47fd4d054dc5acbc1e3ec22a1d27317a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21427: Clearly state the value range of all integer type fields in the model field documentation

2013-11-20 Thread Django

#21427: Clearly state the value range of all integer type fields in the model 
field
documentation
--+
 Reporter:  giuliettamasina   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  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 giuliettamasina):

 Opened a pull request here: https://github.com/django/django/pull/1949

-- 
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/073.2bcaf2ccb9828af6f2b9596841b81da3%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21443: On PY3 if error on import, cannot show debug info

2013-11-20 Thread Django

#21443: On PY3 if error on import, cannot show debug info
--+
 Reporter:  bouke |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Python 3  |  Version:  1.6
 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
--+

Comment (by claudep):

 I cannot reproduce on Python 3.2, I suppose this is specific to Python
 3.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/063.51b46827fa490b11d13c53d8bba85d2f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21475: Choices Field is not shown in UserAdmin when an special sign is in the choices

2013-11-20 Thread Django

#21475: Choices Field is not shown in UserAdmin when an special sign is in the
choices
---+--
 Reporter:  marco.roose@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  Version:  1.5
 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 marco.roose@…):

 I fiddled around a bit:

 (NOTPROOFED, u'Deine Anfrage wird geprüft'),

 does work. So it seems to be some unicode 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/083.212b9ac7e9d3c70b723c84e9c2345e44%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21475: Choices Field is not shown in UserAdmin when an special sign is in the choices

2013-11-20 Thread Django

#21475: Choices Field is not shown in UserAdmin when an special sign is in the
choices
---+--
 Reporter:  marco.roose@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  Version:  1.5
 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 marco.roose@…):

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


Comment:

 I fiddled around a bit:

 (NOTPROOFED, u'Deine Anfrage wird geprüft'),

 does work. So it seems to be some unicode 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/083.7be60dceb5784e7224ac40b84706514d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21475: Choices Field is not shown in UserAdmin when an special sign is in the choices

2013-11-20 Thread Django

#21475: Choices Field is not shown in UserAdmin when an special sign is in the
choices
---+
 Reporter:  marco.roose@…  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  contrib.admin  |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I have the following model:
 {{{
 # -*- coding: iso-8859-1 -*-

 from django.contrib.auth.models import AbstractUser
 from django.db import models


 class Nutzer(AbstractUser):
 NOTREGISTERED = "NR"
 NOTPROOFED = 'NP'
 NOTPAYED = 'NPY'
 EXPERIED = "EXP"
 OK = 'OK'

 MARKETSTATUSCHOICES = (
 (NOTREGISTERED, 'Du bist nicht registriert'),
 (NOTPROOFED, 'Deine Anfrage wird geprüft'),
 (NOTPAYED, 'Wir warten auf Deine Beitragszahlung'),
 (OK, 'Du kannst tauschen'),
 (EXPERIED, 'Dein Konto wurde gesperrt')
 )
 market_status = models.CharField(choices=MARKETSTATUSCHOICES,
 verbose_name="Tausch-Status", max_length=30, default=NOTREGISTERED)
 }}}

 and a "normal" Useradmin like the one from the docs. In the Nutzer change
 form the "market_status" field is not rendered (but the label).

 If I change the NOTPROOFED to have a description without the German Umlaut
 the field is rendered as expected.

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

[django/django] d8fdee: [1.6.x] Fixed #21472 -- Fixed inline formsets disp...

2013-11-20 Thread GitHub

  Branch: refs/heads/stable/1.6.x
  Home:   https://github.com/django/django
  Commit: d8fdee7db877e3a52a761bfcbeb3536ea219ec30
  
https://github.com/django/django/commit/d8fdee7db877e3a52a761bfcbeb3536ea219ec30
  Author: Claude Paroz 
  Date:   2013-11-20 (Wed, 20 Nov 2013)

  Changed paths:
M django/forms/models.py
M docs/releases/1.6.1.txt
M tests/inline_formsets/tests.py

  Log Message:
  ---
  [1.6.x] Fixed #21472 -- Fixed inline formsets display when parent pk is 0

Thanks agale031...@gmail.com for the report.
Backport of fafb6cf049b from master.



-- 
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/528d1dae1055b_2c15ec5d4c191293%40hookshot-fe2-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21472: Django 1.6 ImageField not rendered properly in Admin inline form

2013-11-20 Thread Django

#21472: Django 1.6 ImageField not rendered properly in Admin inline form
---+
 Reporter:  agale031176@…  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.6
 Severity:  Normal |   Resolution:  fixed
 Keywords:  regression | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+

Comment (by Claude Paroz ):

 In [changeset:"d8fdee7db877e3a52a761bfcbeb3536ea219ec30"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d8fdee7db877e3a52a761bfcbeb3536ea219ec30"
 [1.6.x] Fixed #21472 -- Fixed inline formsets display when parent pk is 0

 Thanks agale031...@gmail.com for the report.
 Backport of fafb6cf049b 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/079.58fa30ab08d1f95b9d6b44f6ae1dbbf2%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] fafb6c: Fixed #21472 -- Fixed inline formsets display when...

2013-11-20 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: fafb6cf049bb9f4591a8b94cffda12c081cd096f
  
https://github.com/django/django/commit/fafb6cf049bb9f4591a8b94cffda12c081cd096f
  Author: Claude Paroz 
  Date:   2013-11-20 (Wed, 20 Nov 2013)

  Changed paths:
M django/forms/models.py
M docs/releases/1.6.1.txt
M tests/inline_formsets/tests.py

  Log Message:
  ---
  Fixed #21472 -- Fixed inline formsets display when parent pk is 0

Thanks agale031...@gmail.com for the report.



-- 
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/528d1d72ea780_703610cbd5859093%40hookshot-fe6-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21472: Django 1.6 ImageField not rendered properly in Admin inline form

2013-11-20 Thread Django

#21472: Django 1.6 ImageField not rendered properly in Admin inline form
---+
 Reporter:  agale031176@…  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.6
 Severity:  Normal |   Resolution:  fixed
 Keywords:  regression | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"fafb6cf049bb9f4591a8b94cffda12c081cd096f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="fafb6cf049bb9f4591a8b94cffda12c081cd096f"
 Fixed #21472 -- Fixed inline formsets display when parent pk is 0

 Thanks agale031...@gmail.com for the report.
 }}}

-- 
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/079.d966345556eab90caa7eed249409b6ee%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18456: HttpRequest.get_full_path does not escape # sign in the url

2013-11-20 Thread Django

Comment (by unaizalakain):

It seems that Django doesn't (in principle) log the successful requests
anywhere (the `PATH_INFO` WSGI environ is what gets logged both in
development and production). The only place where `get_full_path()` is
intended for human consumption is
`django.middleware.common.BrokenLinkEmailsMiddleware.process_response`
where it gets mailed. I would say that, in this case, it might be even
interesting to have the "correct" yet difficult to understand path
printed.

--
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/083.3696f0790b268bf684effaae5930a132%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21443: On PY3 if error on import, cannot show debug info

2013-11-20 Thread Django

#21443: On PY3 if error on import, cannot show debug info
--+
 Reporter:  bouke |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Python 3  |  Version:  1.6
 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 bouke):

 * has_patch:  0 => 1


Comment:

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

 The fix should probably also be backported to 1.6, as it will bite every
 user running Django on PY3 while working on a project's code.

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

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

Re: [Django] #21458: Encoding error on /jsi18n/?language=ü

2013-11-20 Thread Django

#21458: Encoding error on /jsi18n/?language=ü
-+-
 Reporter:  Sergey Sorokin   |Owner:  nobody
  <40inss@…> |   Status:  closed
 Type:  Bug  |  Version:  master
Component:   |   Resolution:  fixed
  Internationalization   | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:  UnicodeEncodeError,  |  Needs documentation:  0
  i18n, jsi18n   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Baptiste Mispelon ):

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


Comment:

 In [changeset:"8f5a688d00f2f73a0913acb04247322f13e2c971"]:
 {{{
 #!CommitTicketReference repository=""
 revision="8f5a688d00f2f73a0913acb04247322f13e2c971"
 Fixed #21458 -- Made check_for_language more resistant to malformed input.

 Thanks to Sergey Sorokin for the report and to Bouke Haarsma 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/091.38a646d4cac41040ad41bbae155bcd21%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 8f5a68: Fixed #21458 -- Made check_for_language more resis...

2013-11-20 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 8f5a688d00f2f73a0913acb04247322f13e2c971
  
https://github.com/django/django/commit/8f5a688d00f2f73a0913acb04247322f13e2c971
  Author: Baptiste Mispelon 
  Date:   2013-11-20 (Wed, 20 Nov 2013)

  Changed paths:
M django/utils/translation/trans_real.py
M tests/i18n/tests.py

  Log Message:
  ---
  Fixed #21458 -- Made check_for_language more resistant to malformed input.

Thanks to Sergey Sorokin for the report and to Bouke Haarsma for the review.



-- 
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/528ceae1a0cc0_707b10d5d587061f%40hookshot-fe6-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #5147: Translation inconsistency for Hungarian language (entry - entries)

2013-11-20 Thread Django

#5147: Translation inconsistency for Hungarian language (entry - entries)
-+-
 Reporter:  Szilveszter Farkas   |Owner:
   |   Status:  new
 Type:  Bug  |  Version:  master
Component:   |   Resolution:
  Internationalization   | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  i18n hu pl   |  Patch needs improvement:  0
  inconsistency i18n-nofix   |UI/UX:  0
Has patch:  0|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by bouke):

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


Comment:

 Deassigning as #11688 is a more fine grained approach

-- 
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/107.b3a0c41a462e7e9c36f54d9aa3dd3c48%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21469: makemigrations and normalize_unique_together

2013-11-20 Thread Django

#21469: makemigrations and normalize_unique_together
-+-
 Reporter:  django@… |Owner:  Baptiste
 Type:  Bug  |  Mispelon 
Component:  Migrations   |   Status:  closed
 Severity:  Normal   |  Version:  master
 Keywords:   |   Resolution:  fixed
Has patch:  1| Triage Stage:  Ready for
  Needs tests:  0|  checkin
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Baptiste Mispelon ):

 * owner:   => Baptiste Mispelon 
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"331d79a77d48e1a46df0290689d4d865e67221c4"]:
 {{{
 #!CommitTicketReference repository=""
 revision="331d79a77d48e1a46df0290689d4d865e67221c4"
 Fixed #21469 -- Allow set objects in Meta.unique_together.

 Thanks to Tim 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/081.f721e6cbe5f34519391e8d6678cd6ac7%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 331d79: Fixed #21469 -- Allow set objects in Meta.unique_t...

2013-11-20 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 331d79a77d48e1a46df0290689d4d865e67221c4
  
https://github.com/django/django/commit/331d79a77d48e1a46df0290689d4d865e67221c4
  Author: Baptiste Mispelon 
  Date:   2013-11-20 (Wed, 20 Nov 2013)

  Changed paths:
M django/db/models/options.py
M tests/validation/test_unique.py

  Log Message:
  ---
  Fixed #21469 -- Allow set objects in Meta.unique_together.

Thanks to Tim for the review.



-- 
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/528ce845281bf_2c15ec5d4c15343%40hookshot-fe2-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21458: Encoding error on /jsi18n/?language=ü

2013-11-20 Thread Django

#21458: Encoding error on /jsi18n/?language=ü
-+-
 Reporter:  Sergey Sorokin   |Owner:  nobody
  <40inss@…> |   Status:  new
 Type:  Bug  |  Version:  master
Component:   |   Resolution:
  Internationalization   | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:  UnicodeEncodeError,  |  Needs documentation:  0
  i18n, jsi18n   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by bouke):

 * stage:  Accepted => Ready for checkin


Comment:

 Patch is good to go.

-- 
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/091.2290b183a9e6db0898e91e13a87dd7f6%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21458: Encoding error on /jsi18n/?language=ü

2013-11-20 Thread Django

#21458: Encoding error on /jsi18n/?language=ü
-+-
 Reporter:  Sergey Sorokin   |Owner:  nobody
  <40inss@…> |   Status:  new
 Type:  Bug  |  Version:  master
Component:   |   Resolution:
  Internationalization   | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  UnicodeEncodeError,  |  Patch needs improvement:  0
  i18n, jsi18n   |UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by bmispelon):

 * has_patch:  0 => 1


Comment:

 PR here: https://github.com/django/django/pull/1947

 Feedback welcome.

-- 
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/091.2498aad9352773d1fbc319424e0aa7a3%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21474: ModelForm resets field when field not in data

2013-11-20 Thread Django

#21474: ModelForm resets field when field not in data
--+
Reporter: Mike Wyatt (wyatt.mike@… | Owner: nobody
Type: Uncategorized | Status: new
Component: Forms |Version: master
Severity: Normal| Keywords:
Triage Stage: Unreviewed| Has patch: 0
Easy pickings: 0 | UI/UX: 0
--+
After reading "Don't assume that missing fields from POST data are equal
to an empty string value" (https://groups.google.com/forum/#!topic/django-
developers/w8UKCLjOMpg), I still don't get how something like:

{{{
profile = Profile.objects.create(first_name='Tai', last_name='Lee',
address='Sydney')
form = ProfileForm({}, instance=profile)
if form.is_valid():
form.save()
}}}

clearing the existing fields on the form could be seen as intuitive. Or
how the Django co-creator Adrian Holovaty advises against using
ModelForms, something included in his framework.

My case is I've a `published_at` field on a model, and when the form is
submitted, that field is reset. I would expect it to stay the same.

Sure, there's the `fields` and `exclude` properties of the Meta class, but
things can still be mass-assigned via POST. Maybe take a page from other
frameworks that worked around this issue years ago?

I should mention this issue stems from using django-crispy-forms, where
I've never really had to use those properties on the form's meta class,
where one can easily design a form as they want, and are not limited to
tables or unordered lists.

--
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/076.c5ec396f6443f42db183a708bf5d8823%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6707: Another implementation for ReverseManyRelatedObjectsDescriptor.set method

2013-11-20 Thread Django

#6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__
method
-+-
 Reporter:  favo |Owner:  sfllaw
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by a.krille@…):

 Any news on this?

 We too are bidden by this bug (and it is a bug when a signal is documented
 but never actually emitted) and would love to see a proper fix.

-- 
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/080.d8f7bf307d2dc39603dbdbfc124d817a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18456: HttpRequest.get_full_path does not escape # sign in the url

2013-11-20 Thread Django

#18456: HttpRequest.get_full_path does not escape # sign in the url
-+-
 Reporter:  vlad.shcherbina@…|Owner:
 Type:  Bug  |  unaizalakain
Component:  HTTP handling|   Status:  assigned
 Severity:  Normal   |  Version:  master
 Keywords:   |   Resolution:
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by unaizalakain):

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


Comment:

 According to https://www.ietf.org/rfc/rfc2396.txt

 {{{
The path may consist of a sequence of path segments separated by a
single slash "/" character.  Within a path segment, the characters
"/", ";", "=", and "?" are reserved.  Each path segment may include a
sequence of parameters, indicated by the semicolon ";" character.
The parameters are not significant to the parsing of relative
references.
 }}}

 I would escape all "/", ";", "=" and "?" characters. The fragment isn't
 even contemplated because it's not strictly part of the URI:

 {{{
When a URI reference is used to perform a retrieval action on the
identified resource, the optional fragment identifier, separated from
the URI by a crosshatch ("#") character, consists of additional
reference information to be interpreted by the user agent after the
retrieval action has been successfully completed.  As such, it is not
part of a URI, but is often used in conjunction with a URI.
 }}}

 Personally, I consider the possible logging clarity problems less
 important than the problems arising from `HttpRequest.get_full_path()` bad
 behavior. If needed, logging could use some other function to print out
 the URI.

-- 
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/083.613b5ef59769a90848cfa14d01ece311%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21445: SelectFilter2.js: quickElement() is missing third argument

2013-11-20 Thread Django

#21445: SelectFilter2.js: quickElement() is missing third argument
-+-
 Reporter:  parsch.inc@… |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.6
Component:  Uncategorized|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bmispelon):

 * cc: bmispelon (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/078.508539daf64389c71a0718d3ea49ed76%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21445: SelectFilter2.js: quickElement() is missing third argument

2013-11-20 Thread Django

#21445: SelectFilter2.js: quickElement() is missing third argument
-+-
 Reporter:  parsch.inc@… |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.6
Component:  Uncategorized|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bmispelon):

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


Comment:

 Hi,

 While the proposed PR doesn't look like it would hurt, I can't really
 merge it until I can confirm that it does fix some issue and
 unfortunately, I can't reproduce the problem locally.

 On top of that, two other things bother me:
 * The code of `quickElement` looks like it'd prevent the issue you're
 describing.
 * There are other usage of `quickElement(foo, bar)` in Django's code. If
 there's indeed a bug, it should be fixed everywhere.


 If you could provide a way to reproduce the issue (a testcase would be
 ideal), it would go a long way towards closing this ticket.

 Thanks.

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

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

Re: [Django] #21022: Ensure URL naming is always preferred everywhere in the docs

2013-11-20 Thread Django

#21022: Ensure URL naming is always preferred everywhere in the docs
--+
 Reporter:  mjtamlyn  |Owner:
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by anonymous):

 Removing from myself as I don't anticipate having the time to dedicate to
 it in the next week or two and I have already held on to it too long. If
 it is still here when I have time again I will pick it back up.

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

Re: [Django] #21022: Ensure URL naming is always preferred everywhere in the docs

2013-11-20 Thread Django

#21022: Ensure URL naming is always preferred everywhere in the docs
--+
 Reporter:  mjtamlyn  |Owner:
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by saoili):

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


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

Re: [Django] #21473: Cookie based language detection no longer practical

2013-11-20 Thread Django

#21473: Cookie based language detection no longer practical
--+
 Reporter:  ludwik|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.6
 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 fine with proposal #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.ca9e1ae37367908b46c337deaa196ffc%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21461: Add pre_update and post_update signals

2013-11-20 Thread Django

Comment (by akaariai):

The latest solution is close to what charettes suggested in comment:3. The
biggest distinctions are that pre_update is given the to-be updated
queryset instead of to-be-updated queryset.filter(pk_in=pk_set), and for
post_update you don't get queryset, you just get pk_set.

The reason for going with pk_set is that in some cases the only thing you
need is the set of primary keys, and if that happens to be a large set,
then doing pk_in=pk_set query will be expensive (PostgreSQL doesn't like
this type of query at all, and SQLite will not even execute a query with
more than 1000 pk values.

A possible solution is to provide both the queryset (with pk_in=pk_set
filtering pre-applied), *and* the pk_set to pre_/post_ update signals.
That way the user has nice API if that is all that is needed, but can also
just use the pk_set if that is possible.

--
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.1974afcaa30b14dc46292a6be12db01c%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21473: Cookie based language detection no longer practical

2013-11-20 Thread Django

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

Comment:

The solution in #14825 seems a bit over-aggressive. The implementation in
there is "force-assign language back to session for each response". For
example this means it is impossible to force-clear the session language if
you actually want that. And it also means that the language is stored in
the session no matter if you actually want to use session to store the
language. As session language overrides cookie language this essentially
breaks cookie based language selection. This will also break a view that
does this:
{{{
def change_language(request, lang):
request.session['django_language'] = lang
return HttpResponseRedirect(somepage)
}}}
Some proposals for fix:
1. Assign the language back to session in contrib.auth.logout() right
after session.flush(). Revert the change to localemiddleware
2. In LocaleMiddleware, store the language back only if it came from
session. This can be done by setting request._language_was_from_session =
True in process_request and checking against that in process_response.
3. Just revert the change.

I don't particularly like the idea that you can't flush the language code
from session, and with option 2 above it will be force-restored on
process_response. So, I vote for approach 1. This means that
session.flush() will remove the language for next request. But if you
store the language in a session and then flush it, isn't that what is
supposed to happen?

I haven't actually ran any tests to verify this issue but the analysis in
the description are convincing enough for me. Marking this as release
blocker as this is a regression in 1.6.

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

Re: [Django] #21469: makemigrations and normalize_unique_together

2013-11-20 Thread Django

#21469: makemigrations and normalize_unique_together
+-
 Reporter:  django@…|Owner:
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | 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 timo):

 * 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/081.eaec0353e8a393ea995835b7e2cc9671%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #11722: Query lookups that reference an F() expression produce invalid sql

2013-11-20 Thread Django

#11722: Query lookups that reference an F() expression produce invalid sql
-+-
 Reporter:  plandry@…|Owner:
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  F() expression   |  Needs documentation:  0
  query sql  |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by mumino):

 * cc: mumino (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/078.c8b8260746e5729f0f5ddd638360031f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21473: Cookie based language detection no longer practical

2013-11-20 Thread Django

#21473: Cookie based language detection no longer practical
-+-
 Reporter:  ludwik   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.6
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by ludwik):

 Maybe behaviour requested by #14825 could by a setting, so it stops
 breaking backward compatibility?

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

Re: [Django] #21472: Django 1.6 ImageField not rendered properly in Admin inline form

2013-11-20 Thread Django

#21472: Django 1.6 ImageField not rendered properly in Admin inline form
---+
 Reporter:  agale031176@…  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.6
 Severity:  Normal |   Resolution:
 Keywords:  regression | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+

Comment (by akaariai):

 What about backpatching? This seems to be both in 1.5 and 1.6. Django 1.5
 is in security fixes only mode, and this clearly isn't a regression for
 1.6. The changes required here seem to be trivial, and possibility for new
 regressions seems really low, so I vote for backpatch to 1.6.

-- 
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/079.327e192d5e31285ba51f639b7d18084e%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21472: Django 1.6 ImageField not rendered properly in Admin inline form

2013-11-20 Thread Django

#21472: Django 1.6 ImageField not rendered properly in Admin inline form
---+
 Reporter:  agale031176@…  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.6
 Severity:  Normal |   Resolution:
 Keywords:  regression | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+
Changes (by claudep):

 * keywords:   => regression
 * component:  Uncategorized => Forms


Comment:

 OK, so this was introduced with the fix for #19524 ([e9c24bef74e5572] and
 [5097d3c5faab2] (1.5)).
 The problem is the test `if self.instance.pk:` in
 `BaseInlineFormSet.__init__` which should probably be `if self.instance.pk
 is not None:`.

-- 
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/079.cc00f29e2f35a6c4d98b2acaad39ec79%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21473: Cookie based language detection no longer practical

2013-11-20 Thread Django

#21473: Cookie based language detection no longer practical
-+-
 Reporter:  ludwik   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.6
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ludwik):

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


Comment:

 The change was caused by #14825.

-- 
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.69204d551eb2ec407a2d42845bb2%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18501: Custom fields as foreign keys fix

2013-11-20 Thread Django

#18501: Custom fields as foreign keys fix
-+-
 Reporter:  msopacua |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  RelatedField |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by maa@…):

 * cc: maa@… (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/066.239f94ca7d159fd53a5700fcd4162652%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21472: Django 1.6 ImageField not rendered properly in Admin inline form

2013-11-20 Thread Django

#21472: Django 1.6 ImageField not rendered properly in Admin inline form
---+
 Reporter:  agale031176@…  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.6
 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:  1
---+
Changes (by claudep):

 * stage:  Unreviewed => Accepted


Comment:

 I could reproduce and can confirm that this happens when object primary
 key = 0. The cause still needs to be investigated...

-- 
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/079.b15e8e22d4185b2d9892d91a08a4a112%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21473: Cookie based language detection no longer practical

2013-11-20 Thread Django

#21473: Cookie based language detection no longer practical
--+
Reporter: ludwik| Owner: nobody
Type: Bug | Status: new
Component: Internationalization |Version: 1.6
Severity: Normal| Keywords:
Triage Stage: Unreviewed| Has patch: 0
Easy pickings: 0 | UI/UX: 0
--+
I use cookies to save user's custom language preference (and that's not
just a matter of personal taste - I use Varnish, so it's important for me
to defer putting a session cookie on user's computer as long as possible,
because it is unique per user, so does not work good with caching).

Up until Django 1.6 I successfully used the following method:

1. Use Django's `LocaleMiddleware` so the correct locale is detected and
used.
2. When user switches languages set a cookie with her new preference, with
name based on `settings.LANGUAGE_COOKIE_NAME`.

I think that sounds pretty responsible and in line with what's in
documentation. And it worked as expected. `LocaleMiddleware` used the
cookie's value during language detection.

Unfortunately it all break after upgrading to Django 1.6. In Django 1.6
the following code was added to `LocaleMiddleware`'s `process_response()`
method:

{{{
# Store language back into session if it is not present
if hasattr(request, 'session'):
request.session.setdefault('django_language', language)
}}}

It has two unfortunate consequences for me. The former more obvious, the
latter more important:

1. Session cookie is now always present on user's computer. A session is
created as soon a she opens the site for the first time. That's defeats
the whole purpose of using `django_language` cookie instead of using
sessions.

2. When a user opens the site for the first time her current language is
saved to her session. She haven't had a chance to manually set her
preference yet, so the value set to session in based on request headers or
`LANGUAGE_CODE` settings. From now on `django_language` cookie value is
ignored (and for that matter her changing language preferences in her
browser is ignored also), because the value from session has the highest
priority.

So, to summarise: cookie value is ignored if session value is present, but
starting from Django 1.6 session value is always present.

My code broke after upgrading to Django 1.6, just because I used a cookie-
based method, that is part of documented Django futures. The '''only'''
way to use cookies for setting language now, is to disable sessions
completely in your project (not an option for me). That's a really big
change, and there is literally nothing about it in "backwards incompatible
changes" section of Django 1.6 release notes. I also don't see an easy
work around this problem for me.

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

Re: [Django] #21468: Django 1.5: Docs on ModelForm validation are wrong

2013-11-20 Thread Django

#21468: Django 1.5: Docs on ModelForm validation are wrong
-+-
 Reporter:  direx|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.5
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  model form   | Triage Stage:  Accepted
  validation |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Baptiste Mispelon ):

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


Comment:

 In [changeset:"ed8814b24a18cecdeb2631281bceb2f8432a2546"]:
 {{{
 #!CommitTicketReference repository=""
 revision="ed8814b24a18cecdeb2631281bceb2f8432a2546"
 Fixed #21468 -- Removed a ModelForm bit that doesn't apply to 1.5.x.

 The bit was incorrectly backported with
 3860d5e8f814e26baf4deee9258392cd34a4b456.

 Thanks to trac user direx for the report and to Loic Bistuer
 for his help.
 }}}

-- 
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.772916a75025a81517d276c24e2cd325%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] ed8814: Fixed #21468 -- Removed a ModelForm bit that doesn...

2013-11-20 Thread GitHub

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: ed8814b24a18cecdeb2631281bceb2f8432a2546
  
https://github.com/django/django/commit/ed8814b24a18cecdeb2631281bceb2f8432a2546
  Author: Baptiste Mispelon 
  Date:   2013-11-20 (Wed, 20 Nov 2013)

  Changed paths:
M docs/topics/forms/modelforms.txt

  Log Message:
  ---
  Fixed #21468 -- Removed a ModelForm bit that doesn't apply to 1.5.x.

The bit was incorrectly backported with 
3860d5e8f814e26baf4deee9258392cd34a4b456.

Thanks to trac user direx for the report and to Loic Bistuer
for his help.



-- 
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/528c86aca4040_2b1bb23d4c10264c%40hookshot-fe2-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21469: makemigrations and normalize_unique_together

2013-11-20 Thread Django

#21469: makemigrations and normalize_unique_together
+
 Reporter:  django@…|Owner:
 Type:  Bug |   Status:  new
Component:  Migrations  |  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 bmispelon):

 * cc: bmispelon (added)
 * has_patch:  0 => 1


Comment:

 What about simply forcing `unique_together` to be a tuple at the beginning
 of `normalize_unique_together()`?

 PR (with tests) here: https://github.com/django/django/pull/1946

-- 
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/081.890e2a825d6310c4400b44df46d88a09%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18501: Custom fields as foreign keys fix

2013-11-20 Thread Django

#18501: Custom fields as foreign keys fix
-+-
 Reporter:  msopacua |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  RelatedField |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by maa@…):

 * cc: maa@… (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.94174fe1771c47b8e016801652c952a0%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #11722: Query lookups that reference an F() expression produce invalid sql

2013-11-20 Thread Django

Comment (by mumino):

invalid sql generation happens for iendswith, istartswith, icontains,
iexact for postgreql. similar problems arise in SQLite. I think other
backends have same problem too.

this pull request has a fix. https://github.com/django/django/pull/1945

on the other hand, F objects has another issue related with here.
https://code.djangoproject.com/ticket/16731

because of it istartswith, icontains, iendswith still don't produce
correct SQL. but they produce valid SQL now.

--
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/078.00cd835051546ab60271214d731ae237%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21472: Django 1.6 ImageField not rendered properly in Admin inline form

2013-11-20 Thread Django

#21472: Django 1.6 ImageField not rendered properly in Admin inline form
---+--
 Reporter:  agale031176@…  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.6
 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:  1
---+--

Comment (by anonymous):

 Here is the code that I have that works in 1.4.9 but not in later
 releases:

 In the '''models.py''':

 class Property(models.Model):
 property_id = models.IntegerField(primary_key=True, default=0)
 title = models.CharField(max_length=250, null=False)
 village = models.ForeignKey(Village, 'name')

 class PropertyImages(models.Model):
 property_id = models.ForeignKey(Property)
 image_path = models.ImageField(null=False, upload_to='test')

 Then in the '''admin.py''':

 class PropertyImagesAdmin(admin.TabularInline):
 model = PropertyImages
 fields = ['image_path']

 class PropertyAdmin(admin.ModelAdmin):
 fields = [
 'title', 'village'
 ]

 inlines = [
 PropertyImagesAdmin,
 ]


 admin.site.register(Property, PropertyAdmin)

 I am not sure if Django is the problem or I have to do this differently in
 later 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/079.72228d7cd2c7b206882a3e624b4d0ba5%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

52 matches

Mail list logo