date:20180305

Re: [Django] #29186: "django.request" logging breaks "logging.handlers.SocketHandler"

2018-03-05 Thread Django

#29186: "django.request" logging breaks "logging.handlers.SocketHandler"
--+
 Reporter:  direx |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  2.0
 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 direx):

 Just for the record: A custom SocketHandler which works around this
 problem could look like this:

 {{{
 # -*- coding: utf-8 -*-
 from logging.handlers import SocketHandler as _SocketHandler

 class DjangoSocketHandler(_SocketHandler):
 def emit(self, record):
 if hasattr(record, 'request'):
 record.request = None
 return super().emit(record)
 }}}

 I don't know if you guys want to ship this as a workaround and update the
 documentation accordingly. This could also be a ''documentation-only'' fix
 where this code is added as an example for socket logging.

 On the other hand an actual fix would be nice of course. I know this is
 not an easy task and since the majority of people probably won't be using
 socket logging, a documented and supported workaround (such as the code
 above) might be sufficient.

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

Re: [Django] #28959: Clicking "No, take me back" on the delete selected inline foreign key / one-to-one field confirmation page does nothing

2018-03-05 Thread Django

#28959: Clicking "No, take me back" on the delete selected inline foreign key /
one-to-one field confirmation page does nothing
---+
 Reporter:  Josh Schneier  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  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 Josh Schneier):

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

Re: [Django] #29184: TabularInline read-only fields ignore ModelForm Meta.labels and help_texts

2018-03-05 Thread Django

#29184: TabularInline read-only fields ignore ModelForm Meta.labels and 
help_texts
-+-
 Reporter:  David Sanders|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  readonly,| Triage Stage:  Accepted
  help_texts, labels |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by David Sanders):

 Tweaked the patch a little bit to fix a situation it broke with pure form
 fields (no model 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.0303c8866ee3172678d7f017fbc7dcb9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29184: TabularInline read-only fields ignore ModelForm Meta.labels and help_texts

2018-03-05 Thread Django

#29184: TabularInline read-only fields ignore ModelForm Meta.labels and 
help_texts
-+-
 Reporter:  David Sanders|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  readonly,| Triage Stage:  Accepted
  help_texts, labels |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Sanders):

 * Attachment "tabularinline_label_and_help_text_2.patch" added.

 Fixed patch

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

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

Re: [Django] #27317: Make Form subclasses combine Form.Media from all parents

2018-03-05 Thread Django

#27317: Make Form subclasses combine Form.Media from all parents
-+
 Reporter:  James Pic|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  1.10
 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 James Pic):

 Yes, because currently we can not know if we should or not add a media.
 For example this would allow it:

 {{{
 class YourForm(forms.Form):
 def add_media(self, media):
 if not media.js.find('jquery.js'):  # might have been added from
 another app?
 media.js.add('/yourapp/jquery.js')
 media.js.add('b.js')
 }}}

 Also, probably we should be limited to one Media object per request.

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

Re: [Django] #29189: BoundField: extra css classes

2018-03-05 Thread Django

#29189: BoundField: extra css classes
-+--
 Reporter:  James Pic|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  2.0
 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 James Pic):

 Sure, well i think it's really necessary to limit to only one Media object
 per request.
 Also, you need to identify your scripts with something, ie. npm module
 name+version, so you can deduplicate when 2 widgets add the same (even
 with different file name because they come from different packages).
 Finnaly, you need it to be able to populate itself with a Form object.

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

Re: [Django] #29189: BoundField: extra css classes

2018-03-05 Thread Django

