Re: [Django] #19987: Basic host validation performed even when DEBUG=True

[Django]

#19987: Basic host validation performed even when DEBUG=True
---+
 Reporter:  Will Hardy |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  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 Will Hardy):

 Because the documentation promises that hostname validation is disabled
 when DEBUG=True, I wrote a patch that does this completely (ie for invalid
 hostnames too). But I also add an explanation to the `SuspiciousOperation`
 exception message as to why an RFC 1034/5 invalid hostname was rejected.

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

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

Re: [Django] #19987: Basic host validation performed even when DEBUG=True

[Django]

#19987: Basic host validation performed even when DEBUG=True
---+
 Reporter:  Will Hardy |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  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 Will Hardy):

 I thought I might take a few minutes to help out, even if only by writing
 a test.

 Which approach do you want to take?
  * skip all hostname validation when `ALLOWED_HOSTS = ["*"]`
  * make sure a normal `SuspiciousOperation` exception is raised (ie no
 exception when trying to display debug response)
  * add a different suggestion in exception message for invalid hostnames
 (ie invalid, but matched in `ALLOWED_HOSTS`)

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

[Django] #20208: Type of id.value of inlineformset differs from creation

[Django]

#20208: Type of id.value of inlineformset differs from creation
+
 Reporter:  roehner@…   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Forms   |Version:  1.4
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  1
+
 If i instantiate an inlineformset with request.POST, the type of the id of
 all fields will be unicode. If i instantiate it only with instance=object,
 the id is a long int. It should be a long int in both cases. The type is
 relevant, if accessing the id in a template (e.g. if the id references
 entries in a dictionary) and the different type causes problems there.

 I guess, that this is the case not only with inlineformsets.

 I use django 1.4.5

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

Re: [Django] #15040: Boolean fields return 0 and 1 when loaded through select_related

[Django]

#15040: Boolean fields return 0 and 1 when loaded through select_related
-+-
 Reporter:  homm |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (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 anonymous):

 The problem only occurs when using .defer()

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

Re: [Django] #15040: Boolean fields return 0 and 1 when loaded through select_related

[Django]

#15040: Boolean fields return 0 and 1 when loaded through select_related
-+-
 Reporter:  homm |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (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|
-+-
Changes (by anonymous):

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


Comment:

 I am having this problem in 1.5.1 -- 0 when using select related, but
 False when not. I am using mysql.

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

[django/django] d04e8f: [1.5.x] Fixed #20207 -- Handle ManyToManyField wit...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: d04e8f8c7869b79a6f848a94bd51ce71223c2df2
  
https://github.com/django/django/commit/d04e8f8c7869b79a6f848a94bd51ce71223c2df2
  Author: Simon Charette 
  Date:   2013-04-05 (Fri, 05 Apr 2013)

  Changed paths:
M django/db/models/fields/related.py
M tests/modeltests/many_to_many/models.py

  Log Message:
  ---
  [1.5.x] Fixed #20207 -- Handle ManyToManyField with a unicode name correctly.

Backport of 216580e034.



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

Re: [Django] #20207: `ManyToManyField` with an unicode name fails to create an intermediary model.

[Django]

#20207: `ManyToManyField` with an unicode name fails to create an intermediary
model.
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 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
-+-

Comment (by Simon Charette ):

 In [changeset:"d04e8f8c7869b79a6f848a94bd51ce71223c2df2"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d04e8f8c7869b79a6f848a94bd51ce71223c2df2"
 [1.5.x] Fixed #20207 -- Handle ManyToManyField with a unicode name
 correctly.

 Backport of 216580e034.
 }}}

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

Re: [Django] #20207: `ManyToManyField` with an unicode name fails to create an intermediary model.

[Django]

#20207: `ManyToManyField` with an unicode name fails to create an intermediary
model.
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 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 Simon Charette ):

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


Comment:

 In [changeset:"216580e03499e035b93283df00fcc03b346fef7b"]:
 {{{
 #!CommitTicketReference repository=""
 revision="216580e03499e035b93283df00fcc03b346fef7b"
 Fixed #20207 -- Handle ManyToManyField with a unicode name correctly.
 }}}

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

