Re: [Django] #19645: Add tests for TransactionMiddleware

[Django]

#19645: Add tests for TransactionMiddleware
-+-
 Reporter:  slurms   |Owner:  slurms
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Core (Other) |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by slurms):

 pull request here: https://github.com/django/django/pull/662

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19645: Add tests for TransactionMiddleware

[Django]

#19645: Add tests for TransactionMiddleware
-+-
 Reporter:  slurms   |Owner:  slurms
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Core (Other) |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by slurms):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19645: Add tests for TransactionMiddleware

[Django]

#19645: Add tests for TransactionMiddleware
--+
 Reporter:  slurms|  Owner:  slurms
 Type:  Cleanup/optimization  | Status:  new
Component:  Core (Other)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 Add some unit tests for TransactionMiddleware.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19644: links in pdf all go to the title page.

[Django]

#19644: links in pdf all go to the title page.
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.2
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Every link in the pdf doc here:
 http://media.readthedocs.org/pdf/django/1.2.X/django.pdf go to the title
 instead of where they are supposed to go. It makes the document very
 difficult to navigate.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19477: Docs needed for generic_inlineformset_factory

[Django]

#19477: Docs needed for generic_inlineformset_factory
---+
 Reporter:  epicserve  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timo):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19643: TypedChoiceField and TypedMultipleChoiceField call the super validate() method instead of their own

[Django]

#19643: TypedChoiceField and TypedMultipleChoiceField call the super validate()
method instead of their own
-+-
 Reporter:   |  Owner:  nobody
  BerislavLopac  | Status:  new
 Type:  Bug  |Version:  master
Component:  Forms|   Keywords:  MultipleChoiceField
 Severity:  Normal   |  TypedMultipleChoiceField
 Triage Stage:   |  Has patch:  0
  Unreviewed |  UI/UX:  0
Easy pickings:  1|
-+-
 As it can be seen on
 https://github.com/django/django/blob/master/django/forms/fields.py#L730,
 instead of calling self.validate() the code is actually
 super(TypedChoiceField, self).validate(value); it's the same on
 https://github.com/django/django/blob/master/django/forms/fields.py#L780

 On the other hand, the definition of the validate() methods in both
 classes is a simple "pass".

 I believe this is a bug because it makes it impossible to extend those
 classes and customize the validate() method. Specifically, in this example
 the validate() is never called:


 {{{
 class CustomTypedMultipleChoiceField(forms.TypedMultipleChoiceField):
 def validate(self, value):
 print("CustomTypedMultipleChoiceField.validate")
 }}}


 I propose that, instead of the current situation, lines 730 and 780 are
 replaced with self.validate(), and the validate() method definitions are
 either removed or changed to call the super.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19399: Do not recreate RelatedObject instances

[Django]

#19399: Do not recreate RelatedObject instances
-+-
 Reporter:  KJ   |Owner:  KJ
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by void):

 * cc: sun.void@… (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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19642: django.utils.functional.lazy issues

[Django]

#19642: django.utils.functional.lazy issues
--+--
 Reporter:  void  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Core (Other)  |Version:  master
 Severity:  Normal|   Keywords:  lazy, functional
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+--
 I've found some issues meditating on the `lazy()` function. I'm reporting
 them as one ticket; please tell if I should rather create one per issue.

 * promise, returned by `lazy()`, has no attributes of original class:
 `lazy()` thinks only about methods
 * promise, returned by `lazy()`, has weird behaviour if resultclass has
 `__mod__` method – it overrides it completely
 * methods of promise, returned by `lazy()`, lack the `__doc__` attribute –
 docstring is lost
 * if resultclass explicitly define itself as a not hashable with `__hash__
 = None`, promises of that class may still be hashable.

 Following diff, when applied, adds four failing tests illustrating that
 issues: https://gist.github.com/4582334

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19552: makemessages ignores translations in templates with inline comment tags

[Django]

#19552: makemessages ignores translations in templates with inline comment tags
-+-
 Reporter:  juneih@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.4
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  makemessages,|  Needs documentation:  0
  template, gettext, xgettext|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by ramiro):

 Replying to [comment:4 ramiro]:

 > Maybe something like this? (needs validation of the idea, polishing and
 tests): http://dpaste.de/hJepF/
 Ignore that patch. Moving comments to the end of the line helps in the
 general case but breaks association of translator comments.

 I believe we should ignore all the comments. 2) Get any no-comment tags
 that might be located in the same line as a comment one to be properly
 recognized and extracted and 3) Start requiring translator comments to be
 on a line by thrir own by ignoring those that don't comply just like as in
 1 but possibly making makemessages emit a warning. I have some code along
 these lines, will upload it tomorrow.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19641: Cookie encoding inconsistency

