Re: [Django] #17642: min_num on admin inline formsets

2014-05-13 Thread Django
#17642: min_num on admin inline formsets
-+-
 Reporter:   |Owner:  melinath
  krzysztof.szczesny@…   |   Status:  assigned
 Type:  New feature  |  Version:
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  admin min_num|  Needs documentation:  0
  formsets   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  1
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by melinath):

 @timo: I've run into some strange behavior - see my note on #9532. Would
 it be reasonable for me to integrate a fix into just the modelformset
 behavior, in your opinion?

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


Re: [Django] #9532: Add min_num and validate_min on formsets

2014-05-13 Thread Django
#9532: Add min_num and validate_min on formsets
-+-
 Reporter:  gsf  |Owner:  yokomizor
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by melinath):

 @timo I would set min_num=3 if there should be at least three things. I
 would set extra=3 if I wanted three blank forms presented.

 The implementation here means that there will *always* be '''six''' blank
 forms - existing objects are *not* taken into account.

 To put it another way, if min_num is 3, and extra is 2, and there are
 already 2 existing objects, I would expect to have either 4 forms (2 extra
 on top of existing objects) or 5 forms (2 extra on top of the minimum.)
 With the code as it is, I will instead get '''seven forms''' - two for the
 existing objects, and an additional seven from extra.

 Ran into this behavior while working on #17642. Possible this is only a
 modelformset 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/061.d3a76e3f58aebe932338646600a29b76%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #22620: "Multiple databases" chapter of docs says 'default':{} can start DATABASES setting; Django says no

2014-05-13 Thread Django
#22620: "Multiple databases" chapter of docs says 'default':{} can start 
DATABASES
setting; Django says no
-+-
 Reporter:  moc@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.6
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  multiple_databases   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by moc@…):

 * status:  closed => new
 * version:  1.5 => 1.6
 * resolution:  invalid =>