#29189: BoundField: extra css classes
-+--
 Reporter:  James Pic|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  2.0
 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 Tim Graham):

 My initial reaction is that the `BoundField.css_classes()` method, added
 in 92803205cbcaaee16ac0eb724c45019a9d896aac (#3512), is somewhat
 problematic since it's only used by the `as_p()`, `as_ul()`, and
 `as_table()` methods. Adding a `BoundField` attribute like
 `extra_css_classes` that's only respected there doesn't seem good. Perhaps
 with some more thinking we can come up with a more elegant solution.

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

Re: [Django] #29188: ContentFile.size remains constant after initializing

2018-03-05 Thread Django

#29188: ContentFile.size remains constant after initializing
--+
 Reporter:  Maksim Iakovlev   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  File uploads/storage  |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

 * component:  Uncategorized => File uploads/storage
 * 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/067.3a8f9189bad8a2d2d388ef371c9736b3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29187: test_delete_signals occasionally fails when running all django tests

2018-03-05 Thread Django

#29187: test_delete_signals occasionally fails when running all django tests
-+-
 Reporter:  Jacob Mulford|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  tests, unit tests| Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * component:  Testing framework => Core (Other)
 * stage:  Unreviewed => Someday/Maybe


Comment:

 I haven't seen that failure before, but if someone identifies the cause,
 please let us know.

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

Re: [Django] #28943: Avoid the need to call get_context_data() in TemplateView subclasses

2018-03-05 Thread Django

#28943: Avoid the need to call get_context_data() in TemplateView subclasses
-+-
 Reporter:  James Pic|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Generic views|  Version:  2.0
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by James Pic):

 Yes, returning super().get() allows to bypass the last level of get()
 override. I try to demonstrate the issue with this script, perhaps it will
 make more sense.

 {{{
 class TemplateView(object):
 def get(self):
 print('render to response()')


 class YourBaseView(TemplateView):
 def get(self):
 print('generate token()')
 return super().get()


 class YourView(YourBaseView):
 def post(self):
 # if not dosomething(): return bad request
 return super().get()


 YourView().post()
 }}}

 This will print both 'generate token()' and 'render to response()'. If I
 only want to print 'render to response()', then this works:

 {{{
 class YourView(YourBaseView):
 def post(self):
 # if not dosomething(): return bad request
 return TemplateView.get(self)
 }}}

 But probably it would make sense to just move the render to response
 outside get() as such:

 {{{
 class TemplateView(object):
 def render_to_response(self):
 print('render to response()')

 def get(self):
 return self.render_to_response()


 class YourBaseView(TemplateView):
 def get(self):
 print('generate token()')
 return super().get()


 class YourView(YourBaseView):
 def post(self):
 # if not dosomething(): return bad request
 return self.render_to_response()
 }}}

 For me it seems like the last solution is best OOP but perhaps i'm
 mistaking 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.22c87d2e0ac3258a991cb85831056917%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29187: test_delete_signals occasionally fails when running all django tests

2018-03-05 Thread Django