[Django]

#19641: Cookie encoding inconsistency
--+--
 Reporter:  kirpit|Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  HTTP handling |  Version:  1.4
 Severity:  Release blocker   |   Resolution:  invalid
 Keywords:  cookie, encoding  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by ramiro):

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


Comment:

 Actually, This seems to be a problem of that jquery.cookie library you are
 using: https://github.com/carhartl/jquery-cookie/pull/57

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15201: CACHE_MIDDLEWARE_ANONYMOUS_ONLY is ugly, misleading, and unnecessary, and should be deprecated

[Django]

#15201: CACHE_MIDDLEWARE_ANONYMOUS_ONLY is ugly, misleading, and unnecessary, 
and
should be deprecated
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Cache system)   |  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 aaugustin):

 My idea isn't going to play well with CSRF. `{% csrf_token %}` really
 depends on the cookie.

 Under the Don't Give Users Guns Aimed At Feet policy, I'm retracting it.

 

 This leaves us with Carl's idea of "cache anything that doesn't have Vary:
 Cookie" — but is it even useful?

 Caching is hard!

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19640: inlineformset_factory is not documented well like other formset_factories

[Django]

#19640: inlineformset_factory is not documented well like other 
formset_factories
-+-
 Reporter:  wim@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
  inlineformset_factory  |  Patch needs improvement:  0
  documentation  |UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by timo):

 * needs_docs:   => 0
 * has_patch:  0 => 1
 * needs_better_patch:   => 0
 * needs_tests:   => 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15201: CACHE_MIDDLEWARE_ANONYMOUS_ONLY is ugly, misleading, and unnecessary, and should be deprecated

[Django]

#15201: CACHE_MIDDLEWARE_ANONYMOUS_ONLY is ugly, misleading, and unnecessary, 
and
should be deprecated
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Cache system)   |  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 aaugustin):

 I hit this bug too. I only noticed because I have some randomized content
 and it changed on every refresh instead of staying cached for some time.

 In my case, the problem wasn't reproducible outside of the browser (eg.
 with unit tests or with curl). The culprit was Google Analytics. It sets
 `__utcma`, `__utcmb`, `__utcmc` and `__utcmz` cookies. Since Django's
 cache engine honors `Vary: Cookie`, and my templates hide some parts for
 anonymous users, this results in per-user cache instead of global cache.
 This is a variant of point 2) in the report above.

 I'm not familiar with tracking technology, but I believe cookies is the
 most straightforward and compatible implementation. I expect this problem
 to occur on any website that uses Google Analytics or a similar service.
 In other words, `CACHE_MIDDLEWARE_ANONYMOUS_ONLY` most certainly
 malfunctions silently for every non-trivial website, ''even if its
 behavior is checked by unit tests''!

 

 The feature we want here is "cache content for anonymous users, regardless
 of Vary: Cookie". Obviously, it clashes with the current APIs, because it
 means triggering HTTP-level caching based on application-level
 information. And it works only under the assumption that, when a user is
 anonymous, cookies aren't used for anything that affects the output
 (besides determining that the user is anonymous).

 This assumption cannot be checked automatically. It's something the
 developer declares by turning `CACHE_MIDDLEWARE_ANONYMOUS_ONLY` on. For
 instance, `{% if user.is_authenticated %}Welcome, {{ user }}!{% endif %}`
 is enough to turn "Vary: Cookie" on, but the developer knows that it
 results in the same output for all anonymous users. Often this holds true
 for an entire site, and that's why `CACHE_MIDDLEWARE_ANONYMOUS_ONLY`
 exists.

 

 To sum up, the expected behavior is "ignore Vary: Cookie when caching
 pages for anonymous users" (both for update and fetch).

 I think that's a useful behavior, more useful that "cache pages that don't
 have Vary: Cookie", because it's almost impossible not to have Vary:
 Cookie.

 If it cannot be implemented satisfactorily, then we should deprecate
 `CACHE_MIDDLEWARE_ANONYMOUS_ONLY`.

 

 Naive idea that I haven't tested:
 - if the setting is on, the user is anonymous, and the Vary header
 contains "Cookie"
 - then remove "Cookie" from Vary, do the caching operations, and restore
 "Cookie" in Vary.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #13217: LocaleMiddleware breaks caching. (Vary: Cookie)

[Django]

#13217: LocaleMiddleware  breaks caching.  (Vary: Cookie)
-+-
 Reporter:  harm |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Uncategorized|  Version:  1.2-beta
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  session accessed | Triage Stage:
  vary cookie|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * type:   => Uncategorized
 * ui_ux:   => 0
 * resolution:  wontfix => fixed
 * severity:   => Normal
 * easy:   => 0


