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

[Django]

#20205: positiveintegerfield null=True, blank=True
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 I think there needs to be more control around what values the model should
 allow for blank, Since PositveInteger inherits from Integer->Field it just
 uses the Field clean which uses blank=''.

 I think here the ORM abstraction leaks a bit.  The Database could define
 one set of values it will treats as blank for a given column while the
 django ORM has a different another for the field.

-- 
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] #20149: Forgot password email not being correctly translated

[Django]

#20149: Forgot password email not being correctly translated
-+-
 Reporter:  static   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.5
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  i18n, templates, | Triage Stage:
  admin  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by static):

 I made some changes in my code and updated Django to 1.5.1, now it is
 working (very strange).

 I was using in my settings:

 {{{
 LANGUAGE_CODE = 'pt-br'

 ugettext = lambda s: s
 LANGUAGES = (
 ('pt-br', ugettext('Portuguese')),
 ('en', ugettext('English')),
 )
 DEFAULT_LANGUAGE = 1
 }}}

 I will keep it closed until it happens 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.

Re: [Django] #20003: URLValidator does not accept urls with usernames or passwords in them

[Django]

#20003: URLValidator does not accept urls with usernames or passwords in them
--+
 Reporter:  marshall@…|Owner:  matiasb
 Type:  Bug   |   Status:  assigned
Component:  Core (Other)  |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:  URLValidator  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by matiasb):

 * has_patch:  0 => 1


Comment:

 Proposed update: https://github.com/django/django/pull/998
 Tests passing with sqlite.

-- 
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] #20211: BoundField.label_tag now always escapes its `contents` parameter.

[Django]

#20211: BoundField.label_tag now always escapes its `contents` parameter.
-+-
 Reporter:  bmispelon|Owner:  bmispelon
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.5
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by claudep):

 * stage:  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] #20205: positiveintegerfield null=True, blank=True

[Django]

#20205: positiveintegerfield null=True, blank=True
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bmispelon):

 * cc: bmispelon@… (added)
 * component:  Forms => Database layer (models, ORM)


Comment:

 The original report is not very clear, so here's a way to reproduce the
 error that the OP is refering to:
 {{{
 #!python
 # models.py
 from django.db import models

 class Foo(models.Model):
 bar = models.PositiveIntegerField(blank=True, null=True)

 # to reproduce:
 from django.core.exceptions import ValidationError
 foo = Foo(bar='')

 try:
 foo.full_clean()
 except ValidationError as error:
 print(error)
 else:
 foo.save()
 }}}

 Doing this, the model validation passes but the save throws an error:
 {{{
 ValueError: invalid literal for int() with base 10: ''
 }}}

 I would be inclined to mark this ticket as invalid, since it's incorrect
 to be passing an empty string as the value of an integer field, but
 there's some issues in this report that might still be relevant:

 * The model validation passes, which I find surprising (and might be
 another bug on its own)
 * The documentation (as far as I could find) does not mention what happens
 when you give incorrect data to models.

-- 
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] #13667: Multiple profile models via AUTH_PROFILE_MODULES (proposal)

[Django]

#13667: Multiple profile models via AUTH_PROFILE_MODULES (proposal)
-+-
 Reporter:  humanfromearth   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Contrib apps |  Version:  1.5
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  user auth profile| Triage Stage:
  multiple   |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * version:  1.2 => 1.5
 * easy:   => 0
 * severity:   => Normal


-- 
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] #13167: Non-existent arg passed to template filter raises VariableDoesNotExist

[Django]

#13167: Non-existent arg passed to template filter raises VariableDoesNotExist
-+-
 Reporter:  copelco  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by kmtracey):

 * resolution:  fixed => wontfix


Comment:

 The two calls from the original description still produce the exact same
 result (an exception during template rendering), so if this is going to be
 closed the resolution should be wontfix. History here is that this was
 claimed to be a regression from 1.1 to 1.2 while 1.2 was in development,
 but in fact was not. The actual regression was teased out in the
 discussion, and was slightly different from the original report. THAT
 regression was fixed. But the originally reported problem here was not a
 regression, behavior here has been consistent since probably prior to 1.0.
 I'm fine with wontfixing that, though it does rather seem to go against
 "template errors don't raise exceptions" philosophy.