#29187: test_delete_signals occasionally fails when running all django tests
---+--
 Reporter:  Jacob Mulford  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  2.0
 Severity:  Normal |   Resolution:
 Keywords:  tests, unit tests  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Jacob Mulford):

 I added a print statement in 'tests/signals/tests.py' to see the
 difference between 'signals.pre_delete.receivers' and
 'signals.post_delete.receivers' and noticed that they were not the same
 when running all of the unit tests compared to running just the
 'signals.tests.SignalTests' tests.

 Isolating the signals.tests.SignalTests unit tests

 {{{
 (djangodev) jakemulf@jakemulf-
 Aspire-E5-574G:~/projects/open_source_projects/django$ python
 tests/runtests.py signals.tests.SignalTests
 Testing against Django installed in
 '/home/jakemulf/projects/open_source_projects/django/django' with up to 4
 processes
 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 System check identified no issues (0 silenced).
 [((140297206139216, 37859832), )]
 []
 .[((140297206139216, 37859832), )]
 []
 .[((140297206139216, 37859832), )]
 []
 .[((140297206139216, 37859832), )]
 []
 .[((140297206139216, 37859832), )]
 []
 .[((140297206139216, 37859832), )]
 []
 .[((140297206139216, 37859832), )]
 []
 .
 --
 Ran 7 tests in 0.016s

 OK
 Destroying test database for alias 'default'...
 Destroying test database for alias 'other'...
 (djangodev) jakemulf@jakemulf-
 Aspire-E5-574G:~/projects/open_source_projects/django$
 }}}

 Running all unit tests with success

 {{{
 (djangodev) jakemulf@jakemulf-
 Aspire-E5-574G:~/projects/open_source_projects/django$ python
 tests/runtests.py
 Testing against Django installed in
 '/home/jakemulf/projects/open_source_projects/django/django' with up to 4
 processes
 Creating test database for alias 'default'...
 Cloning test database for alias 'default'...
 Cloning test database for alias 'default'...
 Cloning test database for alias 'default'...
 Cloning test database for alias 'default'...
 Creating test database for alias 'other'...
 Cloning test database for alias 'other'...
 Cloning test database for alias 'other'...
 Cloning test database for alias 'other'...
 Cloning test database for alias 'other'...
 System check identified no issues (14 silenced).

Re: [Django] #29189: BoundField: extra css classes

2018-03-05 Thread Django

#29189: BoundField: extra css classes
-+--
 Reporter:  James Pic|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  2.0
 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 James Pic):

 * cc: James Pic (added)
 * type:  Uncategorized => New feature


Old description:

> Currently,
> [https://github.com/django/django/blob/d368784bacc7e58b426f29937ee842aa14d439ad/django/forms/forms.py#L218
> Form._html_output()] calls
> [https://github.com/django/django/blob/d368784bacc7e58b426f29937ee842aa14d439ad/django/forms/boundfield.py#L166
> BoundField.css_classes()] to get the list of classes to apply on the
> field container, such as error_css_class or required_css_class.
>
> My objective is something like :
> {{{
> form['myfield'].extra_css_classes = 'hide'
> }}}
>
> (Setting the class in JS too, but this causes a flash of course)
>
> Could we perhaps allow adding extra css classes to BoundField ?
>
> Currently I have this little hack which works but isn't doing anything
> that's supposed to be supported so please bare with me, it's just here to
> serve as an example and attempt to illustrate what I would like to get
> rid of in my own code:
>
> {{{
> class BoundField(forms.BoundField):
> """BoundField override for facond Form."""
>
> def css_classes(self):
> """Allow setting extra_css_classes."""
> return super(BoundField, self).css_classes(
> getattr(self, 'extra_css_classes', ''))
>
> class Form(forms.Form):
> def __init__(self, *args, **kwargs):
> super().__init__(*args, **kwargs)
> for name, field in self.fields.items():
> # not sure what it breaks to instanciate BoundFields here
> # rather than in __getitem__
> self._bound_fields_cache[name] = BoundField(self, field,
> name)
> }}}
>
> Thanks in advance for your feedback

New description:

 Currently,
 
[https://github.com/django/django/blob/d368784bacc7e58b426f29937ee842aa14d439ad/django/forms/forms.py#L218
 Form._html_output()] calls
 
[https://github.com/django/django/blob/d368784bacc7e58b426f29937ee842aa14d439ad/django/forms/boundfield.py#L166
 BoundField.css_classes()] to get the list of classes to apply on the field
 container, such as error_css_class or required_css_class.

 My objective is something like :
 {{{
 form['myfield'].extra_css_classes = 'hide'
 }}}

 (Setting the class in JS too, but this causes a flash of course)

 Could we perhaps allow adding extra css classes to BoundField ?

 Currently I have this little hack which works but isn't doing anything
 that's supposed to be supported so please bare with me, it's just here to
 serve as an example and attempt to illustrate what I would like to get rid
 of in my own code:

 {{{
 class BoundField(forms.BoundField):
 """BoundField override for facond Form."""

 def css_classes(self):
 """Allow setting extra_css_classes."""
 return super(BoundField, self).css_classes(
 getattr(self, 'extra_css_classes', ''))

 class Form(forms.Form):
 def __init__(self, *args, **kwargs):
 super().__init__(*args, **kwargs)
 for name, field in self.fields.items():
 # not sure what it breaks to instanciate BoundFields here
 # rather than in __getitem__
 self._bound_fields_cache[name] = BoundField(self, field, name)
 }}}

 Thanks in advance for your feedback, I can submit a patch if you want.

--

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

[Django] #29189: BoundField: extra css classes

2018-03-05 Thread Django

#29189: BoundField: extra css classes
-+
   Reporter:  James Pic  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Forms  |Version:  2.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Currently,
 
[https://github.com/django/django/blob/d368784bacc7e58b426f29937ee842aa14d439ad/django/forms/forms.py#L218
 Form._html_output()] calls
 
[https://github.com/django/django/blob/d368784bacc7e58b426f29937ee842aa14d439ad/django/forms/boundfield.py#L166
 BoundField.css_classes()] to get the list of classes to apply on the field
 container, such as error_css_class or required_css_class.

 My objective is something like :
 {{{
 form['myfield'].extra_css_classes = 'hide'
 }}}

 (Setting the class in JS too, but this causes a flash of course)

 Could we perhaps allow adding extra css classes to BoundField ?

 Currently I have this little hack which works but isn't doing anything
 that's supposed to be supported so please bare with me, it's just here to
 serve as an example and attempt to illustrate what I would like to get rid
 of in my own code:

 {{{
 class BoundField(forms.BoundField):
 """BoundField override for facond Form."""

 def css_classes(self):
 """Allow setting extra_css_classes."""
 return super(BoundField, self).css_classes(
 getattr(self, 'extra_css_classes', ''))

 class Form(forms.Form):
 def __init__(self, *args, **kwargs):
 super().__init__(*args, **kwargs)
 for name, field in self.fields.items():
 # not sure what it breaks to instanciate BoundFields here
 # rather than in __getitem__
 self._bound_fields_cache[name] = BoundField(self, field, name)
 }}}

 Thanks in advance for your feedback

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

Re: [Django] #19544: IntegrityError during Many To Many add()

2018-03-05 Thread Django

#19544: IntegrityError during Many To Many add()
-+-
 Reporter:  German M. Bravo  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Andrey Fedoseev):

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

[Django] #29188: ContentFile.size remains constant after initializing

2018-03-05 Thread Django

#29188: ContentFile.size remains constant after initializing
---+
   Reporter:  Maksim Iakovlev  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Uncategorized|Version:  1.11
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 {{{
 >>> cf = ContentFile('')
 >>> cf.size
 0
 >>> cf.write('asd')
 3L
 >>> cf.size
 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/052.1cff79163a948fd90a9ab38525426b69%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28132: File upload crash with "TemporaryFileUploadHandler object has no attribute 'file'" error

2018-03-05 Thread Django

#28132: File upload crash with "TemporaryFileUploadHandler object has no 
attribute
'file'" error
-+-
 Reporter:  Michal Čihař |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  1.10
  uploads/storage|
 Severity:  Normal   |   Resolution:  needsinfo
 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 Jirka Vejrazka):

 I've recently seen the same bug (Django 1.11). It was also during a
 security review. I managed to save some POST arguments and I guess the
 problem is caused by the completely invalid `file` and `name` arguments,
 namely:
 {{{
 "file": "'", "name": "'",
 }}}

 I'll try to create a test case tomorrow if I have time.

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

[Django] #29187: test_delete_signals occasionally fails when running all django tests

2018-03-05 Thread Django

#29187: test_delete_signals occasionally fails when running all django tests
-+-
   Reporter:  Jacob  |  Owner:  nobody
  Mulford|
   Type:  Bug| Status:  new
  Component:  Testing|Version:  2.0
  framework  |
   Severity:  Normal |   Keywords:  tests, unit tests
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'm unable to replicate this consistently (outside of random chance) but
 occasionally test_delete_signals fails with the following error message
 when running all of the django tests:

 {{{
 (djangodev) jakemulf@jakemulf-
 Aspire-E5-574G:~/projects/open_source_projects/django$ python
 tests/runtests.py
 Testing against Django installed in
 '/home/jakemulf/projects/open_source_projects/django/django' with up to 4
 processes
 Creating test database for alias 'default'...
 Cloning test database for alias 'default'...
 Cloning test database for alias 'default'...
 Cloning test database for alias 'default'...
 Cloning test database for alias 'default'...
 Creating test database for alias 'other'...
 Cloning test database for alias 'other'...
 Cloning test database for alias 'other'...
 Cloning test database for alias 'other'...
 Cloning test database for alias 'other'...
 System check identified no issues (14 silenced).

Re: [Django] #22449: Colorize output of test results

2018-03-05 Thread Django

Comment (by Chris Jerdonek):

Personally, I disagree that the lack of color is a "major testing
usability problem," or even that it's a problem at all. I would consider
it a nice to have. Also, in my opinion, the PR that was proposed had
issues independent of upstream, but the author volunteered to close the
ticket.

Lastly, while there are certainly things that can be added or improved
about Django testing, I think testing usability on the whole is great. I
don't see how you can be calling it a mess.

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

Re: [Django] #29174: makemessages does not find translations in Python 3.6 formatted string literals

2018-03-05 Thread Django

#29174: makemessages does not find translations in Python 3.6 formatted string
literals
-+-
 Reporter:  Artem Skoretskiy |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  2.0
  Internationalization   |
 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 Tim Graham):

 I don't have much expertise about translations but is this a Python or
 xgettext issue rather than something Django can solve?

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

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

Re: [Django] #29175: makemessages does parse ES6 template strings

2018-03-05 Thread Django

#29175: makemessages does parse ES6 template strings
-+-
 Reporter:  Artem Skoretskiy |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  2.0
  Internationalization   |
 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 Tim Graham):

 Isn't this an [https://savannah.gnu.org/bugs/?50920 xgettext issue] rather
 than something Django can solve?

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

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

Re: [Django] #29184: TabularInline read-only fields ignore ModelForm Meta.labels and help_texts (was: TabularInline Read-only Fields Ignore ModelForm._meta Label and Help Text Overrides)

2018-03-05 Thread Django

#29184: TabularInline read-only fields ignore ModelForm Meta.labels and 
help_texts
-+-
 Reporter:  David Sanders|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  readonly,| Triage Stage:  Accepted
  help_texts, labels |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted
 * needs_tests:  0 => 1


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

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

Re: [Django] #29183: "cache" template tag should not render empty strings on failure

2018-03-05 Thread Django

#29183: "cache" template tag should not render empty strings on failure
-+-
 Reporter:  Nicolas Le Manchet   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (Cache system)  |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  cache, template, | Triage Stage:
  memcached, pylibmc |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * easy:  1 => 0


Comment:

 The behavior is different on the master branch. As of
 e62165b898785e890661953c3b2c9c36d98aee57, `{% include %}` no longer
 silences exceptions. Do you want to propose a different behavior (such as
 `{% cache %}` silencing the exception)? I'm not sure whether or not there
 would be consensus to do that, but you could write to the
 DevelopersMailingList to get feedback.

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

Re: [Django] #28981: GeoIP2 should error when GEOIP_PATH exists but there is no MaxMind database

2018-03-05 Thread Django

#28981: GeoIP2 should error when GEOIP_PATH exists but there is no MaxMind 
database
-+-
 Reporter:  Hugo Rodger-Brown|Owner:  Alex
 Type:   |  Stovbur
  Cleanup/optimization   |   Status:  closed
Component:  GIS  |  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  geoip2 maxmind   | Triage Stage:  Accepted
  GEOIP_PATH |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"d171843f5715b4c0162ab800539bd25ad60147c7" d171843f]:
 {{{
 #!CommitTicketReference repository=""
 revision="d171843f5715b4c0162ab800539bd25ad60147c7"
 Fixed #28981 -- Added an exception if GeoIP database can't be loaded from
 the path.
 }}}

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

Re: [Django] #29186: "django.request" logging breaks "logging.handlers.SocketHandler"

2018-03-05 Thread Django

#29186: "django.request" logging breaks "logging.handlers.SocketHandler"
--+
 Reporter:  direx |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  2.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

 * component:  Uncategorized => Core (Other)
 * stage:  Unreviewed => Accepted


Comment:

 I'm not sure what the best solution is, but I don't think removing
 `request` from `extra` is acceptable as that would be backwards
 incompatible for logging handlers using that information.

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

[Django] #29186: "django.request" logging breaks "logging.handlers.SocketHandler"

2018-03-05 Thread Django

#29186: "django.request" logging breaks "logging.handlers.SocketHandler"
-+
   Reporter:  direx  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  2.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 When setting up logging with Python's default `SocketHandler` then the log
 messages produced by `django.request` cause an exception in the logging
 system. This happens everywhere where Django passes an `extra={'request':
 request}` dictionary to log messages. The reason for this is that the
 request object cannot be pickled.

 Steps to reproduce (example):

 1. `./manage.py startproject`
 1. Add this logging config in settings:
 {{{
 LOGGING = {
 'version': 1,
 'disable_existing_loggers': False,
 'handlers': {
 'socket_handler': {
 'class': 'logging.handlers.SocketHandler',
 'host': '127.0.0.1',
 'port': 9020,
 }
 },
 'loggers': {
 'django.request': {
 'handlers': ['socket_handler'],
 'level': 'INFO',
 'propagate': False,
 },
 }
 }
 }}}
 1. `./manage.py migrate`
 1. `./manage.py runserver`
 1. `wget http://127.0.0.1:8000/invalid -O /dev//null`

 The exception is this one:

 {{{
 --- Logging error ---
 Traceback (most recent call last):
   File "/usr/lib/python3.6/logging/handlers.py", line 633, in emit
 s = self.makePickle(record)
   File "/usr/lib/python3.6/logging/handlers.py", line 605, in makePickle
 s = pickle.dumps(d, 1)
   File "/usr/lib/python3.6/copyreg.py", line 65, in _reduce_ex
 raise TypeError("can't pickle %s objects" % base.__name__)
 TypeError: can't pickle BufferedReader objects
 Call stack:
   File "/usr/lib/python3.6/threading.py", line 884, in _bootstrap
 self._bootstrap_inner()
   File "/usr/lib/python3.6/threading.py", line 916, in _bootstrap_inner
 self.run()
   File "/usr/lib/python3.6/threading.py", line 864, in run
 self._target(*self._args, **self._kwargs)
   File "/usr/lib/python3.6/socketserver.py", line 639, in
 process_request_thread
 self.finish_request(request, client_address)
   File "/usr/lib/python3.6/socketserver.py", line 361, in finish_request
 self.RequestHandlerClass(request, client_address, self)
   File "/usr/lib/python3.6/socketserver.py", line 696, in __init__
 self.handle()
   File "/home/direx/virtualenv/django-2.0/lib/python3.6/site-
 packages/django/core/servers/basehttp.py", line 154, in handle
 handler.run(self.server.get_app())
   File "/usr/lib/python3.6/wsgiref/handlers.py", line 137, in run
 self.result = application(self.environ, self.start_response)
   File "/home/direx/virtualenv/django-2.0/lib/python3.6/site-
 packages/django/contrib/staticfiles/handlers.py", line 66, in __call__
 return self.application(environ, start_response)
   File "/home/direx/virtualenv/django-2.0/lib/python3.6/site-
 packages/django/core/handlers/wsgi.py", line 146, in __call__
 response = self.get_response(request)
   File "/home/direx/virtualenv/django-2.0/lib/python3.6/site-
 packages/django/core/handlers/base.py", line 93, in get_response
 extra={'status_code': 404, 'request': request},
 Message: 'Not Found: %s'
 Arguments: ('/invalid',)
 }}}


 Of course these steps are only an example. This bug does not only apply to
 404 errors, but also to CSRF verfication errors for instance. In fact all
 places where the `request` object is passed in as an `extra` logger
 argument.

 I see a few possible solutions for this issue:

 1. Remove the `request` object from the `extra` log message dict. Right
 now I am not even sure why this is required.
 1. Make the entire `request` object pickleable (probably not an easy task)
 1. Pass in a reduced (pickable) version of the request object in the
 `extra` dict
 1. Ship a compatible version of `SocketHandler`

 BTW: socket logging is explicitly mentioned in the Django docs:

 > The handler is the engine that determines what happens to each message
 in a logger. It describes a particular logging behavior, such as writing a
 message to the screen, to a file, **or to a network socket**.

 This bug also applies to older Django versions.

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

Re: [Django] #22449: Colorize output of test results

2018-03-05 Thread Django

Comment (by Rich Jones):

This is a bad decision and the related PR should be merged.

The fact that there exists an obscure, ancient, unmaintained and unused
third party library that also implements this (with 7 stars on GitHub and
the last serious commit 4 years ago) is not a reason to ignore this facet
of major testing usability problem that Django has.

If you don't like the solution because there are upstream changes which
need to be added, you should then create those upstream tickets, and in
the meantime accept the PR until the upstream changes land. It's not good
maintainership to ignore good work and completely punt the issue.

Testing usability in Django is an absolute mess and anything to help
improve it should be welcomed, not abandoned after all the work is done.

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

Re: [Django] #29120: Document that the admin autocomplete requires the change permission of the related model

2018-03-05 Thread Django

#29120: Document that the admin autocomplete requires the change permission of 
the
related model
-+-
 Reporter:  Rodrigo Pinheiro |Owner:  Johannes
  Marques de Araújo  |  Hoppe
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  2.0
 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 Tim Graham):

 I'm fairly certain the code is correct. If editing a choice and the
 related object is question, then the JSON view loads questions, so the
 change permission for question is checked. This is consistent with how
 `raw_id_fields` works.

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

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

Re: [Django] #29165: Initial data howto could better explain how to use migrations

2018-03-05 Thread Django

#29165: Initial data howto could better explain how to use migrations
-+-
 Reporter:  Michel Samia |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  initial data | Triage Stage:  Accepted
  migrations |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/9753 PR]

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

Re: [Django] #29179: format_html() can falsely interpret a strack trace as a str.format replacement field

2018-03-05 Thread Django

#29179: format_html() can falsely interpret a strack trace as a str.format
replacement field
-+-
 Reporter:  Stephan Michaud  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  1.10
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  format_html, string  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


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

Re: [Django] #25313: Document how to migrate from a built-in User model to a custom User model

2018-03-05 Thread Django

#25313: Document how to migrate from a built-in User model to a custom User 
model
---+
 Reporter:  Carl Meyer |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.8
 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 Justin Smith):

 Replying to [comment:2 Aymeric Augustin]:
 > I did it at least twice. Unfortunately I don't remember all the details.
 >
 > I think a reasonable procedure is:
 >
 > 1. Create a custom user model identical to `auth.User`, call it `User`
 (so many-to-many tables keep the same name) and set `db_table='auth_user'`
 (so it uses the same table)
 > 2. Throw away all your migrations
 > 3. Recreate a fresh set of migrations
 > 4. Sacrifice a chicken, perhaps two if you're anxious; also make a
 backup of your database
 > 5. Truncate the `django_migrations` table
 > 6. Fake-apply the new set of migrations
 > 7. Unset `db_table`, make other changes to the custom model, generate
 migrations, apply them
 >
 > It is highly recommended to do this on a database that enforces foreign
 key constraints. Don't try this on SQLite on your laptop and expect it to
 work on Postgres on the servers!

 Just recently had to go through this process using a Microsoft SQL Server
 backend and used the steps above as my guideline. Just thought I'd drop in
 and include some of my notes just in case they can help anyone in the
 future.

 Notes (by step):
 1. Make sure the custom user model identical to auth.User is an
 `AbstractUser` model. I originally made this mistake because I did an
 `inspectdb auth_user` and just copy/pasted so I left it as `models.Model`
 at first. Since I copied and pasted from `inspectdb` I went ahead and
 removed `managed = False`
 2. Quick shortcut to delete migrations for all apps in a project I used
 was `find . -path "*/migrations/*.py" -not -name "__init__.py" -delete`.
 3. No additional notes
 4. Not kidding about the back up I had to start over a few times
 5. No additional notes
 6. I did `--fake-initial` first few times and not `--fake`
 7. No notes

 Thank you very much for posting this in the first place I am not sure I
 would have figured this out on my own and saved us mid-project. I have
 learned my lesson about starting a django project and not setting up
 custom user model.

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

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