[django/django] 216580: Fixed #20207 -- Handle ManyToManyField with a unic...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 216580e03499e035b93283df00fcc03b346fef7b
  
https://github.com/django/django/commit/216580e03499e035b93283df00fcc03b346fef7b
  Author: Simon Charette 
  Date:   2013-04-05 (Fri, 05 Apr 2013)

  Changed paths:
M django/db/models/fields/related.py
M tests/many_to_many/models.py

  Log Message:
  ---
  Fixed #20207 -- Handle ManyToManyField with a unicode name correctly.



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

Re: [Django] #20207: `ManyToManyField` with an unicode name fails to create an intermediary model.

[Django]

#20207: `ManyToManyField` with an unicode name fails to create an intermediary
model.
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   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
-+-

Comment (by aaugustin):

 It'd be nice to backport the fix to 1.5.

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

Re: [Django] #20202: BaseModelForm uses model_to_dict to provide initial, causes problems for ModelChoiceField with non-pk to_field_name

[Django]

#20202: BaseModelForm uses model_to_dict to provide initial, causes problems for
ModelChoiceField with non-pk to_field_name
---+
 Reporter:  valtron2000@…  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Forms  |  Version:  1.5
 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 bmispelon):

 I made a first attempt at documenting the existing behavior:
 https://github.com/bmispelon/django/compare/ticket-20202

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

Re: [Django] #20207: `ManyToManyField` with an unicode name fails to create an intermediary model.

[Django]

#20207: `ManyToManyField` with an unicode name fails to create an intermediary
model.
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   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 claudep):

 * stage:  Unreviewed => Ready for checkin


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

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

Re: [Django] #20207: `ManyToManyField` with an unicode name fails to create an intermediary model.

[Django]

#20207: `ManyToManyField` with an unicode name fails to create an intermediary
model.
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * has_patch:  0 => 1


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

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

[Django] #20207: `ManyToManyField` with an unicode name fails to create an intermediary model.

[Django]

#20207: `ManyToManyField` with an unicode name fails to create an intermediary
model.
-+-
   Reporter:  charettes  |  Owner:  charettes
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  layer (models, ORM)|   Keywords:
   Severity:  Normal |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 I encountered the following error when porting an app codebase to support
 both python 2 and 3.

 {{{
 #!python
 from __future__ import unicode_literals


 class Teacher(models.Model):
 students_ = models.ManyToManyField(Student, name='students')  # Here
 the name is a unicode string because of the future import.
 }}}

 Raises:

 {{{
 TypeError: Error when calling the metaclass bases
 type() argument 1 must be string, not unicode
 }}}

 The culprit is this
 
[https://github.com/django/django/blob/8d05e6c0c7fe35df86799fa2fdcdb6499a4f6312/django/db/models/fields/related.py#L1312
 line]. It should always be a `str`.

 This was not introduced by the codebase port to Python 3 and thus it's not
 a release blocker.

 Attaching a simple patch with tests in a few moments.

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

Re: [Django] #20204: Better explanation of usage of url() in urlpatterns

[Django]

#20204: Better explanation of usage of url() in urlpatterns
-+-
 Reporter:  dave.lampton@…   |Owner:  bmispelon
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  1.5
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  url()|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by bmispelon):

 * has_patch:  0 => 1


Comment:

 Seeing as the tutorial systematically uses `url` instead of the tuple
 notation, I decided to do the same in this documentation too.

 Here's the corresponding pull request:
 https://github.com/django/django/pull/994

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

Re: [Django] #20202: BaseModelForm uses model_to_dict to provide initial, causes problems for ModelChoiceField with non-pk to_field_name

[Django]

#20202: BaseModelForm uses model_to_dict to provide initial, causes problems for
ModelChoiceField with non-pk to_field_name
---+
 Reporter:  valtron2000@…  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Forms  |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by valtron2000@…):

 * type:  Bug => New feature


Comment:

 I see, `to_field_name` is supposed to be mostly internal, because it's
 usually set by `ForeignKey.formfield`
 