-- 
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] #14019: SQLInsertCompiler.as_sql() failure

[Django]

#14019: SQLInsertCompiler.as_sql() failure
-+-
 Reporter:  mlavin   |Owner:  tobias
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by kmtracey):

 Really? Sigh. This is a real problem hit by people trying to use Django
 and a couple of external packages (mssql backend, django db log). Why the
 incredible pushback to initializing an attribute in init so as to ensure
 that a utility routine won't fall over dead if this "internal api" is used
 "incorrectly"? What's the harm? Maybe it would give a clue as to what the
 heck has gone wrong with use of this internal api by whatever package is
 in error...the current Django code makes it impossible to figure out who
 has gone wrong when, because you get a totally useless exception. Why are
 we being so user-unfriendly? Sure, it's an internal API but I'm not
 exactly surprised if an externally-maintained DB backend uses it, and
 given we don't exactly document this stuff very well I think it would be
 far more friendly of us to make the small effort to make this code a bit
 more foolproof.

-- 
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] #20211: BoundField.label_tag now always escapes its `contents` parameter.

[Django]

#20211: BoundField.label_tag now always escapes its `contents` parameter.
---+--
 Reporter:  bmispelon  |Owner:  bmispelon
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by bmispelon):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * component:  Forms => Documentation
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Well it turned out the behavior is intended, since the docstring of the
 method now reads:
 {{{
 contents should be 'mark_safe'd to avoid HTML escaping.
 }}}

 So I made a pull request that adds a note in the backwards-incompatible
 changes of the 1.5 release notes.

 I also added some tests for the `label_tag` functionalities (it didn't
 seem to be tested very much) and removed a call to `conditional_escape`
 that was not needed since everything gets escaped by `format_html` later
 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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20211: BoundField.label_tag now always escapes its `contents` parameter.

[Django]

#20211: BoundField.label_tag now always escapes its `contents` parameter.
+---
 Reporter:  bmispelon   |  Owner:  bmispelon
 Type:  Bug | Status:  new
Component:  Forms   |Version:  1.5
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+---
 This behavior changed between 1.4 and 1.5:

 {{{
 #!python
 class FooForm(forms.Form):
 foo = forms.CharField()

 print FooForm().foo.label_tag('')
 }}}

 In 1.4, the output of the previous code was this:
 {{{
 #!python
 
 }}}

 In 1.5, we get this:
 {{{
 #!python
 
 }}}

 This was changed by commit a92e7f37c4ae84b6b8d8016cc6783211e9047219.

 I think the original intention was to **not** escape the content if it was
 provided, as indicated by the first line of the method
 (https://github.com/django/django/blob/master/django/forms/forms.py#L522):
 {{{
 #!python
 contents = contents or conditional_escape(self.label)
 }}}

 This conditional escape is rendered moot by the use of `format_html` later
 on (introduced by the commit I linked above), which escapes everything
 anyway.

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

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

Re: [Django] #20210: Correction on DjangoFriendlyWebHosts

[Django]

#20210: Correction on DjangoFriendlyWebHosts
-+-
 Reporter:  elena|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.5
Component:  *.djangoproject.com  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by claudep):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => fixed
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization


Comment:

 Thanks for the notice. Line removed on the Wiki page.

-- 
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] #20210: Correction on DjangoFriendlyWebHosts

[Django]

#20210: Correction on DjangoFriendlyWebHosts
-+
 Reporter:  elena|  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  *.djangoproject.com  |Version:  1.5
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  1|  UI/UX:  0
-+
 https://code.djangoproject.com/wiki/DjangoFriendlyWebHosts

 "Development Island"

 According to the link provided: http://www.devisland.net/


 > CLOSED - Was a hosting company with a difference
 > We regretfully inform all our members that all our services will be
 stopping on 24/07/2013.

-- 
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] #4045: some admin Javascript fixes and cleanups

[Django]

#4045: some admin Javascript fixes and cleanups
+--
 Reporter:  arvin   |Owner:  andrewjesaitis
 Type:  Bug |   Status:  assigned
