date:20150122

Re: [Django] #15802: Django stops functioning when the database (PostgreSQL) closes the connection

2015-01-22 Thread Django

#15802: Django stops functioning when the database (PostgreSQL) closes the
connection
-+-
 Reporter:  Rick.van.Hattem@…|Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database, postgres,  | Triage Stage:  Accepted
  postgresql, connection, closed |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by rckclmbr):

 * cc: rckclmbr@… (added)


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

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

Re: [Django] #24164: Oracle GIS geoapp extent test failure

2015-01-22 Thread Django

#24164: Oracle GIS geoapp extent test failure
---+-
 Reporter:  timgraham  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  GIS|  Version:  1.8alpha1
 Severity:  Normal |   Resolution:
 Keywords:  oracle | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by akaariai):

 The select_format is pretty much equivalent to from_db_value, but done on
 the database side (because we don't know how to do it on Python side). So,
 it must be done only at the point where the expression is in the outermost
 select list.

 Adding an is_subquery flag to compiler, setting this to true for the inner
 query, and finally skipping the select_format generation for subqueries
 seems like a good enough fix to me.

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

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

[Django] #24206: Missing mock dependency for test suite

2015-01-22 Thread Django

#24206: Missing mock dependency for test suite
---+-
 Reporter:  aron45 |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  1.7
 Severity:  Normal |   Keywords:  tests, mock
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+-
 The test suite depends on mock python package, but is missing from the
 requirements file.

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

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

Re: [Django] #15602: Using get_readonly_fields and StackedInline/TabularInline admin objects doesn't allow creating new objects, immutible existing objects

2015-01-22 Thread Django

#15602: Using get_readonly_fields and StackedInline/TabularInline admin objects
doesn't allow creating new objects, immutible existing objects
-+
 Reporter:  bradwhittington  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.2
 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 dji):

 I've done some additional research, and the problem actually goes much
 deeper than this.  Not only do the results of `get_readonly_fields` get
 passed to the `InlineAdminFormSet` object and others in
 `django.contrib.admin.helpers` that actually mark the individual field
 objects as readonly and render them differently, they also get passed into
 the regular form validation logic.

 The way formsets work is to take a single form class and instantiate it
 multiple times; an inline model formset uses a constructed `ModelForm`
 subclass.  (see `django.forms.models.modelformset_factory`)

 Now, the results of `get_readonly_fields` are added to this constructed
 form class as the `Meta.exclude` list, the list of fields that are
 excluded from validation.  Because this same class is instantiated
 multiple times by the formset, every instance of the form must have the
 same fields excluded.  So, as it stands now, every instance must have the
 same readonly fields - because you want to exclude at least these of
 fields from validation.  Decisions can't be made on a per-form/per-inline-
 model-instance basis.

 The only real "solutions" that come to mind both involve _underscore
 methods, which is exactly what you're not supposed to do:

 - The simplest is to allow the custom model form class to be created with
 `exclude=()`, and let the individual forms in the formset be instantiated.
 Then we'd tweak each form's `_meta.exclude` as we wanted to include the
 results of its exclude.

 - Another possibility is to use a custom `formset` that overrides
 `BaseModelFormSet._construct_form`, the method that model formsets use to
 get each model instance in the queryset and to instantiate each of their
 individual forms.  Instead of instantiating the formset's normal form,
 we'd have to check the readonly fields on the instance, create a new model
 form class for that particular exclude list, and instantiate a single
 instance of that class.  Whew.

 I suppose the ideal solution would be to allow a model form's `exclude` to
 be callable with the form's instance, but that's outside the scope of this
 ticket I imagine.

 Of course none of this solves the earlier problem of what to do with the
 request, but in comparison that seems like a fairly simple problem to have
 - worst case you send it along when you instantiate the `InlineAdminForm`
 wrapper or bind up a `functools.partial` version of `get_readonly_fields`
 with the request in it.  But perhaps there's even a cleaner way, I didn't
 look into this too much as it depends on the larger problem.

 So, I guess in conclusion - how bad is it considered to mess with a form's
 `_meta` after it's been instantiated?  Would that be a deal-breaker even
 if it fixed this?

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

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