Re: [Django] #29171: PostgreSQL specific model fields - ArrayField: Type Mismatch

2018-03-05 Thread Django

#29171: PostgreSQL specific model fields - ArrayField: Type Mismatch
-+-
 Reporter:  Pal  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Postgres Array   | Triage Stage:
  Query  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I'm still not sure we have enough details to reproduce the issue. What
 does the SQL for the table look like, what does your model look like, and
 what does the failing QuerySet look like?

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

Re: [Django] #11964: Add the ability to use database-level CHECK CONSTRAINTS

2018-03-05 Thread Django

#11964: Add the ability to use database-level CHECK CONSTRAINTS
-+-
 Reporter:  Matthew Schinckel|Owner:  Ian Foote
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  check contsraint | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Michael Wheeler):

 * cc: Michael Wheeler (added)


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

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

Re: [Django] #28574: Add a QuerySet.explain() method

2018-03-05 Thread Django

#28574: Add a QuerySet.explain() method
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 |  Forbes
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Carlton Gibson):

 * needs_better_patch:  0 => 1
 * stage:  Ready for checkin => Accepted


Comment:

 The new tests fail on Oracle. Needs resolving. (Hopefully good to go
 then.)

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

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

Re: [Django] #28715: Prevent a migration changing DateTimeField(auto_now_add=True) to default=timezone.now from generating SQL