Component:  contrib.admin   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  admin calendar  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+--

Comment (by Claude Paroz ):

 In [changeset:"4509a1be1f1164164c2b654d1e3e4169ef71b5ae"]:
 {{{
 #!CommitTicketReference repository=""
 revision="4509a1be1f1164164c2b654d1e3e4169ef71b5ae"
 Explicitly removes dismissClock

 Uses the removeEvent function in core.js to remove the function from
 the document click event.
 Refs #4045.
 }}}

-- 
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] #4045: some admin Javascript fixes and cleanups

[Django]

#4045: some admin Javascript fixes and cleanups
+--
 Reporter:  arvin   |Owner:  andrewjesaitis
 Type:  Bug |   Status:  closed
Component:  contrib.admin   |  Version:  master
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  admin calendar  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"5ab66dea50eab6625e3a07b71342268432e9cfaf"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5ab66dea50eab6625e3a07b71342268432e9cfaf"
 Explicitly removes dismissCalendar

 Uses the removeEvent function in core.js to remove the dismissCalendar
 function from the document click event.
 Fixes #4045.
 }}}

-- 
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] 4509a1: Explicitly removes dismissClock

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 4509a1be1f1164164c2b654d1e3e4169ef71b5ae
  
https://github.com/django/django/commit/4509a1be1f1164164c2b654d1e3e4169ef71b5ae
  Author: Andrew Jesaitis 
  Date:   2013-04-06 (Sat, 06 Apr 2013)

  Changed paths:
M django/contrib/admin/static/admin/js/admin/DateTimeShortcuts.js

  Log Message:
  ---
  Explicitly removes dismissClock

Uses the removeEvent function in core.js to remove the function from
the document click event.
Refs #4045.


  Commit: 5ab66dea50eab6625e3a07b71342268432e9cfaf
  
https://github.com/django/django/commit/5ab66dea50eab6625e3a07b71342268432e9cfaf
  Author: Andrew Jesaitis 
  Date:   2013-04-06 (Sat, 06 Apr 2013)

  Changed paths:
M django/contrib/admin/static/admin/js/admin/DateTimeShortcuts.js

  Log Message:
  ---
  Explicitly removes dismissCalendar

Uses the removeEvent function in core.js to remove the dismissCalendar
function from the document click event.
Fixes #4045.


Compare: https://github.com/django/django/compare/216580e03499...5ab66dea50ea

-- 
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] #20209: fields is empty after post with RadioWidget

[Django]

#20209: fields is empty after post with RadioWidget
---+
 Reporter:  strelnikovdmitrij  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Forms  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 ---forms.py---
 class ApplicantForm(forms.ModelForm):
 # gender = forms.ChoiceField(choices=Gender.CHOICES,
 widget=forms.RadioSelect)

 class Meta:
 exclude = (...)
 model = Applicant

 widgets = {
 'gender': forms.RadioSelect,
 }

 ---view.py---
 def compose_full(request, tmpl='applicant/compose.html'):
 data = {}

 applicant = Applicant()
 applicant.created_by = request.user
 applicant.ip = get_ip(request)

 appl_frm = ApplicantForm(request.POST or None, instance=applicant)
 att_frm = AppCVForm(request.POST or None, request.FILES or None)

 if appl_frm.is_valid() and att_frm.is_valid():
 

 ---models.py---
 class Applicant(models.Model):
 ...
 gender = models.IntegerField(choices=Gender.CHOICES,
 default=Gender.UNSPECIFIED)
 ...

 after POST form, no value of gender is selected

 all works fine with default widget, if change widget to Meta class, or
 change it in form __init__ method, or define it in form class (commented
 line)
 RadioSelect or RadioSelect() providing same result (if no exception is
 raised)

-- 
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] #18108: Official translations of the documentation

[Django]

#18108: Official translations of the documentation
-+-
 Reporter:  survaes@…|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Documentation|  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  documentation| Triage Stage:  Accepted
  translation|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by claudep):

 Anyone at ease with writing Makefiles to create one to compile po files
 into mo files in https://github.com/django/django-docs-translations ?

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