Re: [Django] #24185: Inline object in TabularInline.get_readonly_fields

2015-01-22 Thread Django

#24185: Inline object in TabularInline.get_readonly_fields
---+--
 Reporter:  zachborboa |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:  duplicate
 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 timgraham):

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


Comment:

 Duplicate of #15602

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

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

Re: [Django] #24164: Oracle GIS geoapp extent test failure

2015-01-22 Thread Django

#24164: Oracle GIS geoapp extent test failure
---+-
 Reporter:  timgraham  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  GIS|  Version:  1.8alpha1
 Severity:  Normal |   Resolution:
 Keywords:  oracle | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by timgraham):

 If no one fixes this issue in the next couple days I plan to mark the test
 as `@expectedFailure` on Oracle so we get the build back to green and
 don't miss any new failures that are introduced.

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

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

Re: [Django] #3254: full text search support for postgres, oracle and mssql (was: [patch] experimental fulltext search support for postgres, oracle and mssql)

2015-01-22 Thread Django

#3254: full text search support for postgres, oracle and mssql
-+-
 Reporter:  Ronny Pfannschmidt   |Owner:  mjtamlyn
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle fulltext  | Triage Stage:  Accepted
  search postgresql postgres mysql   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/076.2f6edcefbaceaa15d70ca22c98874107%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24190: "Don’t use len() on QuerySets" is too strong.

2015-01-22 Thread Django

#24190: "Don’t use len() on QuerySets" is too strong.
--+
 Reporter:  collinanderson|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.36e1e6ec180c82fc7f68e38fb7366f9d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24192: Deprecate django.templatetags.static

2015-01-22 Thread Django

#24192: Deprecate django.templatetags.static
-+-
 Reporter:  doismellburning  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  Uncategorized => Core (Other)


Comment:

 I don't see much advantage here vs. the pain this is likely to cause
 (force everyone to use `contrib.staticfiles` and `{% load static %}` in
 their templates. The documentation points users in the direction IMO.
 There has been some talk of "if we did it again, static files might have
 been better in core, rather than contrib", but I'm not sure if that's
 something that's worth changing at this point. See also #18942. Feel free
 to raise the issue on the DevelopersMailingList or reopen if you think
 I've missed something here.

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

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

Re: [Django] #24202: Implement a SensitiveTextInput widget for sensitive input fields

2015-01-22 Thread Django

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

Comment:

I'm not sure this is such a universal problem or implementation that it
needs to live in Django itself. Please see an

[https://github.com/django/djangoproject.com/blob/c2fb010f8e58dfc5269fba220ec5a9ca4476d1d5/fundraising/forms.py#L83-L97
alternate implementation] for djangoproject.com's own Stripe integration.
The six lines of code you've proposed seem pretty low maintenance for any
projects that need it. If you can drive consensus on the
DevelopersMailingList that indicates otherwise, then we can reopen this.
Thanks!

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

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

Re: [Django] #15602: Using get_readonly_fields and StackedInline/TabularInline admin objects doesn't allow creating new objects, immutible existing objects

2015-01-22 Thread Django

#15602: Using get_readonly_fields and StackedInline/TabularInline admin objects
doesn't allow creating new objects, immutible existing objects
-+
 Reporter:  bradwhittington  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.2
 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 dji):

 #24185 is a duplicate of this.

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

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

Re: [Django] #24205: Remove or deprecate weak parameter to Signal.disconnect()

2015-01-22 Thread Django

#24205: Remove or deprecate weak parameter to Signal.disconnect()
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/3964 PR] from Florian which
 implements a deprecation.

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

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

[Django] #24205: Remove or deprecate weak parameter to Signal.disconnect()

2015-01-22 Thread Django

#24205: Remove or deprecate weak parameter to Signal.disconnect()
+
   Reporter:  timgraham |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (Other)  |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 The parameter has no effect. I'm in favor of simply removing it and
 documenting it as a backwards incompatible change. A deprecation seems to
 simply add overhead. A library that attempts to support multiple versions
 of Django can remove the parameter without any backwards compatibility
 concerns. Any opposition to that?

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

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