2018-03-05 Thread Django

#28715: Prevent a migration changing DateTimeField(auto_now_add=True) to
default=timezone.now from generating SQL
--+
Reporter: Дилян Палаузов|Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Migrations| 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
--+

Comment (by Дилян Палаузов):

The purpose of the change is to tweak the migrations auto_now_add ->
default for DateField and DateTimeField not to call

ALTER TABLE SET DEFAULT '2017-10-16T09:35:52.710695'::timestamp;
ALTER TABLE DROP DEFAULT

towards the database. The attached auto_now_add_skip_sql_calls.2.patch
touches BaseDatabaseSchemaEditor, and does generate a migration, which
however skips modifying the DEFAULT.

auto_now_add being possibly deprecated means that this type of migration
will be created more often in the future and this patch accelerates the
execution of the migration (as it does not lock the table).

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

Re: [Django] #28715: Prevent a migration changing DateTimeField(auto_now_add=True) to default=timezone.now from generating SQL

2018-03-05 Thread Django

#28715: Prevent a migration changing DateTimeField(auto_now_add=True) to
default=timezone.now from generating SQL
--+
 Reporter:  Дилян Палаузов|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  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 Дилян Палаузов):

 * Attachment "auto_now_add_skip_sql_calls.2.patch" 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/072.6eade91342babd2c6945f396c8b6ac9e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29180: makemigrations autodetector ignoring existing migrations