Comment:

 I'll deal with the "For n"'s of timo in turn:

 "For 1, I don't see an issue as the default database is being used to
 store sessions, hence the error. It is possible to configure Django so the
 default database isn't used, but you haven't done that."

 This about the ticket referring to the fact that the "Multiple databases"
 chapter clearly states and shows, with text and code, that you can, if you
 need to, start the DATABASES setting with 'default':{}... with an empty
 dictionary in place of the parameters for your first database, with
 'mydb1':{usual params}, 'mydb2':{usual params} to follow.

 So this ticket is of course about how the documentation of the "Multiple
 databases" chapter works or fails to work; it's not about how Django
 works. And the question is `if after following the instructions and code
 example of the 'default':{} approach, how is anyone to know FROM THIS
 CHAPTER that there is some other required step with which it "is possible
 to configure Django so the default database isn't used"--- that the reader
 might thus avoid the error?' Why isn't there an immediate mention of the
 need for this other configuration step, right next to the code example for
 the empty 'default' dictionary approach?

 Perhaps a core developer can read the provided traceback, which pertains
 entirely to django internals, and immediately know what to do. But we do
 not acquire and use frameworks so that we can learn all of the source code
 and how it works.

 On to the next For...

 "For 2, I believe your initial interpretation is correct (there's the
 reference to "synchronizing these three models"). I think it'll be safer
 not to change this text."

 Yes the ticket is nit-picky on that one, as it admits, but note especially
 that it says that I tested deleting ALL of the objects from my second
 database other than the tables from the models from one of my apps, the
 only app that uses the second database--- not just those three objects.
 There are no resultant problems. I did the deleting using "manage.py
 dbshell --database=mydb2", which opens the default sqlite2 database
 manager which allows me, with a ".tables" command to clearly see all of
 the tables and with SQL DROP statements to delete any one of them. Not
 only am I able to read and write to the two databases separately through
 views in different apps but I have implemented a "class
 MultiDBModelAdmin(admin.ModelAdmin):" and "class
 Mydb2AdminSite(AdminSite):" as advised in this chapter so as to have
 separate admin pages for each database--- and that works fine with all of
 the objects that are discussed in
 https://docs.djangoproject.com/en/1.6/topics/db/multi-db/#behavior-of-
 contrib-apps deleted from mydb2, not with just the three deleted. So maybe
 my initial interpretation is not correct. My test rather strongly suggests
 that it is not.

 And now for the last For...

 "For 3, I think the best approach is to use the ​--database flag to
 syncdb. Note that syncdb is replaced by migrate in 1.7 and this command
 doesn't have a similar flag, so I guess the approach will be different
 there."

 About the latter tip, be advised that
 https://docs.djangoproject.com/en/1.7/topics/db/multi-db/#synchronizing-
 your-databases clearly shows a --database flag in use with migrate.
 However, timo is probably right about its demise because whereas
 https://docs.djangoproject.com/en/1.6/ref/django-admin/#syncdb shows the
 --database option https://docs.djangoproject.com/en/1.7/ref/django-admin
 /#django-admin-migrate does not. Something has to give there in one or the
 other of those chapters. Basically "I guess the approach will be different
 there" will have to be replaced by an actual approach.

 About "the best approach is to use the ​--database flag to syncdb",
 strangely, the entire https://docs.djangoproject.com/en/1.6/topics/db
 /multi-db/#behavior-of-contrib-apps is offered in contradiction of the
 earlier https://docs.djangoproject.com/en/1.6/topics/db/multi-db
 /#synchronizing-your-databases 

[django/django] 50f228: [1.7.x] Removed an unnecessary anchor in the docs.

2014-05-13 Thread GitHub
  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: 50f228ae7c7d5eb68c1544423dcb3dfa31f2dc74
  
https://github.com/django/django/commit/50f228ae7c7d5eb68c1544423dcb3dfa31f2dc74
  Author: Tim Graham 
  Date:   2014-05-13 (Tue, 13 May 2014)

  Changed paths:
M docs/ref/contrib/admin/index.txt
M docs/releases/1.2.txt

  Log Message:
  ---
  [1.7.x] Removed an unnecessary anchor in the docs.

Backport of a06808d370 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/5372bef0cb2af_294ef8dd385789f%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


[django/django] e05a62: [1.6.x] Removed an unnecessary anchor in the docs.

2014-05-13 Thread GitHub
  Branch: refs/heads/stable/1.6.x
  Home:   https://github.com/django/django
  Commit: e05a6222cd409bbfd9fd060a3913a956014dc4ab
  
https://github.com/django/django/commit/e05a6222cd409bbfd9fd060a3913a956014dc4ab
  Author: Tim Graham 
  Date:   2014-05-13 (Tue, 13 May 2014)

  Changed paths:
M docs/ref/contrib/admin/index.txt
M docs/releases/1.2.txt

  Log Message:
  ---
  [1.6.x] Removed an unnecessary anchor in the docs.

Backport of a06808d370 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/5372beeebde96_78e71149d34101240%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


[django/django] a06808: Removed an unnecessary anchor in the docs.

2014-05-13 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: a06808d370ab2216562720efde1fd3e4f85486ad
  
https://github.com/django/django/commit/a06808d370ab2216562720efde1fd3e4f85486ad
  Author: Tim Graham 
  Date:   2014-05-13 (Tue, 13 May 2014)

  Changed paths:
M docs/ref/contrib/admin/index.txt
M docs/releases/1.2.txt

  Log Message:
  ---
  Removed an unnecessary anchor in the docs.


-- 
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/5372bed93eb59_315258fd40150698%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #22617: Allow to fix translation -> Fix makemessages to not delete debug data and hide errors (and all similar modules using "msgmerge")

2014-05-13 Thread Django
#22617: Allow to fix translation -> Fix makemessages to not delete debug data 
and
hide errors (and all similar modules using "msgmerge")
---+--
 Reporter:  Cezary.Wagner  |Owner:  nobody
 Type:  Uncategorized  |   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:  0
---+--

Comment (by timo):

 I will let someone more familiar with `makemessages` make a call on
 whether or not anything needs to be done here, but for some more context,
 I also closed #22615 and #22616 which are related.

 I do see `--keep-pot` in the help for `makemessages` on 1.6 (I'm not sure
 if that's what you are saying in the above comment).

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

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


Re: [Django] #17642: min_num on admin inline formsets

2014-05-13 Thread Django
#17642: min_num on admin inline formsets
-+-
 Reporter:   |Owner:  melinath
  krzysztof.szczesny@…   |   Status:  assigned
 Type:  New feature  |  Version:
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  admin min_num|  Needs documentation:  0
  formsets   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  1
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by melinath):

 * owner:  asteinlein => melinath


Comment:

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


Re: [Django] #22432: Switching model on an M2M field results in a broken db (no change to the automatic through table)

2014-05-13 Thread Django
#22432: Switching model on an M2M field results in a broken db (no change to the
automatic through table)
-+--
 Reporter:  melinath |Owner:
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7-beta-1
 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 melinath):

 Yes, I can still replicate this with the latest 1.7, using the method
 described by bmispelon. After creating the models and then creating and
 running the migrations, the database looks like this:

 {{{
 sqlite> .schema brambling_baz_m2m
 CREATE TABLE "brambling_baz_m2m" ("id" integer NOT NULL PRIMARY KEY
 AUTOINCREMENT, "baz_id" integer NOT NULL REFERENCES "brambling_baz"
 ("id"), "foo_id" integer NOT NULL REFERENCES "brambling_foo" ("id"),
 UNIQUE ("baz_id", "foo_id"));
 CREATE INDEX brambling_baz_m2m_60ef55ec ON "brambling_baz_m2m" ("baz_id");
 CREATE INDEX brambling_baz_m2m_a8d1fe7d ON "brambling_baz_m2m" ("foo_id");
 }}}

 The second FK *should* be `bar_id` and reference `brambling_bar ("id")`.

 Behavior that would make sense to me:

 1. Delete the through table (perhaps with a warning when creating the
 migration), then create the new table.
 2. Raise an error to prevent this type of change for now until a better
 solution is found.

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


Re: [Django] #22627: Error when adding a new user through the admin and using custom user model.

2014-05-13 Thread Django
#22627: Error when adding a new user through the admin and using custom user 
model.
-+--
 Reporter:  jacobeharding@…  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Uncategorized|  Version:  1.6
 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 anonymous):

 * resolution:  wontfix => invalid


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


Re: [Django] #22627: Error when adding a new user through the admin and using custom user model.

2014-05-13 Thread Django
#22627: Error when adding a new user through the admin and using custom user 
model.
-+--
 Reporter:  jacobeharding@…  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Uncategorized|  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 alasdair):

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


Comment:

 This is a duplicate of #20086 and #21407, which were closed as invalid.

 The user creation form is working
 [https://docs.djangoproject.com/en/1.6/topics/auth/customizing/#custom-
 users-and-the-built-in-auth-forms as documented]. It depends on the user
 model, and must be re-written for any custom model.

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


Re: [Django] #21230: Remove usage of direct settings manipulation in Django's tests

2014-05-13 Thread Django
#21230: Remove usage of direct settings manipulation in Django's tests
--+
 Reporter:  akaariai  |Owner:  whoshuu
 Type:  Cleanup/optimization  |   Status:  assigned
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 whoshuu):

 There is still a pull request that references this ticket
 [https://github.com/django/django/pull/2525 here]. The outstanding issue
 is whether `staticfiles_tests/project/site_media/static/testfile.txt` is
 deleted after running the affected test code. Reviewing the history of
 that file, it seems to be vestigial and can safely be removed from source
 control. The pull request currently doesn't remove it itself, but it can.

 It would be helpful if someone can take a look at this and decide if the
 refactor is worth taking this additional step. Otherwise, I can close the
 PR and unassign this ticket.

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

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


[Django] #22627: Error when adding a new user through the admin and using custom user model.

2014-05-13 Thread Django
#22627: Error when adding a new user through the admin and using custom user 
model.
-+
 Reporter:  jacobeharding@…  |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Uncategorized|Version:  1.6
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 I see a programming error when adding a user through the admin and using a
 custom user model.  I believe this is caused in contrib/auth/forms.py on
 line 98 referring the auth.user model and not the custom user model.

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


Re: [Django] #22563: Migration of admin.LogEntry.user fails.

2014-05-13 Thread Django
#22563: Migration of admin.LogEntry.user fails.
-+
 Reporter:  efrinut@…|Owner:  andrewgodwin
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by beathan):

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


Re: [Django] #22617: Allow to fix translation -> Fix makemessages to not delete debug data and hide errors (and all similar modules using "msgmerge")

2014-05-13 Thread Django
#22617: Allow to fix translation -> Fix makemessages to not delete debug data 
and
hide errors (and all similar modules using "msgmerge")
---+--
 Reporter:  Cezary.Wagner  |Owner:  nobody
 Type:  Uncategorized  |   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:  0
---+--

Comment (by Cezary.Wagner):

 Push Request on github is related.

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

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


Re: [Django] #22617: Allow to fix translation -> Fix makemessages to not delete debug data and hide errors (and all similar modules using "msgmerge")

2014-05-13 Thread Django
#22617: Allow to fix translation -> Fix makemessages to not delete debug data 
and
hide errors (and all similar modules using "msgmerge")
---+--
 Reporter:  Cezary.Wagner  |Owner:  nobody
 Type:  Uncategorized  |   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:  0
---+--

Comment (by Cezary.Wagner):

 Not known about such option but should not help too much since many bugs
 is in code - see my pulls on github.

 1. Messages from msgmerge is not presented since bug - exception blocks
 print out.
 2. --keep-pot is not presented in --help I think so (not checked but never
 seen it before - o.k. since it from 1.6).

 I think problem is with "blocktrans" on 60% - I gave up now - I was done
 very large project more than 1k strings.

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

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


[Django] #22626: SQLite's DatabaseSchemaEditor.quote_value trips on buffer and memoryview instances

2014-05-13 Thread Django
#22626: SQLite's DatabaseSchemaEditor.quote_value trips on buffer and memoryview
instances
-+-
   Reporter:  loic84 |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  layer (models, ORM)|   Keywords:
   Severity:  Release|  Has patch:  0
  blocker|Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 Since e9a456d11b5b63389b466ed435ef3915f0e79e4c  default values for
 migrations go through `get_db_prep_save()` which in case of `BinaryField`
 results in `buffer` (PY2) or `memoryview` (PY3) instances. This causes a
 `ValueError` since `quote_value()` doesn't specifically support these
 types:
 
https://github.com/django/django/blob/master/django/db/backends/sqlite3/schema.py#L32.

 The test case for #22424 (https://github.com/django/django/pull/2634)
 demonstrates the issue.

 Dunno if it's relevant but the Oracle backend falls back to `str` rather
 than raising an exception:
 
https://github.com/django/django/blob/master/django/db/backends/oracle/schema.py#L28

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


Re: [Django] #22605: Impossible to delete two models with a M2M field

2014-05-13 Thread Django
#22605: Impossible to delete two models with a M2M field
-+--
 Reporter:  andrewgodwin |Owner:  andrewsg
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   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 andrewsg):

 I have a prototype autodetector-based solution, but I'm not happy with it
 -- it adds a substantial bit of code to the monolithic _detect_chagnes
 function (similar to how the autodetector has a 3.1-phase process for
 adding models, it becomes a two or three phase process for removing
 models).  I'll want to consult with a core dev before going further down
 this path, because I don't know how complex the alternative state_forward-
 based solution would be.

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


[Django] #22625: Installing pytz breaks code already using django's timezone module

2014-05-13 Thread Django
#22625: Installing pytz breaks code already using django's timezone module
-+
 Reporter:  tom.michaelis@…  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Utilities|Version:  1.6
 Severity:  Normal   |   Keywords:  pytz, timezone
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 pytz is an optional module for Django, used in django.utils.timezone (and
 possibly elsewhere). The documentation recommends that pytz is installed,
 but it's not a requirement.

 The bug is that after installing pytz, methods in django's timezone module
 do not present the same interface as before installation. Installing an
 optional module should not adjust the interface presented.

 The following code works differently before and after installation of
 pytz:

 {{{
 from django.utils import timezone

 now = timezone.now()
 timezone.make_aware(now, timezone.utc())
 }}}

 Before installing pytz, timezone.make_aware essentially does nothing (the
 variable is already timezone aware). After installing pytz,
 timezone.make_aware makes a call to pytz which raises 'ValueError: Not
 naive datetime (tzinfo is already set)', and causes everything to break.

 While I discovered this in django 1.5, I've also been able to replicate
 the bug in django 1.6, so I am filing the bug report under that.

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


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

2014-05-13 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
---+
Changes (by danielsamuels):

 * cc: danielsamuels (added)


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

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


Re: [Django] #22624: readonly form widget modified by new Firefox number input

2014-05-13 Thread Django
#22624: readonly form widget modified by new Firefox number input
-+-
 Reporter:  burton449geo@…   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Forms|  Version:  1.6
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  form firefox | Triage Stage:
  readonly   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

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


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


Re: [Django] #22624: readonly form widget modified by new Firefox number input

2014-05-13 Thread Django
#22624: readonly form widget modified by new Firefox number input
-+-
 Reporter:  burton449geo@…   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Forms|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  form firefox | Triage Stage:
  readonly   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timo):

 Isn't this a browser bug and not something we can/should fix in Django?

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


Re: [Django] #22624: readonly form widget modified by new Firefox number input

2014-05-13 Thread Django
#22624: readonly form widget modified by new Firefox number input
-+-
 Reporter:  burton449geo@…   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Forms|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  form firefox | Triage Stage:
  readonly   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by burton449geo@…):

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


Comment:

 Refer to this Firefox ticket:
 https://bugzilla.mozilla.org/show_bug.cgi?id=982189

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


[Django] #22624: readonly form widget modified by new Firefox number input

2014-05-13 Thread Django
#22624: readonly form widget modified by new Firefox number input
+---
 Reporter:  burton449geo@…  |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Component:  Forms   |Version:  1.6
 Severity:  Normal  |   Keywords:  form firefox readonly
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+---
 In Firefox v.29.1, the input for type=number has up/down arrows that can
 modified the form even if readonly is set to True.

 

 This input above cannot be edited with keyboard but can be with up/down
 arrow.

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


Re: [Django] #22485: makemigrations fails with dependencies to unmigrated apps

2014-05-13 Thread Django
#22485: makemigrations fails with dependencies to unmigrated apps
-+-
 Reporter:  apollo13 |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  migrations,  | Triage Stage:  Accepted
  unmigrated, makemigrations |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by hjwp):

 no worries.  Thanks for all the hard 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/066.c2c2eccbec489388d55b46921742bb5c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #22485: makemigrations fails with dependencies to unmigrated apps

2014-05-13 Thread Django
#22485: makemigrations fails with dependencies to unmigrated apps
-+-
 Reporter:  apollo13 |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  migrations,  | Triage Stage:  Accepted
  unmigrated, makemigrations |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by andrewgodwin):

 No, the next release will be RC1, as the date for that was May 1st so
 we're already behind.

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


Re: [Django] #22485: makemigrations fails with dependencies to unmigrated apps

2014-05-13 Thread Django
#22485: makemigrations fails with dependencies to unmigrated apps
-+-
 Reporter:  apollo13 |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  migrations,  | Triage Stage:  Accepted
  unmigrated, makemigrations |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by hjwp):

 Will this be rolled up into an updated beta release?  I'm advising my book
 readers to use 1.7b1 for 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/066.a0b613cebab54f47878b75e95b090e07%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #21634: Lis of installed apps set to empty when ImproperlyConfigured exception is raised

2014-05-13 Thread Django
#21634: Lis of installed apps set to empty when ImproperlyConfigured exception 
is
raised
-+-
 Reporter:  nikolay.v.golub@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.6
Component:  Core (Management |   Resolution:
  commands)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  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/083.c250276845723f9d299152446458f589%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[django/django] 1165e9: Fixed spelling mistake and added a word to the wor...

2014-05-13 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 1165e9992ee83a7706a6cc2f6fd3e2e31cacc97c
  
https://github.com/django/django/commit/1165e9992ee83a7706a6cc2f6fd3e2e31cacc97c
  Author: Tim Graham 
  Date:   2014-05-13 (Tue, 13 May 2014)

  Changed paths:
M docs/releases/1.7.txt
M docs/spelling_wordlist

  Log Message:
  ---
  Fixed spelling mistake and added a word to the word list.


-- 
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/53721b63385d0_29e4853d38880dd%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


[django/django] fb9edf: [1.7.x] Fixed spelling mistake and added a word to...

2014-05-13 Thread GitHub
  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: fb9edfa3e637edcbcdd0fafbb905209a906e75af
  
https://github.com/django/django/commit/fb9edfa3e637edcbcdd0fafbb905209a906e75af
  Author: Tim Graham 
  Date:   2014-05-13 (Tue, 13 May 2014)

  Changed paths:
M docs/releases/1.7.txt
M docs/spelling_wordlist

  Log Message:
  ---
  [1.7.x] Fixed spelling mistake and added a word to the word list.

Backport of 1165e9992e 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/53721b74e7dae_70cc83d40386ac%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #18134: BoundField.label_tag should include form.label_suffix

2014-05-13 Thread Django
#18134: BoundField.label_tag should include form.label_suffix
-+-
 Reporter:  Evil Clay|Owner:
    |  gabejackson
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.4
Component:  Forms|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  forms|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Tim Graham ):

 In [changeset:"5eb81ce44532596ecc1c781d93f3421a467a6206"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5eb81ce44532596ecc1c781d93f3421a467a6206"
 Fixed #22533 -- Added label_suffix parameter to form fields.

 Fields can now receive the `label_suffix` attribute, which will override
 a form's `label_suffix`.

 This enhances the possibility to customize form's `label_suffix`, allowing
 to use such customizations while using shortcuts such as
 `{{ form.as_p }}`.

 Note that the field's own customization can be overridden at runtime by
 using the `label_prefix` parameter to `BoundField.label_tag()`.

 Refs #18134.
 }}}

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


Re: [Django] #22533: Allow overriding `label_suffix` on a per-field basis

2014-05-13 Thread Django
#22533: Allow overriding `label_suffix` on a per-field basis
-+
 Reporter:  julen|Owner:  julen
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"5eb81ce44532596ecc1c781d93f3421a467a6206"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5eb81ce44532596ecc1c781d93f3421a467a6206"
 Fixed #22533 -- Added label_suffix parameter to form fields.

 Fields can now receive the `label_suffix` attribute, which will override
 a form's `label_suffix`.

 This enhances the possibility to customize form's `label_suffix`, allowing
 to use such customizations while using shortcuts such as
 `{{ form.as_p }}`.

 Note that the field's own customization can be overridden at runtime by
 using the `label_prefix` parameter to `BoundField.label_tag()`.

 Refs #18134.
 }}}

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


[django/django] 5eb81c: Fixed #22533 -- Added label_suffix parameter to fo...

2014-05-13 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 5eb81ce44532596ecc1c781d93f3421a467a6206
  
https://github.com/django/django/commit/5eb81ce44532596ecc1c781d93f3421a467a6206
  Author: Julen Ruiz Aizpuru 
  Date:   2014-05-13 (Tue, 13 May 2014)

  Changed paths:
M django/forms/fields.py
M django/forms/forms.py
M docs/ref/forms/api.txt
M docs/ref/forms/fields.txt
M docs/releases/1.8.txt
M tests/forms_tests/tests/test_forms.py

  Log Message:
  ---
  Fixed #22533 -- Added label_suffix parameter to form fields.

Fields can now receive the `label_suffix` attribute, which will override
a form's `label_suffix`.

This enhances the possibility to customize form's `label_suffix`, allowing
to use such customizations while using shortcuts such as
`{{ form.as_p }}`.

Note that the field's own customization can be overridden at runtime by
using the `label_prefix` parameter to `BoundField.label_tag()`.

Refs #18134.


-- 
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/53721a5830008_371ba7d405584d%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


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

2014-05-13 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 nastasi-oq):

 Using the silvexfix branch ​https://github.com/silverfix/django-nested-
 inlines I found a problem if I enable the 'save_as' feature in the
 ModelAdmin and ''save as new'' a previous stored record. I'm forced to use
 django 1.5.
 Could someone confirm it ? If yes: some suggestion about how to fix the
 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/067.6963fa80fae6ea21e905e19ec0798262%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #22623: PermLookupDict behaves dangerously / inconsistently

2014-05-13 Thread Django
#22623: PermLookupDict behaves dangerously / inconsistently
-+-
 Reporter:  rob.moore@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  PermLookupDict   | Triage Stage:
  permissions|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by evolter):

 While checking perms for existing app but not existing permission (caused
 e.g. by typo) like {{ perms.auth.anything }} will return True by default,
 which imho should be defaulted to False as it seems quite dangerous about
 perms to allow for anything.

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


Re: [Django] #22623: PermLookupDict behaves dangerously / inconsistently

2014-05-13 Thread Django
#22623: PermLookupDict behaves dangerously / inconsistently
-+-
 Reporter:  rob.moore@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  PermLookupDict   | Triage Stage:
  permissions|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

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


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

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


[Django] #22623: PermLookupDict behaves dangerously / inconsistently

2014-05-13 Thread Django
#22623: PermLookupDict behaves dangerously / inconsistently
---+
 Reporter:  rob.moore@…|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  master
 Severity:  Normal |   Keywords:  PermLookupDict permissions
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 While checking permissions within a template, I noticed that a typo of

 {% if perms.auth.change_user %}

 to

 {% if perms.auth_change_user %}

 for example, causes the statement to be evaluated as True if the
 authenticated user has any permissions, as perms.any_arbitrary_key returns
 a PermLookupDict, which has a __repr__ method which returns a stringified
 set of all the user's permissions. This seems dangerous and unusual, as
 most typos checking user permissions will result is the user being
 silently given privileges they should not have; it also seems unreasonable
 that perms.anything_you_want should return the full set of permissions:
 the PermLookupDict represents permissions for the specified app, not all
 permissions, and the return value of __repr__ should reflect that (i.e.
 return a set of permissions within that app, if anything).

 The class' __repr__ and __bool__ methods also seem inconsistent in that
 the latter does behave as I describe, checking that the user has a
 permission within the module for which the PermLookupDict is constructed.

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

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


Re: [Django] #22617: Allow to fix translation -> Fix makemessages to not delete debug data and hide errors (and all similar modules using "msgmerge")

2014-05-13 Thread Django
#22617: Allow to fix translation -> Fix makemessages to not delete debug data 
and
hide errors (and all similar modules using "msgmerge")
---+--
 Reporter:  Cezary.Wagner  |Owner:  nobody
 Type:  Uncategorized  |   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:  0
---+--

Comment (by timo):

 This [https://github.com/django/django/pull/2648 PR] appears related.

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

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


Re: [Django] #22621: Return JSON response in default error handlers for ajax requests

2014-05-13 Thread Django
#22621: Return JSON response in default error handlers for ajax requests
-+--
 Reporter:  Elvard   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by timo):

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


Comment:

 The main issue I see is that I'm not sure there's a standard format for
 returning JSON errors. I found [https://pypi.python.org/pypi/django-
 jsonview/0.3.0 django-jsonview] which returns
 {{{
 json.dumps({
 'error': STATUS_CODE,
 'message': str(exception),
 })
 }}}
 which seems reasonable. I'm not convinced this functionality needs to live
 in Django since it's easy to redefine the error handlers based on your
 needs, but I'll leave it open for a second opinion.

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


Re: [Django] #22609: Allow specifying the form field when instantiating a model field

2014-05-13 Thread Django
#22609: Allow specifying the form field when instantiating a model field
---+--
 Reporter:  django@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  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
---+--

Comment (by django@…):

 OK, I agree that coupling models/forms isn't great (even though modelForm
 and models are already coupled right?)

 I've come across quite a few limitations with subclassing/extending forms
 from models today so it's definitely something to discuss. 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.0f690ecd7bc67df884133d1a0210dc57%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #22609: Allow specifying the form field when instantiating a model field

2014-05-13 Thread Django
#22609: Allow specifying the form field when instantiating a model field
---+--
 Reporter:  django@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  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 timo):

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


Comment:

 I don't think the idea of specifying a form field on the model is going to
 fly since we don't want to add coupling like that between models and
 forms.

 Consider using
 `label=MyModel._meta.get_field('home_delivery').verbose_name` to make it
 more DRY.

 I don't think pulling unspecified kwargs from the model would be backwards
 compatible as you might have options changing on existing model form
 fields that are redefined on the form.

 I'm not saying the current situation is great, but I don't see a viable
 solution proposed here. Feel free to start a discussion on django-
 developers if you'd like to continue the discussion on how this can be
 improved.

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


Re: [Django] #22622: Add imports for ugettext_lazy in documentation (was: Multiple _'s are in the code, although they shouldn't be.)

2014-05-13 Thread Django
#22622: Add imports for ugettext_lazy in documentation
--+
 Reporter:  anonymous |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  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:  1 |UI/UX:  0
--+
Changes (by timo):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * keywords:  code error =>
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Actually the code is correct, but we could add the following import to
 help clarify: `from django.utils.translation import ugettext_lazy as _`

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


Re: [Django] #22620: "Multiple databases" chapter of docs says 'default':{} can start DATABASES setting; Django says no

2014-05-13 Thread Django
#22620: "Multiple databases" chapter of docs says 'default':{} can start 
DATABASES
setting; Django says no
-+-
 Reporter:  moc@…|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.5
Component:  Documentation|   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:  multiple_databases   |  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:

 Thanks for the suggestions. I don't really see any issues with the points
 you've raised, but feel free to reopen this ticket if you want to provide
 a patch for anything that could be clarified.

 For 1, I don't see an issue as the default database is being used to store
 sessions, hence the error. It is possible to configure Django so the
 default database isn't used, but you haven't done that.

 For 2, I believe your initial interpretation is correct (there's the
 reference to "synchronizing these three models"). I think it'll be safer
 not to change this text.

 For 3, I think the best approach is to use the
 [https://docs.djangoproject.com/en/1.5/ref/django-admin/#django-admin-
 option---database --database] flag to `syncdb`. Note that `syncdb` is
 replaced by `migrate` in 1.7 and this command doesn't have a similar flag,
 so I guess the approach will be different there.

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

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


[Django] #22622: Multiple _'s are in the code, although they shouldn't be.

2014-05-13 Thread Django
#22622: Multiple _'s are in the code, although they shouldn't be.
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.6
 Severity:  Normal |   Keywords:  code error
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 It shouldn't say:

 {{{
 _("This writer's name is too long.")
 }}}
 it should say:

 {{{
 ("This writer's name is too long.")
 }}}
 (in other words, it shouldn't have the underscore)

 The code below was taken from:
 https://docs.djangoproject.com/en/1.6/topics/forms/modelforms/#overriding-
 the-default-fields

 {{{
 class AuthorForm(ModelForm):
 class Meta:
 model = Author
 fields = ('name', 'title', 'birth_date')
 labels = {
 'name': _('Writer'),
 }
 help_texts = {
 'name': _('Some useful help text.'),
 }
 error_messages = {
 'name': {
 'max_length': _("This writer's name is 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/052.616cd105000340394e4c27aa0085ed15%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #22616: CommandError exception no prints message - instead always is "django.core.management.base.CommandError"

2014-05-13 Thread Django
#22616: CommandError exception no prints message - instead always is
"django.core.management.base.CommandError"
---+--
 Reporter:  Cezary.Wagner  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.6
 Severity:  Normal |   Resolution:  worksforme
 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:   => worksforme


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

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


[django/django] bff0eb: [1.6.x] Fixed typo in transactions.txt

2014-05-13 Thread GitHub
  Branch: refs/heads/stable/1.6.x
  Home:   https://github.com/django/django
  Commit: bff0eb3b24f94831832f89913a4bcc8c3ee94d80
  
https://github.com/django/django/commit/bff0eb3b24f94831832f89913a4bcc8c3ee94d80
  Author: Haris Ibrahim K. V 
  Date:   2014-05-13 (Tue, 13 May 2014)

  Changed paths:
M docs/topics/db/transactions.txt

  Log Message:
  ---
  [1.6.x] Fixed typo in transactions.txt

Backport of f2a8e47cfd 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/537201f4cb67e_2f7b995d404399a%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


[django/django] 81aeff: [1.7.x] Fixed typo in transactions.txt

2014-05-13 Thread GitHub
  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: 81aeffccf32804aaf9343a32632e526fc6ec0f24
  
https://github.com/django/django/commit/81aeffccf32804aaf9343a32632e526fc6ec0f24
  Author: Haris Ibrahim K. V 
  Date:   2014-05-13 (Tue, 13 May 2014)

  Changed paths:
M docs/topics/db/transactions.txt

  Log Message:
  ---
  [1.7.x] Fixed typo in transactions.txt

Backport of f2a8e47cfd 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/537201f6c87a8_35e3119dd4458661%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


[django/django] f2a8e4: Fixed typo in transactions.txt

2014-05-13 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: f2a8e47cfd75f6135634a833f0a6a621909b4c3a
  
https://github.com/django/django/commit/f2a8e47cfd75f6135634a833f0a6a621909b4c3a
  Author: Haris Ibrahim K. V 
  Date:   2014-05-13 (Tue, 13 May 2014)

  Changed paths:
M docs/topics/db/transactions.txt

  Log Message:
  ---
  Fixed typo in transactions.txt


-- 
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/537201e26f75c_5c8b81d34760e4%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


[django/django] 57296b: Removed some references to django.contrib.comments...

2014-05-13 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 57296b41624c37206d89275882eb71eca5157214
  
https://github.com/django/django/commit/57296b41624c37206d89275882eb71eca5157214
  Author: Tim Graham 
  Date:   2014-05-13 (Tue, 13 May 2014)

  Changed paths:
M docs/ref/contrib/sites.txt
M docs/topics/db/multi-db.txt

  Log Message:
  ---
  Removed some references to django.contrib.comments which has been removed.


-- 
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/53720108dc33f_2dc710c7d343313a%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #22618: Documentation about import_string unclear

2014-05-13 Thread Django
#22618: Documentation about import_string unclear
-+-
 Reporter:  ewjoachim|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Documentation|   Resolution:  fixed
 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 Tim Graham ):

 In [changeset:"0bb90de869303f4e0fc9479391fde7c68b4088a0"]:
 {{{
 #!CommitTicketReference repository=""
 revision="0bb90de869303f4e0fc9479391fde7c68b4088a0"
 [1.7.x] Fixed #22618 -- Improved import_string example.

 Thanks ewjoachim for the sugggestion.

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


[django/django] 0bb90d: [1.7.x] Fixed #22618 -- Improved import_string exa...

2014-05-13 Thread GitHub
  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: 0bb90de869303f4e0fc9479391fde7c68b4088a0
  
https://github.com/django/django/commit/0bb90de869303f4e0fc9479391fde7c68b4088a0
  Author: Tim Graham 
  Date:   2014-05-13 (Tue, 13 May 2014)

  Changed paths:
M docs/ref/utils.txt

  Log Message:
  ---
  [1.7.x] Fixed #22618 -- Improved import_string example.

Thanks ewjoachim for the sugggestion.

Backport of c501662f3c 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/5371fcc8320eb_79715d3d38146df%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


[django/django] c50166: Fixed #22618 -- Improved import_string example.

2014-05-13 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: c501662f3c3f03876effcf3ede94922c0cec43bd
  
https://github.com/django/django/commit/c501662f3c3f03876effcf3ede94922c0cec43bd
  Author: Tim Graham 
  Date:   2014-05-13 (Tue, 13 May 2014)

  Changed paths:
M docs/ref/utils.txt

  Log Message:
  ---
  Fixed #22618 -- Improved import_string example.

Thanks ewjoachim for the sugggestion.


-- 
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/5371fc73f0949_2386fafd34784d9%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #22618: Documentation about import_string unclear

2014-05-13 Thread Django
#22618: Documentation about import_string unclear
-+-
 Reporter:  ewjoachim|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Documentation|   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"c501662f3c3f03876effcf3ede94922c0cec43bd"]:
 {{{
 #!CommitTicketReference repository=""
 revision="c501662f3c3f03876effcf3ede94922c0cec43bd"
 Fixed #22618 -- Improved import_string example.

 Thanks ewjoachim for the sugggestion.
 }}}

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


Re: [Django] #22594: Content Type framework does not trigger Cascade delete

2014-05-13 Thread Django
#22594: Content Type framework does not trigger Cascade delete
-+-
 Reporter:  JoseTomasTocino  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:   |  Version:  1.6
  contrib.contenttypes   |   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 chk):

 * cc: chk (added)


Comment:

 I'm able to reproduce the same issue with a similar database schema.
 * django 1.6.1
 * postgresql 9.1

 As a workaround I've defined a pre_signal (but NOT empty as Jose says):

 {{{
 from django.db.models.signals import pre_delete
 from django.dispatch import receiver

 @receiver(pre_delete, sender=User)
 def pre_delete_receiver(sender, instance, **kwargs):
 ## CODE TO DELETE RELATED OBJECTS
 for delta in instance.deltachecks.all():
 delta.logs.all().delete()
 }}}

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

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


Re: [Django] #22487: Moving from initial_data to data migrations stops test data persisting

2014-05-13 Thread Django
#22487: Moving from initial_data to data migrations stops test data persisting
-+-
 Reporter:  andrewgodwin |Owner:
 Type:  Bug  |  andrewgodwin
Component:  Testing framework|   Status:  assigned
 Severity:  Release blocker  |  Version:
 Keywords:   |  1.7-beta-1
Has patch:  0|   Resolution:
  Needs tests:  0| Triage Stage:  Accepted
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by merb):

 Currently this won't work on my side.
 I always get something like that:
 Sqlite3 http://pastebin.com/mb89mVqf
 Postgresql http://pastebin.com/WZu9JGF9

 This is the application I tested:
 http://gccc.de/unittest_persistance.tar.gz
 Just a really simple application, so that I could run it with:

 {{{
 PYTHONPATH=../django python manage.py test
 }}}

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


[Django] #22621: Return JSON response in default error handlers for ajax requests

2014-05-13 Thread Django
#22621: Return JSON response in default error handlers for ajax requests
-+
 Reporter:  Elvard   |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Core (URLs)  |Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Default error handlers in `django.views.defaults` always return
 `text/html` content type with HTML response.

 It would be useful to check if:
  - `request.is_ajax()`
  - client accepts `application/json` content type

 and then return JSON response.

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


Re: [Django] #22620: "Multiple databases" chapter of docs says 'default':{} can start DATABASES setting; Django says no

2014-05-13 Thread Django
#22620: "Multiple databases" chapter of docs says 'default':{} can start 
DATABASES
setting; Django says no
-+-
 Reporter:  moc@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.5
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  multiple_databases   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by moc@…):

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


Comment:

 I didn't mean to remain anonymous. I submitted this.

 -Mike O'Connor
 Shelton, WA

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

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


Re: [Django] #10961: Allow users to override forward and reverse relationships on proxy models with !ForeignKey fields.

2014-05-13 Thread Django
#10961: Allow users to override forward and reverse relationships on proxy 
models
with !ForeignKey fields.
-+-
 Reporter:  mrmachine|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  proxy ForeignKey |  Needs documentation:  0
  reverse relationship manager   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by rhertzog):

 * cc: rhertzog (added)


Comment:

 pjdelport, this doesn't seem to be enough to update the related fields
 (eg. country.state_set). There's a discussion of this on
 http://stackoverflow.com/questions/3891880/django-proxy-model-and-
 foreignkey and for my needs I have also added something like this:

 {{{
 #!python
 class CountryProxy(Country):
 ...
 @property
 def state_set(self):
 qs = super(CountryProxy, self).state_set
 qs.model = StateProxy
 return qs
 }}}

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