Re: [Django] #24204: Add remaining character count in admin for fields with maxlength

2015-01-22 Thread Django

#24204: Add remaining character count in admin for fields with maxlength
---+--
 Reporter:  jschneier  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

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


Comment:

 I hope not to discourage you from contributing or raising other ideas, but
 this particular one seems very niche to me. I can't think of one site
 where I've seen something like this. I don't think it's something that
 needs to live in Django itself as you should be able to implement this as
 custom admin CSS and JavaScript.

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

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

Re: [Django] #24204: Add remaining character count in admin for fields with maxlength

2015-01-22 Thread Django

#24204: Add remaining character count in admin for fields with maxlength
---+--
 Reporter:  jschneier  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by berkerpeksag):

 I'm not sure it's a common use case to make it default. Perhaps you can
 make it optional.

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

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

Re: [Django] #24204: Add remaining character count in admin for fields with maxlength

2015-01-22 Thread Django

#24204: Add remaining character count in admin for fields with maxlength
---+--
 Reporter:  jschneier  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by collinanderson):

 * cc: cmawebsite@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #24204: Add remaining character count in admin for fields with maxlength

2015-01-22 Thread Django

#24204: Add remaining character count in admin for fields with maxlength
---+
 Reporter:  jschneier  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  contrib.admin  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I'm attaching a screenshot. It looks a bit cluttered I think, any comments
 on improvements for UX or where I should place the count/styling would be
 greatly appreciated.

 The question if this should be applied for emails remains outstanding.

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

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

Re: [Django] #24193: Test failure: deprecation.tests.DeprecatedChineseLanguageCodes.test_deprecation_warning with unexpected warnings about unclosed files

2015-01-22 Thread Django

#24193: Test failure:
deprecation.tests.DeprecatedChineseLanguageCodes.test_deprecation_warning
with unexpected warnings about unclosed files
-+-
 Reporter:  rhertzog |Owner:
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.7
 Severity:  Release blocker  |   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 timgraham):

 * component:  Uncategorized => Core (Other)
 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #24201: order_with_respect_to GenericForeignKey

2015-01-22 Thread Django

#24201: order_with_respect_to GenericForeignKey
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 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 AlexHill):

 * needs_better_patch:  1 => 0
 * needs_docs:  1 => 0


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

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

Re: [Django] #24201: order_with_respect_to GenericForeignKey

2015-01-22 Thread Django

#24201: order_with_respect_to GenericForeignKey
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by AlexHill):

 * needs_tests:  1 => 0


Comment:

 I've now implemented the `get_RELATED_order` and `set_RELATED_order`
 methods where `GenericRelation`s are present, and duplicated the
 order_with_respect_to tests using generic relationships.

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

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

Re: [Django] #11505: Django's TestCase should reset the cache

2015-01-22 Thread Django

#11505: Django's TestCase should reset the cache
-+-
 Reporter:  andrewfong   |Owner:
 |  andrewfong
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  cache testing flush  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"1806e059f6127e3e4572db09f297984c96ea9d02"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1806e059f6127e3e4572db09f297984c96ea9d02"
 [1.8.x] Isolated a flatpages test; refs #11505.

 Backport of 4135d837027eac43ec416856d9476c478167d8a6 from master
 }}}

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

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

Re: [Django] #11505: Django's TestCase should reset the cache

2015-01-22 Thread Django

#11505: Django's TestCase should reset the cache
-+-
 Reporter:  andrewfong   |Owner:
 |  andrewfong
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  cache testing flush  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"4135d837027eac43ec416856d9476c478167d8a6"]:
 {{{
 #!CommitTicketReference repository=""
 revision="4135d837027eac43ec416856d9476c478167d8a6"
 Isolated a flatpages test; refs #11505.
 }}}

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

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

Re: [Django] #24149: Normalize settings to be lists rather than tuples

2015-01-22 Thread Django

#24149: Normalize settings to be lists rather than tuples
-+-
 Reporter:  aaugustin|Owner:  darkryder
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Other) |  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 darkryder):

 * has_patch:  0 => 1