(https://github.com/django/django/blob/master/django/db/models/fields/related.py#L1244).
 The only time the user has to provide it is if they're defining the field
 manually rather than though `Meta.fields`. I agree that this should be
 documented.

 However, my use case is: my FKs use the PK, but my models also have a uuid
 field. I don't want to expose PKs in the front end, so I was in the
 process of (as of now, incorrectly) using `to_field_name` to use the uuid
 for a bunch of fields. Therefore, I'm turning this into a feature request.

 I know that a lot of people currently use `model_to_dict` as it stands, so
 changing its behaviour isn't an option. It would be better to make a
 private `_get_initial_from_instance` that works the same but returns the
 instance instead of the PK for FK fields, and then it becomes the form
 field's responsibility to turn the instance into an HTML form field value.

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

[Django] #20206: Travel Vouchers As Business Incentives ###

[Django]

#20206: Travel Vouchers As Business Incentives ###
---+
 Reporter:  tamorado1984   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 If you own a company, you could be considering various ways that you can
 increase your income, bring more clients, or reward your employees. There
 are a variety of various kinds of incentive programs available, but
 undoubtedly you wish to utilize the one that is going to be most reliable
 for the company. One of many best incentive plans is by using travel
 vouchers. Whether you provide them with to products are purchased by new
 customers who, to the very best salesman for the most sales, or to other
 workers for meeting other objectives, these deals are sure to bring about
 great results for your business.

 While there are many other incentive plans, such as merchandise offers or
 cash rewards, many people love to travel, which is why travel deals make
 such great incentives. Though people enjoy income offers, they are
 generally very costly for businesses to finance, and products can be a
 difficult choice as well, as it is difficult to learn what people really
 would like. The best thing about using travel vouchers is that everyone
 either enjoys traveling or must travel at some time.

 exemplary business incentives If you are trying to draw clients, journey
 vouchers work. If you are in the car sales business and need to bring
 customers to your car dealership, providing journey deals with the
 purchase of a car is a superb method to gain new customers. These deals
 will also be convenient for selling big ticket items as well, such as
 large screen televisions and other high priced technology. You might also
 desire to offer them to consumers who spend a specific amount of cash in
 your shop as well.

 Not only can travel vouchers be used as business incentives for your
 visitors, but they can be also used by you as incentives for your purchase
 associates to bring in more income. Offering a competition that provides
 travel vouchers to anyone with the most sales is a superb way to get your
 staff motivated. Undoubtedly they would like a vacation, therefore
 probably this may motivate them to work towards this goal. As business
 incentives for their sales associates firms that use travel deals usually
 visit a great increase in the total amount of sales that are increasingly
 being made.

 Whether you elect to utilize them for the customers, your sales
 associates, as well as both, undoubtedly you will find journey vouchers to
 be very successful. Using these deals can help you increase your sales,
 which will increase your profit margin, and they will also make your
 workers and customers happy as well.

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

Re: [Django] #20205: positiveintegerfield null=True, blank=True

[Django]

#20205: positiveintegerfield null=True, blank=True
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  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 anonymous):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Forms
 * 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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20205: positiveintegerfield null=True, blank=True

[Django]

#20205: positiveintegerfield null=True, blank=True
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 When using a model PositiveIntegerField with blank=True and null=True, ''
 (empty string) is not allowed as a blank response value.  An extra manual
 step seems needlessly necessary to convert an empty string (say, received
 from a form) to convert to python None value.  Shouldn't this be fixed in
 to_get_prep_value()?  This is usually not the case for CharFields,
 TextFields or some of the other model fields.  Here is the exception:

 {{{
 Exception Value:

 invalid literal for int() with base 10: ''

 Exception Location: .../django/db/models/fields/__init__.py in
 get_prep_value, line 991
 }}}

 It seems an update to IntegerField's get_prep_value or to_python may 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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] a49e7d: Fixed #20114 -- support custom project login_url i...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: a49e7dd2a34882fc68244e024eb2876b21c7e8a8
  
https://github.com/django/django/commit/a49e7dd2a34882fc68244e024eb2876b21c7e8a8
  Author: Preston Holmes 
  Date:   2013-04-05 (Fri, 05 Apr 2013)

  Changed paths:
M django/contrib/auth/tests/test_decorators.py

  Log Message:
  ---
  Fixed #20114 -- support custom project login_url in tests

Thanks to Matias Bordese for the patch



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

Re: [Django] #20114: Failures in tests in django.contrib.auth when using custom LOGIN_URL/LOGOUT_URL

[Django]

#20114: Failures in tests in django.contrib.auth when using custom
LOGIN_URL/LOGOUT_URL
--+
 Reporter:  jriley@…  |Owner:  matiasb
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  1.5
 Severity:  Normal|   Resolution:  fixed
 Keywords:  tests | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Preston Holmes ):

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


Comment:

 In [changeset:"a49e7dd2a34882fc68244e024eb2876b21c7e8a8"]:
 {{{
 #!CommitTicketReference repository=""
 revision="a49e7dd2a34882fc68244e024eb2876b21c7e8a8"
 Fixed #20114 -- support custom project login_url in tests

 Thanks to Matias Bordese for the patch
 }}}

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

Re: [Django] #20204: Better explanation of usage of url() in urlpatterns

[Django]

#20204: Better explanation of usage of url() in urlpatterns
-+-
 Reporter:  dave.lampton@…   |Owner:  bmispelon
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  1.5
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  url()|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by bmispelon):

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


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

Re: [Django] #9055: Percent sign in SQL statement behaves different with CursorDebugWrapper

[Django]

#9055: Percent sign in SQL statement behaves different with CursorDebugWrapper
-+-
 Reporter:  guettli  |Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 Thank you very much!

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

Re: [Django] #9055: Percent sign in SQL statement behaves different with CursorDebugWrapper

[Django]

#9055: Percent sign in SQL statement behaves different with CursorDebugWrapper
-+-
 Reporter:  guettli  |Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"975c5afdb5a0c2f9f61f9faecf8dbd928c4996b7"]:
 {{{
 #!CommitTicketReference repository=""
 revision="975c5afdb5a0c2f9f61f9faecf8dbd928c4996b7"
 Added release note about percent literals in cursor.execute

 Thanks Aymeric Augustin for noticing the omission and Tim Graham
 for the text review.
 Fixes #9055 (again).
 }}}

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

[django/django] 975c5a: Added release note about percent literals in curso...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 975c5afdb5a0c2f9f61f9faecf8dbd928c4996b7
  
https://github.com/django/django/commit/975c5afdb5a0c2f9f61f9faecf8dbd928c4996b7
  Author: Claude Paroz 
  Date:   2013-04-05 (Fri, 05 Apr 2013)

  Changed paths:
M docs/releases/1.6.txt

  Log Message:
  ---
  Added release note about percent literals in cursor.execute

Thanks Aymeric Augustin for noticing the omission and Tim Graham
for the text review.
Fixes #9055 (again).



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

[django/django] 232290: Removed LocaleMiddleware from settings template.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 23229061fcb836ecca2195cc75f91e331279a5d1
  
https://github.com/django/django/commit/23229061fcb836ecca2195cc75f91e331279a5d1
  Author: Aymeric Augustin 
  Date:   2013-04-05 (Fri, 05 Apr 2013)

  Changed paths:
M django/conf/project_template/project_name/settings.py

  Log Message:
  ---
  Removed LocaleMiddleware from settings template.

It was added in 3f1c7b70537330435e2ec2fca9550f7b7fa4372e.

Single language sites should always be translated in LANGUAGE_CODE,
regardless of the browser's Accept-Language. Having LocaleMiddleware
enabled can result in having some parts, like the admin, translated
in an unexpected language, typically if someone browses a non-English
website on a system set up in English. Since most websites won't be
translated in multiple languages — especially at the time they're
created — it's better not to enable LocaleMiddleware by default.

Thanks Ramiro for the feedback.



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

Re: [Django] #19252: Install from wheel package

[Django]

#19252: Install from wheel package
--+
 Reporter:  Alex Morega   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Packaging |  Version:  master
 Severity:  Release blocker   |   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 apollo13):

 Building wheels is possible via:
 {{{
 pip wheel .
 }}}
 (Assuming pip 1.4). python setup.py bdist_wheel doesn't work since we
 don't use setuptools in setup.py, but that's fine.

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

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