2018-03-05 Thread Django

#29180: makemigrations autodetector ignoring existing migrations
-+
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Carlton Gibson):

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

Re: [Django] #28574: Add a QuerySet.explain() method

2018-03-05 Thread Django

#28574: Add a QuerySet.explain() method
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 |  Forbes
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Carlton Gibson):

 * stage:  Accepted => Ready for checkin


Comment:

 Patch looks good.

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

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

Re: [Django] #29120: Document that the admin autocomplete requires the change permission of the related model

2018-03-05 Thread Django

#29120: Document that the admin autocomplete requires the change permission of
the
related model
-+-
Reporter: Rodrigo Pinheiro |Owner: Johannes
Marques de Araújo | Hoppe
Type: Bug | Status: assigned
Component: contrib.admin| Version: 2.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0| Needs documentation: 0
Needs tests: 0| Patch needs improvement: 0
Easy pickings: 0|UI/UX: 0
-+-
Changes (by Johannes Hoppe):

* owner: nobody => Johannes Hoppe
* status: new => assigned
* component: Documentation => contrib.admin
* type: Cleanup/optimization => Bug

Comment:

Hi,

this isn't expected behavior bug a if not a security issue. It should
check the if user has access to the change admin of the origin model, not
the related one. I think this was introduced with a commit from Florian,
when he simplified the code.

I have an idea on how to fix this. I will work on a fix asap.

Best
-Joe

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

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

38 matches

Mail list logo