Comment:

 PR resides here: https://github.com/django/django/pull/3973

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

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

Re: [Django] #24170: DateTimeRangeField: widget doesn't implement decompress()

2015-01-22 Thread Django

#24170: DateTimeRangeField: widget doesn't implement decompress()
-+-
 Reporter:  joelburton   |Owner:  ngzhian
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  DateTimeRangeField   | Triage Stage:  Ready for
  decompress |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ng Zhi An ):

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


Comment:

 In [changeset:"4669b6a807811d6763b9fdc5df974cb67aa1fb56"]:
 {{{
 #!CommitTicketReference repository=""
 revision="4669b6a807811d6763b9fdc5df974cb67aa1fb56"
 Fixed #24170 -- Implemented decompress for BaseRangeField widgets
 }}}

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

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

Re: [Django] #24203: Optimisation: adding multiple fields to same model should attempt to run single ALTER TABLE statement

2015-01-22 Thread Django

#24203: Optimisation: adding multiple fields to same model should attempt to run
single ALTER TABLE statement
-+-
 Reporter:  peterlauri   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migration| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by peterlauri):

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


Comment:

 Some ideas: https://github.com/peterlauri/django/pull/1

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

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

[Django] #24203: Optimisation: adding multiple fields to same model should attempt to run single ALTER TABLE statement

2015-01-22 Thread Django

#24203: Optimisation: adding multiple fields to same model should attempt to run
single ALTER TABLE statement
--+---
 Reporter:  peterlauri|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Migrations|Version:  1.7
 Severity:  Normal|   Keywords:  migration
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+---
 Origin: https://groups.google.com/d/msg/django-users/DDekrNgXH2U/k1un-
 e8CbnMJ

 When adding multiple fields to a Model the makemigrate and migrate does
 not attempt to create one ALTER TABLE statement, but rather one per field
 added. This can cause slow migrations of large tables.

 I propose to optimise to attempt to merge multiple AddField to one single
 ALTER TABLE request when the migrate is run.

 My real world case the db backend was MySQL, here is PG example of 2nd
 migration db output after adding two fields to one model.

 {{{
   Applying play.0002_auto_20150122_1825...DEBUG ALTER TABLE "play_play"
 ADD COLUMN "field2" varchar(100) NULL; (params [])
 DEBUG (0.000) ALTER TABLE "play_play" ADD COLUMN "field2" varchar(100)
 NULL; args=[]
 DEBUG ALTER TABLE "play_play" ALTER COLUMN "field2" DROP DEFAULT; (params
 [])
 DEBUG (0.000) ALTER TABLE "play_play" ALTER COLUMN "field2" DROP DEFAULT;
 args=[]
 DEBUG ALTER TABLE "play_play" ADD COLUMN "field3" varchar(100) NULL;
 (params [])
 DEBUG (0.000) ALTER TABLE "play_play" ADD COLUMN "field3" varchar(100)
 NULL; args=[]
 DEBUG ALTER TABLE "play_play" ALTER COLUMN "field3" DROP DEFAULT; (params
 [])
 DEBUG (0.000) ALTER TABLE "play_play" ALTER COLUMN "field3" DROP DEFAULT;
 args=[]
 }}}

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

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

Re: [Django] #24104: SQLite schema should to look for internal type of field instead of class instance when choosing a default for created fields

2015-01-22 Thread Django

#24104: SQLite schema should to look for internal type of field instead of class
instance when choosing a default for created fields
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Release blocker  |   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 MarkusH):

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


Comment:

 Backport for 1.7 will be opened as a separate PR including release notes
 for 1.7. Release notes can then be added to the 1.8 and 1.9 branches.

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

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

Re: [Django] #24104: SQLite schema should to look for internal type of field instead of class instance when choosing a default for created fields

2015-01-22 Thread Django

#24104: SQLite schema should to look for internal type of field instead of class
instance when choosing a default for created fields
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 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
-+-