Re: [Django] #20204: Better explanation of usage of url() in urlpatterns (was: suggestion for improvement/clarification)

[Django]

#20204: Better explanation of usage of url() in urlpatterns
--+
 Reporter:  dave.lampton@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:  url() | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20202: BaseModelForm uses model_to_dict to provide initial, causes problems for ModelChoiceField with non-pk to_field_name

[Django]

#20202: BaseModelForm uses model_to_dict to provide initial, causes problems for
ModelChoiceField with non-pk to_field_name
---+
 Reporter:  valtron2000@…  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.5
 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 bmispelon):

 I've been digging a bit and now I'm not sure if this is technically a bug
 or not.

 The main problem is that since the `to_field_name` attribute is
 undocumented, what it's supposed to do is not exactly clear.

 The fact is that there is a (passing) test the issue you describe:
 
https://github.com/django/django/blob/master/tests/model_forms/tests.py#L1508-L1513

 Without documentation, a test is probably the next best thing to know the
 intended behavior.

 From the test, it looks like the form field's `to_field_name` should match
 the model field's `to_field`, which in your example is not the case (and
 causes the issue).

 Note that the test models is quite similar to your example (the difference
 being the existence of the `to_field` attribute):
 https://github.com/django/django/blob/master/tests/model_forms/models.py#L174

 So I'm leaving this as "Accepted", but I think the first thing to do would
 be to document `ModelChoiceField.to_field_name` and then make sure the
 implementation matches the documentation.

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

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

Re: [Django] #20202: BaseModelForm uses model_to_dict to provide initial, causes problems for ModelChoiceField with non-pk to_field_name

[Django]

#20202: BaseModelForm uses model_to_dict to provide initial, causes problems for
ModelChoiceField with non-pk to_field_name
---+
 Reporter:  valtron2000@…  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by bmispelon):

 * cc: bmispelon@… (added)
 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 This definitely looks like a bug but it might be a bit tricky to fix (it
 will at least require some changes to `model_to_dict`'s signature).

 As noted, the issue is that `model_to_dict` will always return the primary
 key of the model, not taking into account the field's `to_field_name`
 attribute.

 The problem is that `model_to_dict` does not have access to the form's
 fields: it only gets passed the instance, a list of strings corresponding
 to the model's fields present in the form, and a list of strings of the
 fields to exclude. Therefore, it has no way to access the `to_field_name`
 attribute and adjust the value accordingly.

 On a side-note, it seems that `ModelChoiceField.to_field_name` is
 completely undocumented, though there seem to be a few tests for it.

 This ticket could be a good excuse to finally document it.

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

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

[django/django] 17be12: Removed a trailing space in the template name on l...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 17be12df473c24f5b717dd553400971893a9676c
  
https://github.com/django/django/commit/17be12df473c24f5b717dd553400971893a9676c
  Author: Andrew Brown 
  Date:   2013-04-04 (Thu, 04 Apr 2013)

  Changed paths:
M docs/ref/templates/builtins.txt

  Log Message:
  ---
  Removed a trailing space in the template name on line 174.
This trailing space may seem innocuous, but can be easily copied-and-pasted 
from the docs.
This can lead to bizarre File Not Found errors where the checked paths look 
correct, but actually aren't because
the trailing space is hard to see in an error message.


  Commit: d7fa80258b0dc918483679066b38fc4d471acabc
  
https://github.com/django/django/commit/d7fa80258b0dc918483679066b38fc4d471acabc
  Author: Simon Charette 
  Date:   2013-04-04 (Thu, 04 Apr 2013)

  Changed paths:
M docs/ref/templates/builtins.txt

  Log Message:
  ---
  Merge pull request #993 from almostabc/template-include-docs-update

Removed a trailing space in the template builtins docs.


Compare: https://github.com/django/django/compare/1aca9d93beaa...d7fa80258b0d

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

Re: [Django] #20204: suggestion for improvement/clarification

[Django]

#20204: suggestion for improvement/clarification
--+
 Reporter:  dave.lampton@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:  url() | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by bmispelon):

 * cc: bmispelon@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


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

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