Comment:

 If you're using `i18n_patterns` (introduced in Django 1.4) and the URL
 contains a language prefix, `get_language_from_request` will select the
 active language without reading the session.

 So, in practice, this is fixed.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19641: Cookie encoding inconsistency

[Django]

#19641: Cookie encoding inconsistency
-+--
 Reporter:  kirpit   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  HTTP handling|Version:  1.4
 Severity:  Release blocker  |   Keywords:  cookie, encoding
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+--
 Django is encoding cookie values and if, only if any of its value is
 encoded, wrapping the entire value within double quotes.

 `django/http/__init__.py` starts from the line `#84` (for 1.4.3):
   {{{#!python
   # If encoded now contains any quoted chars, we need double quotes
   # around the whole string.
   if "\\" in encoded and not encoded.startswith('"'):
 encoded = '"' + encoded + '"'
   }}}

 That means, the value `hello` will be stored as `hello` but `hello world`
 will be stored as `"hello world"`.

 I believe this is totally inconsistent and difficult to handle from client
 side. For example, you simply cannot use [https://github.com/carhartl
 /jquery-cookie jquery.cookie] to get the exact value without writing some
 double quotes checking javascript code.

 If you use jquery.cookie with its default values (`$.cookie.raw = false;`
 and `$.cookie.json = false;`) you get the server-side set value with
 double quotes around it (as in `var value = '"hello world"';`)

 If you use it with `$.cookie.json = true;`, you get the double quoted
 values fine (as in `var value = "hello world";`) but you get syntax error
 (for `hello`) because it is trying `JSON.parse('hello')`, which is not a
 valid JSON string.

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

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

[Django] #19640: inlineformset_factory is not documented well like other formset_factories

[Django]

#19640: inlineformset_factory is not documented well like other 
formset_factories
-+-
 Reporter:  wim@…|  Owner:  nobody
 Type:   | Status:  new
  Cleanup/optimization   |Version:  master
Component:  Documentation|   Keywords:  inlineformset_factory
 Severity:  Normal   |  documentation
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  1|  UI/UX:  0
-+-
 inlineformset_factory is poorly documented.

 
https://docs.djangoproject.com/en/dev/ref/forms/models/#django.forms.models.modelformset_factory
 lists modelform_factory and modelformset_factory, but not
 inlineformset_factory.

 We should probably add something in the line of:

 inlineformset_factory(parent_model, model, form=ModelForm,
 formfield_callback=None, formset=BaseInlineFormSet, fk_name=None, extra=3,
 can_delete=True, can_order=False, max_num=None, fields=None, exclude=None)

 Note that inlineformset_factory uses modelformset_factory() and marks
 can_delete=True, extra=3. In addition, it uses BaseInlineFormSet by
 default.
 If your model has more than one ForeignKey to the parent_model, you must
 specify a fk_name.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19552: makemessages ignores translations in templates with inline comment tags

[Django]

#19552: makemessages ignores translations in templates with inline comment tags
-+-
 Reporter:  juneih@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.4
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  makemessages,|  Needs documentation:  0
  template, gettext, xgettext|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by ramiro):

 Replying to [comment:3 claudep]:
 > I realized that my patch (with the OP proposal) has one major drawback,
 it doesn't preserve the line numbers. We've made considerable efforts in
 templatize to preserve line numbers, so as line numbers in po files match
 line numbers in the source file. For comments which are not translator
 comments, we could replace `#` by `''' '''`, but this doesn't work for
 translator comments. Ramiro, any idea?

 Maybe something like this? (needs validation of the idea, polishing and
 tests): http://dpaste.de/hJepF/

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #9532: min_num on formsets

[Django]

#9532: min_num on formsets
-+
 Reporter:  gsf  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+

Comment (by wim@…):

 Hi, probably it is a good idea to add min_num to modelformset_factory and
 inlineformset_factory 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17416: inlineformset_factory doesn't allow the widgets argument

[Django]

#17416: inlineformset_factory doesn't allow the widgets argument
+-
 Reporter:  jacob   |Owner:  slurms
 Type:  Bug |   Status:  assigned
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Ready for checkin
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-
Changes (by wim@…):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18898: has_changed fails to compare model instance with primary key

[Django]

#18898: has_changed fails to compare model instance with primary key
+
 Reporter:  adsva   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.4
 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 tuxcanfly):

 Trying a fix by updating has_changed to check on both string and python
 values.

 Added test for ModelMultipleChoiceField as well. Verified that all tests
 pass on sqlite.

 Needs review: https://github.com/django/django/pull/660

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19639: Choices in model fields best practices consistency

[Django]

#19639: Choices in model fields best practices consistency
---+
 Reporter:  charettes  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by timo):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.