Comment (by Markus Holtermann ):

 In [changeset:"11a5e45b96c3a15826927f5d0e50472767b937f1"]:
 {{{
 #!CommitTicketReference repository=""
 revision="11a5e45b96c3a15826927f5d0e50472767b937f1"
 [1.8.x] Fixed #24104 -- Fixed check to look on field.many_to_many instead
 of class instance

 Backport of 38c17871bb6dafd489367f6fe8bc56199223adb8 from master
 }}}

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

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

Re: [Django] #24104: SQLite schema should to look for internal type of field instead of class instance when choosing a default for created fields

2015-01-22 Thread Django

#24104: SQLite schema should to look for internal type of field instead of class
instance when choosing a default for created fields
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 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 Markus Holtermann ):

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


Comment:

 In [changeset:"38c17871bb6dafd489367f6fe8bc56199223adb8"]:
 {{{
 #!CommitTicketReference repository=""
 revision="38c17871bb6dafd489367f6fe8bc56199223adb8"
 Fixed #24104 -- Fixed check to look on field.many_to_many instead of class
 instance
 }}}

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

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

Re: [Django] #18392: Use utf8mb4 encoding with MySQL 5.5

2015-01-22 Thread Django

#18392: Use utf8mb4 encoding with MySQL 5.5
-+-
 Reporter:  EmilStenstrom|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  utf8mb4 mysql| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by collinanderson):

 * cc: cmawebsite@… (added)


Comment:

 One solution would be to reduce the INDEX size to 191 for mysql, like the
 example above:

 col1 VARCHAR(500) CHARACTER SET utf8mb4, INDEX (col1(191))"

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

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

Re: [Django] #24104: SQLite schema should to look for internal type of field instead of class instance when choosing a default for created fields

2015-01-22 Thread Django

#24104: SQLite schema should to look for internal type of field instead of class
instance when choosing a default for created fields
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Release blocker  |   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 MarkusH):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #24198: Options.get_field behavior change

2015-01-22 Thread Django

Comment (by xordoquy):

Hi Daniel,

Unfortunately I don't think it is as easy as it sounds. This happened with
a GFK, but could be with any field that doesn't inherit from `Field`.
I didn't read the migration part because I'm not just migrating: I'm
supporting Django 1.4 to 1.8. My workaround is there:
https://github.com/linovia/django-rest-
framework/commit/857185cf07bb539083a90bc75a6dd951da8e2206
I am not sure the field flag you are mentioning was available for 1.4

Anyway, I feel it's kind of a documentation issue but I'm not sure what's
the best way to deal with this.

`get_field` isn't even mentioned in the release notes. I don't think it
was part of the public API so I'm not sure it should even be mentioned.
However, as the behavior change, I'd assume it is worth adding a notice
about this in the backward incompatible change section since its behavior
has changed.

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

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

Re: [Django] #24198: Options.get_field behavior change

2015-01-22 Thread Django

Comment (by pirosb3):

Replying to [comment:3 xordoquy]:
> Thanks Tim. I'm sorry I totally missed the migration guide.
Hi,

As Tim confirmed, the new Meta API allows GenericForeignKeys too. If you
are concerned this can be an issue on your side, you can easily filter it
our using the field flags. It should be the only field that has a '''one-
to-many''' cardinality without a specific '''related_model''' set.
As stated in the guide, '''related_model''' can be None if the relation is
generic.
Please feel free to contact me on IRC for any issues.

Dan

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

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

Re: [Django] #24202: Implement a SensitiveTextInput widget for sensitive input fields

2015-01-22 Thread Django

#24202: Implement a SensitiveTextInput widget for sensitive input fields
-+--
 Reporter:  hakanw   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  1.7
 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 hakanw):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Forms
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => New feature


Old description:

> If you're implementing Stripe, Adyen, or other big payment solutions
> today, then you can use client side encryption, where form fields are
> used for inputting e.g. credit card number (etc), but that will be
> encrypted before the form is submitted to the server. These fields should
> not be sent raw to the server, so you usually remove the name attribute
> on the input fields.
>
> It would be really useful if django had a SensitiveTextInput widget that
> just removed its name attribute. This idea is from here:
> http://stackoverflow.com/questions/18116917/change-form-input-attribute-
> name-to-data-encrypted-name
>
> Suggested class:
>
> {{{python
> # a text input widget with no name attribute
> class SensitiveTextInput(forms.TextInput):
> def build_attrs(self, extra_attrs=None, **kwargs):
> attrs = super(SensitiveTextInput, self).build_attrs(extra_attrs,
> **kwargs)
> if 'name' in attrs:
> del attrs['name']
> return attrs
> }}}

New description:

 If you're implementing Stripe, Adyen, or other big payment solutions
 today, then you can use client side encryption, where form fields are used
 for inputting e.g. credit card number (etc), but that will be encrypted
 before the form is submitted to the server. These fields should not be
 sent raw to the server, so you usually remove the name attribute on the
 input fields.

 It would be really great if django had a SensitiveTextInput widget for
 purposes like this. This idea is from here:
 http://stackoverflow.com/questions/18116917/change-form-input-attribute-
 name-to-data-encrypted-name

 Here's a suggested class:

 {{{
 #!python
 # a text input widget with no name attribute
 class SensitiveTextInput(forms.TextInput):
 def build_attrs(self, extra_attrs=None, **kwargs):
 attrs = super(SensitiveTextInput, self).build_attrs(extra_attrs,
 **kwargs)
 if 'name' in attrs:
 del attrs['name']
 return attrs
 }}}

--

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

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

[Django] #24202: Implement a SensitiveTextInput widget for sensitive input fields

2015-01-22 Thread Django

#24202: Implement a SensitiveTextInput widget for sensitive input fields
---+
 Reporter:  hakanw |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 If you're implementing Stripe, Adyen, or other big payment solutions
 today, then you can use client side encryption, where form fields are used
 for inputting e.g. credit card number (etc), but that will be encrypted
 before the form is submitted to the server. These fields should not be
 sent raw to the server, so you usually remove the name attribute on the
 input fields.

 It would be really useful if django had a SensitiveTextInput widget that
 just removed its name attribute. This idea is from here:
 http://stackoverflow.com/questions/18116917/change-form-input-attribute-
 name-to-data-encrypted-name

 Suggested class:

 {{{python
 # a text input widget with no name attribute
 class SensitiveTextInput(forms.TextInput):
 def build_attrs(self, extra_attrs=None, **kwargs):
 attrs = super(SensitiveTextInput, self).build_attrs(extra_attrs,
 **kwargs)
 if 'name' in attrs:
 del attrs['name']
 return attrs
 }}}

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

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

Re: [Django] #23558: document slugify limitations

2015-01-22 Thread Django

#23558: document slugify limitations
--+
 Reporter:  kmike |Owner:  dhoffman
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:  fixed
 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 Haakenlid):

 Is this the new documentation?

  Converts to ASCII. Converts spaces to hyphens. Removes characters that
 aren't alphanumerics, underscores, or hyphens. Converts to lowercase.
 Also strips leading and trailing whitespace.

 Where can I find out which alphanumerics are deleted, and which
 alphanumerics are converted to ASCII?

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

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

Re: [Django] #24170: DateTimeRangeField: widget doesn't implement decompress()

2015-01-22 Thread Django

#24170: DateTimeRangeField: widget doesn't implement decompress()
-+-
 Reporter:  joelburton   |Owner:  ngzhian
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  DateTimeRangeField   | Triage Stage:  Ready for
  decompress |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by MarkusH):

 * needs_docs:  1 => 0
 * needs_tests:  1 => 0
 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #24200: Make introspection bypass statement caching on Oracle

2015-01-22 Thread Django

#24200: Make introspection bypass statement caching on Oracle
-+-
 Reporter:  shaib|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:  Accepted
  introspection  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jarshwah):

 The flush shared_pool just flushes server side statements AFAIK, and
 doesn't work with the recommended privileges (you need system-like privs).

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

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

Re: [Django] #24200: Make introspection bypass statement caching on Oracle

2015-01-22 Thread Django

#24200: Make introspection bypass statement caching on Oracle
-+-
 Reporter:  shaib|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:  Accepted
  introspection  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.9aed715324368adef11cbed99943ad44%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

39 matches

Mail list logo