[Django] #31974: SplitDateTimeWidget and is_valid problem

2020-09-01 Thread Django
#31974: SplitDateTimeWidget and is_valid problem
-+-
   Reporter:  carson512  |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component:  Forms  |Version:  3.0
   Severity:  Normal |   Keywords:  SplitDateTimeWidget
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 this the models.py
 {{{
 class Rent_Car(models.Model):
 rent_time = models.DateTimeField( blank=False)
 car = models.ForeignKey(Cop_Car, on_delete=models.SET_NULL, null=True,
 blank=False)
 user = models.ForeignKey(Users, on_delete=models.SET_NULL, null=True,
 blank=False)
 car_rage = models.IntegerField(null=False, blank=False)
 rent_mark = models.CharField(max_length=300", null=True, blank=True)
 }}}
 this the forms.py
 {{{
 class RentcarForm(forms.ModelForm):
 class Meta:
 model = models.Rent_Car
 fields = '__all__'
 # model.rent_time =
 forms.DateTimeField(widget=forms.SplitDateTimeWidget)
 # initial = datetime.datetime.now()
 # model.rent_time = datetime.datetime.now()
 widgets = {
 'rent_time': forms.SplitDateTimeWidget(date_attrs={'class
 ':'form-control', 'type':'date'},time_attrs={'class':'form-control',
 'type':'time'},date_format='%Y-%m-%d'),
 }

 def __init__(self,*args,**kwargs):
 super().__init__(*args,**kwargs)
 for field_name,field in self.fields.items():
 field.widget.attrs.update({'class':'form-control'})
 }}}

 this is the views.py


 {{{

 def rentcar_add_edit(request, rid=None):

 rentcar_obj = models.Rent_Car.objects.filter(pk=rid).first()

 if request.method == 'GET':
 if rid:
 rentcar_form = RentcarForm(instance=rentcar_obj)
 else:
 rentcar_form = RentcarForm(initial={'rent_time':
 datetime.datetime.now(), 'user': request.user}, instance=rentcar_obj)
 return render(request, 'edit.html', {'rentcar_form':
 rentcar_form})

 else:
 rentcar_form = RentcarForm(request.POST, instance=rentcar_obj)
 if rentcar_form.is_valid():
 print(rentcar_form.errors)
 print(rentcar_form.cleaned_data)
 rentcar_form.save()
 messages.success(request,'ok!')
 return redirect('list')
 else:
 return render(request, 'edit.html', {'rentcar_form':
 rentcar_form})
 }}}

 when post the rent_time. show the error' 'list' object has no attribute
 'strip''

 the traceback below:

 {{{
 D:\Python\lib\site-packages\django\core\handlers\exception.py in inner
 response = get_response(request) …
 ▼ Local vars
 VariableValue
 exc
 AttributeError("'list' object has no attribute 'strip'")
 get_response
 >
 request
 
 D:\Python\lib\site-packages\django\core\handlers\base.py in _get_response
 response = self.process_exception_by_middleware(e,
 request) …
 ▼ Local vars
 VariableValue
 callback
 
 callback_args
 ()
 callback_kwargs
 {}
 middleware_method
 >
 request
 
 resolver
 
 resolver_match
 ResolverMatch(func=rentcar.views.rentcar_add_edit, args=(), kwargs={},
 url_name=add, app_names=[], namespaces=[], route=rentcar/add/)
 response
 None
 self
 
 wrapped_callback
 
 D:\Python\lib\site-packages\django\core\handlers\base.py in _get_response
 response = wrapped_callback(request, *callback_args,
 **callback_kwargs) …
 ▼ Local vars
 VariableValue
 callback
 
 callback_args
 ()
 callback_kwargs
 {}
 middleware_method
 >
 request
 
 resolver
 
 resolver_match
 ResolverMatch(func=rentcar.views.rentcar_add_edit, args=(), kwargs={},
 url_name=add, app_names=[], namespaces=[], route=rentcar/add/)
 response
 None
 self
 
 wrapped_callback
 
 D:\Python\lib\site-packages\django\contrib\auth\decorators.py in
 _wrapped_view
 return view_func(request, *args, **kwargs) …
 ▼ Local vars
 VariableValue
 args
 ()
 kwargs
 {}
 login_url
 None
 redirect_field_name
 'next'
 request
 
 test_func
 . at 0x01BBE3B0A0D8>
 view_func
 
 D:\202008\carsoft\rentcar\views.py in rentcar_add_edit
 if rentcar_form.is_valid(): …
 ▼ Local vars
 VariableValue
 rentcar_form
 
 rentcar_obj
 None
 request
 
 rid
 None
 D:\Python\lib\site-packages\django\forms\forms.py in is_valid
 return self.is_bound and not self.errors …
 ▼ Local vars
 VariableValue
 self
 
 D:\Python\lib\site-packages\django\forms\forms.py in errors
 self.full_clean() …
 ▼ Local vars
 VariableValue
 self
 
 

Re: [Django] #31971: Would like a BooleanChoiceField in Forms

2020-09-01 Thread Django
#31971: Would like a BooleanChoiceField in Forms
-+-
 Reporter:  Terence Collins  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  3.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  boolean widget   | Triage Stage:
  radioselect radio BooleanField |  Unreviewed
  ChoiceField forms  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 You should use a `BooleanField` with a different widget not a
 `ChoiceField`, if you want to get data as booleans, e.g.
 {{{
 word_level_timing =
 forms.BooleanField(widget=forms.RadioSelect(choices=TIMING_LEVEL_CHOICES))
 }}}

 I don't see a reason to add a new field to Django.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.ee46ad8135f5db77e8f30c6c7dd1d336%40djangoproject.com.


Re: [Django] #31973: TypeError loading data in JSONField if DB has native JSON support

2020-09-01 Thread Django
#31973: TypeError loading data in JSONField if DB has native JSON support
-+-
 Reporter:  Adam Alton   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 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 felixxm):

 > The fields which were getting this error were originally using a custom
 `JSONField`, which was a subclass of `models.TextField`, and so presumably
 their original DB column type was `text`. I then changed them to use the
 native `models.JSONField`, and got Django to automatically create a
 migration (which contains a `migrations.AlterField` operation for each
 field, converting them to the native `models.JSONField`).
 >
 > The weird thing is that that migration converted the DB columns to type
 `json` rather than `jsonb`.

 Django have never used the `json` datatype, so it's not possible that it
 used `json` type in migrations. Can you provide more detail about this
 custom `JSONField`? Was it your own implementation or a field provided by
 3rd-party package?

 > I can fix that in my own DB, no problem. But the remaining question is
 this: is that behaviour unexpected and should we fix it?

 I cannot reproduce it (custom `JSONField(TextField)` -> `models.JSONField`
 works for me). Can you provide a small sample project that reproduces this
 issue?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.a964904bc7d1561cd507754ecde0b3d5%40djangoproject.com.


Re: [Django] #31973: TypeError loading data in JSONField if DB has native JSON support

2020-09-01 Thread Django
#31973: TypeError loading data in JSONField if DB has native JSON support
-+-
 Reporter:  Adam Alton   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 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 Adam Alton):

 Thanks for your swift reply, @felixxm. You're right, this is caused by the
 database having the fields as type `json` rather than `jsonb`, even though
 the DB schema has only ever been altered via Django's migrations.

 So (contrary to my original report) there is not a bug in `value_from_db`.

 The question now is whether there's a bug in Django's migration logic.

 The fields which were getting this error were originally using a custom
 `JSONField`, which was a subclass of `models.TextField`, and so presumably
 their original DB column type was `text`. I then changed them to use the
 native `models.JSONField`, and got Django to automatically create a
 migration (which contains a `migrations.AlterField` operation for each
 field, converting them to the native `models.JSONField`).

 The weird thing is that that migration converted the DB columns to type
 `json` rather than `jsonb`.

 I can fix that in my own DB, no problem. But the remaining question is
 this: is that behaviour unexpected and should we fix it?

 It seems unexpected to me that Django is happily creating the migration
 and applying it, but that the DB then ends up in an unusable state.
 Presumably Django should either say "I can't do that change, write your
 own migration" or it should apply the correct change.

 Happy to make a new ticket if the decision is that this is a valid bug.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.1ac442c45ddc83f8657aa1a009e9f7d1%40djangoproject.com.


Re: [Django] #31973: TypeError loading data in JSONField if DB has native JSON support

2020-09-01 Thread Django
#31973: TypeError loading data in JSONField if DB has native JSON support
-+-
 Reporter:  Adam Alton   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 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
-+-
Changes (by felixxm):

 * status:  new => closed
 * resolution:   => needsinfo
 * component:  Uncategorized => Database layer (models, ORM)
 * type:  Uncategorized => Bug


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.e35c8468d14807438d39261c65363db5%40djangoproject.com.


Re: [Django] #30032: Allow expressions to be used for default

2020-09-01 Thread Django
#30032: Allow expressions to be used for default
-+-
 Reporter:  Gavin Wahl   |Owner:  Johannes
 |  Hoppe
 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:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Johannes Hoppe):

 * needs_better_patch:  1 => 0
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.bb360f63ae7c46d9dd622199721e8572%40djangoproject.com.


Re: [Django] #31973: TypeError loading data in JSONField if DB has native JSON support

2020-09-01 Thread Django
#31973: TypeError loading data in JSONField if DB has native JSON support
---+--
 Reporter:  Adam Alton |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  3.1
 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 felixxm):

 > I will see if I can write a test to prove this (or run the existing
 tests with postgres, which has native JSON support)

 The existing tests, which cover also lists in `JSONField`s, work on
 PostgreSQL.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.96624f24d2db3ea0c38536f1bef5e8fa%40djangoproject.com.


Re: [Django] #31973: TypeError loading data in JSONField if DB has native JSON support

2020-09-01 Thread Django
#31973: TypeError loading data in JSONField if DB has native JSON support
---+--
 Reporter:  Adam Alton |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  3.1
 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 felixxm):

 Can you provide more details? Are you using a custom decoder/encoder? The
 only reason that I can imagine is that you use `json` instead of `jsonb`
 datatype in your database.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.b58a5f4d0afc954ca97269a6933f8069%40djangoproject.com.


[Django] #31973: TypeError loading data in JSONField if DB has native JSON support

2020-09-01 Thread Django
#31973: TypeError loading data in JSONField if DB has native JSON support
-+
   Reporter:  Adam Alton |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  3.1
   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  |
-+
 Following today's security release, I've upgraded from Django 3.1 to 3.1.1
 with no other code changes, and suddenly I'm getting this error when
 loading a model instance from the DB:

 {{{
 list(MyModel.objects.all())
 Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/local/lib/python3.8/site-packages/django/db/models/query.py",
 line 287, in __iter__
 self._fetch_all()
   File "/usr/local/lib/python3.8/site-packages/django/db/models/query.py",
 line 1303, in _fetch_all
 self._result_cache = list(self._iterable_class(self))
   File "/usr/local/lib/python3.8/site-packages/django/db/models/query.py",
 line 70, in __iter__
 for row in compiler.results_iter(results):
   File "/usr/local/lib/python3.8/site-
 packages/django/db/models/sql/compiler.py", line 1100, in apply_converters
 value = converter(value, expression, connection)
   File "/usr/local/lib/python3.8/site-
 packages/django/db/models/fields/json.py", line 74, in from_db_value
 return json.loads(value, cls=self.decoder)
   File "/usr/local/lib/python3.8/json/__init__.py", line 341, in loads
 raise TypeError(f'the JSON object must be str, bytes or bytearray, '
 TypeError: the JSON object must be str, bytes or bytearray, not list
 }}}

 From looking at the recent changes between 3.0 and 3.1, I'm pretty sure
 that the problem was introduced in this commit:
 
https://github.com/django/django/commit/0be51d2226fce030ac9ca840535a524f41e9832c

 Specifically, in django/db/models/fields/json.py, the removal of this from
 `from_db_value`:


 {{{
 if connection.features.has_native_json_field and self.decoder is None:
 return value
 }}}



 I'm pretty sure that this means that if the value has already been decoded
 and the DB has got native JSON support, then it continues through this
 function, attempting to decode the already-decoded data, and therefore
 gets a `TypeError`. But note that the exception catching around
 `json.loads` only catches `json.JSONDecodeError`, not `TypeError`, and
 hence it dies.

 I will see if I can write a test to prove this (or run the existing tests
 with postgres, which has native JSON support). But I'm reporting this now,
 as it seems like a fairly serious breaking change in 3.1.1. And maybe
 someone else who understands the changes in the mentioned commit can fix
 this faster than I can.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.94a77a346cb73ab24381e674a5444c28%40djangoproject.com.


Re: [Django] #31972: AuthenticationForm.UsernameField does not change field widget according to USERNAME_FIELD. (was: Django AuthenticationForm.UsernameField does not change field widget according to

2020-09-01 Thread Django
#31972: AuthenticationForm.UsernameField does not change field widget according 
to
USERNAME_FIELD.
-+-
 Reporter:  Maksudul Haque   |Owner:  Maksudul
 |  Haque
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  3.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  forms,   | Triage Stage:
  AuthenticationForm |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  assigned => closed
 * resolution:   => wontfix
 * type:  Bug => New feature
 * component:  Forms => contrib.auth


Comment:

 Yes it's intentional, this isn't worth the extra complexity.
 [https://docs.djangoproject.com/en/3.1/topics/auth/customizing/#custom-
 users-and-the-built-in-auth-forms The built-in auth forms] make several
 assumptions about the user model. You need to create a subclass of
 `AuthenticationForm` if you want to use a different widget.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.dc8dc5618ac537ec588b848a5b3e0876%40djangoproject.com.


Re: [Django] #23771: Optimisation idea for Paginator object

2020-09-01 Thread Django
#23771: Optimisation idea for Paginator object
-+-
 Reporter:  GP89 |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  paginator| Triage Stage:  Accepted
  optimization performance   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Doing this automatically and correctly is really tricky as #28477 proved
 (think of annotations spanning multi-valued relationships, `values`
 grouping by annotations before aggregation) so I'd be +1 on adding a way
 to pass `count` or `total` to `Paginator` and a way to clear annotations
 but we'd have to document that the later is not panacea.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.ad170915c3c8e36235919e9b5ab007b1%40djangoproject.com.


Re: [Django] #31972: Django AuthenticationForm.UsernameField does not change field widget according to UserModel.USERNAME_FIELD

2020-09-01 Thread Django
#31972: Django AuthenticationForm.UsernameField does not change field widget
according to UserModel.USERNAME_FIELD
-+-
 Reporter:  Maksudul Haque   |Owner:  Maksudul
 |  Haque
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  forms,   | Triage Stage:
  AuthenticationForm |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Maksudul Haque):

 * owner:  nobody => Maksudul Haque


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.4977b52a09f6f1d073eb3621d8ac0c04%40djangoproject.com.


[Django] #31972: Django AuthenticationForm.UsernameField does not change field widget according to UserModel.USERNAME_FIELD

2020-09-01 Thread Django
#31972: Django AuthenticationForm.UsernameField does not change field widget
according to UserModel.USERNAME_FIELD
-+-
   Reporter:  Maksudul   |  Owner:  nobody
  Haque  |
   Type:  Bug| Status:  assigned
  Component:  Forms  |Version:  3.1
   Severity:  Normal |   Keywords:  forms,
   Triage Stage: |  AuthenticationForm
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 First of all,
 Thank you for such an amazing Framework. You guys are doing amazing work
 on Django. really appreciate it. :)

 Today I was using {{{AuthenticationForm}}} to log users in but I use a
 custom User model and it specifies  {{{USERNAME_FIELD}}} as email.
 So, when I rendered the form {{{({{ form }})}}} I saw this:

 {{{
 
 }}}



 It was using {{{text}}} type input field Though It should render
 {{{email}}} type field.

 I don't know if it is a bug or it was intentional.

 If it is a bug I would like to submit a 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.bdcb20f3354b414b37efd16eb16790e5%40djangoproject.com.


Re: [Django] #31962: Raise a more appriopriate exception when session cannot be updated.

2020-09-01 Thread Django
#31962: Raise a more appriopriate exception when session cannot be updated.
-+-
 Reporter:  Alex Vandiver|Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.sessions |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * owner:  nobody => Hasan Ramezani
 * status:  new => assigned


Comment:

 @felixxm
 > I think we should use a new exception class

 What do you think about `SessionInterrupted` as new exception class name?

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

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


Re: [Django] #31971: Would like a BooleanChoiceField in Forms

2020-09-01 Thread Django
#31971: Would like a BooleanChoiceField in Forms
-+-
 Reporter:  Terence Collins  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  boolean widget   | Triage Stage:
  radioselect radio BooleanField |  Unreviewed
  ChoiceField forms  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Terence Collins:

Old description:

> I am using a ChoiceField with a RadioSelect to provide an input to a
> boolean field, however, the value in forms.cleaned_data comes through as
> a string.  I understand why a choice field would result in a string,
> however if I place booleans in my values I'd expect them to pass simple
> equality tests against booleans in the model.   Other users implementing
> this model will likely come up against a bug where False ≠ 'False'.   So
> I'd request a widget (BooleanChoiceField) to cover this case: often a
> simple checkbox will not provide sufficient interface guidance to a user
> on the implications of their true/false options.
>
> {{{#!python
> #in forms.py
> class TimingForm(forms.ModelForm):
>
> TIMING_LEVEL_CHOICES = ( (False, "Time Whole Lines (recommended)"),
>   (True, "Time Individual Words"), )
>
> word_level_timing = forms.ChoiceField(label='Timing Level',
> required=True, widget=forms.RadioSelect, choices=TIMING_LEVEL_CHOICES,
> initial=False)
> class Meta:
> model = TimingThingie
> fields = ['word_level_timing']
>
> #in models.py
> class TimingThingie(models.Model):
> word_level_timing = models.BooleanField(default=False)
>
> #in views.py:
> def modify_timing(request, tinstance_id):
> tinstance = TimingThingie.objects.get(id=tinstance_id)
> if tinstance.word_level_timing !=
> boolform.cleaned_data["word_level_timing"]:
> #one is False, the other is 'False', inequality is true against
> intent and likely introduces a bug
> pass
> if tinstance.word_level_timing !=
> bool(strtobool(form.cleaned_data["word_level_timing"])):
> #this works correctly, but is ugly and born only through
> suffering
> pass
>   }}}

New description:

 I am using a ChoiceField with a RadioSelect to provide an input to a
 boolean field, however, the value in forms.cleaned_data comes through as a
 string.  I understand why a choice field would result in a string, however
 if I place booleans in my values I'd expect them to pass simple equality
 tests against booleans in the model.   Other users implementing this model
 will likely come up against a bug where False ≠ 'False'.   So I'd request
 a widget (BooleanChoiceField) to cover this case: often a simple checkbox
 will not provide sufficient interface guidance to a user on the
 implications of their true/false options.

 {{{#!python
 #in forms.py
 class TimingForm(forms.ModelForm):

 TIMING_LEVEL_CHOICES = ( (False, "Time Whole Lines (recommended)"),
   (True, "Time Individual Words"), )

 word_level_timing = forms.ChoiceField(label='Timing Level',
 required=True, widget=forms.RadioSelect, choices=TIMING_LEVEL_CHOICES,
 initial=False)
 class Meta:
 model = TimingThingie
 fields = ['word_level_timing']

 #in models.py
 class TimingThingie(models.Model):
 word_level_timing = models.BooleanField(default=False)

 #in views.py:
 def modify_timing(request, tinstance_id):
 tinstance = TimingThingie.objects.get(id=tinstance_id)
 if tinstance.word_level_timing !=
 form.cleaned_data["word_level_timing"]:
 #one is False, the other is 'False', inequality is true against
 intent and likely introduces a bug
 pass
 if tinstance.word_level_timing !=
 bool(strtobool(form.cleaned_data["word_level_timing"])):
 #this works correctly, but is ugly and born only through suffering
 pass
   }}}

--

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.032c109a5f8a6d7025ae7b4c5fdaf648%40djangoproject.com.


[Django] #31971: Would like a BooleanChoiceField in Forms

2020-09-01 Thread Django
#31971: Would like a BooleanChoiceField in Forms
-+-
   Reporter: |  Owner:  nobody
  terencecollins |
   Type:  New| Status:  new
  feature|
  Component:  Forms  |Version:  3.1
   Severity:  Normal |   Keywords:  boolean widget
 |  radioselect radio BooleanField
   Triage Stage: |  ChoiceField forms
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I am using a ChoiceField with a RadioSelect to provide an input to a
 boolean field, however, the value in forms.cleaned_data comes through as a
 string.  I understand why a choice field would result in a string, however
 if I place booleans in my values I'd expect them to pass simple equality
 tests against booleans in the model.   Other users implementing this model
 will likely come up against a bug where False ≠ 'False'.   So I'd request
 a widget (BooleanChoiceField) to cover this case: often a simple checkbox
 will not provide sufficient interface guidance to a user on the
 implications of their true/false options.

 {{{#!python
 #in forms.py
 class TimingForm(forms.ModelForm):

 TIMING_LEVEL_CHOICES = ( (False, "Time Whole Lines (recommended)"),
   (True, "Time Individual Words"), )

 word_level_timing = forms.ChoiceField(label='Timing Level',
 required=True, widget=forms.RadioSelect, choices=TIMING_LEVEL_CHOICES,
 initial=False)
 class Meta:
 model = TimingThingie
 fields = ['word_level_timing']

 #in models.py
 class TimingThingie(models.Model):
 word_level_timing = models.BooleanField(default=False)

 #in views.py:
 def modify_timing(request, tinstance_id):
 tinstance = TimingThingie.objects.get(id=tinstance_id)
 if tinstance.word_level_timing !=
 boolform.cleaned_data["word_level_timing"]:
 #one is False, the other is 'False', inequality is true against
 intent and likely introduces a bug
 pass
 if tinstance.word_level_timing !=
 bool(strtobool(form.cleaned_data["word_level_timing"])):
 #this works correctly, but is ugly and born only through suffering
 pass
   }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/057.5b901e6686ae65b141f058b31941dde1%40djangoproject.com.


Re: [Django] #31970: Logging in from one browser logs me out from other browsers

2020-09-01 Thread Django
#31970: Logging in from one browser logs me out from other browsers
--+--
 Reporter:  אורי  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  3.1
 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 אורי):

 * cc: אורי (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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.d4cf22dfe17ef551eadb53db99f70c77%40djangoproject.com.


[Django] #31970: Logging in from one browser logs me out from other browsers

2020-09-01 Thread Django
#31970: Logging in from one browser logs me out from other browsers
+
   Reporter:  אורי  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.sessions  |Version:  3.1
   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 |
+
 - I upgraded Django from 3.0.6 to 3.1.1 with `DEFAULT_HASHING_ALGORITHM =
 'sha1'`.
 - I was logged in from several browsers.
 - The first time I login from a new browser with Django 3.1.1, all my
 other sessions expire, and I'm automatically logged out from all the other
 browsers.
 - This happens only once, at the first time I login with Django 3.1.1.
 - I think it's a bug, since users may use several browsers and they don't
 need to be logged out when they login from a new browser.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/054.6bd1a5bc03762572ce9c48ccb3f48c1c%40djangoproject.com.


Re: [Django] #31895: Decoding an invalid session data crashes.

2020-09-01 Thread Django
#31895: Decoding an invalid session data crashes.
-+-
 Reporter:  Matt Hegarty |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  3.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  incorrect padding,   | Triage Stage:  Accepted
  badsignature   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 This can be a duplicate of #31592 (downgrade is not supported).

 Moreover, Django 3.0 is in extended support so it doesn't receive bugfixes
 anymore (except security fixes). Therefore even if you hit a different
 (but similar) issue in Django 3.0 (without any sessions created in Django
 3.1+) it will not qualify for a backport based on our
 [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions supported versions policy].

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.f10942939826f0e629f992d67e5cf338%40djangoproject.com.


Re: [Django] #31895: Decoding an invalid session data crashes.

2020-09-01 Thread Django
#31895: Decoding an invalid session data crashes.
-+-
 Reporter:  Matt Hegarty |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  3.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  incorrect padding,   | Triage Stage:  Accepted
  badsignature   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Torsten Bronger):

 I attached the traceback we see with 3.0.8. It is not the same but very
 similar, and the point in time since we observe this also matches with
 this bug. Furthermore, the master branch solves this problem for us.

 Do you still think it is a different problem? If so, I file a new report.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.404c5e64026ae5a95440d612db5489f0%40djangoproject.com.


Re: [Django] #31895: Decoding an invalid session data crashes.

2020-09-01 Thread Django
#31895: Decoding an invalid session data crashes.
-+-
 Reporter:  Matt Hegarty |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  3.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  incorrect padding,   | Triage Stage:  Accepted
  badsignature   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Torsten Bronger):

 * Attachment "31895" added.

 Traceback with 3.0.8

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.880ec948d8c7c820b83e9863315ae5ef%40djangoproject.com.


Re: [Django] #30422: Temporary files do not get deleted on canceled upload request.

2020-09-01 Thread Django
#30422: Temporary files do not get deleted on canceled upload request.
-+-
 Reporter:  drutalj  |Owner:  Sanskar
 |  Jaiswal
 Type:  Bug  |   Status:  assigned
Component:  File |  Version:  master
  uploads/storage|
 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 felixxm):

 * needs_better_patch:  0 => 1


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

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


Re: [Django] #31961: forms.ChoiceField calls choices callback multiple times.

2020-09-01 Thread Django
#31961: forms.ChoiceField calls choices callback multiple times.
---+--
 Reporter:  Roy Smith  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  2.2
 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 Carlton Gibson):

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


Comment:

 Let's close as a duplicate of #11390.

 The `ChoiceField` docs already mention the evaluation during the form
 initialization. I've [https://github.com/django/django/pull/13376 opened a
 PR with a possible clarification].

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.a2bb0c33b387c884c4d759dd1d35ea6d%40djangoproject.com.


Re: [Django] #31895: Decoding an invalid session data crashes.

2020-09-01 Thread Django
#31895: Decoding an invalid session data crashes.
-+-
 Reporter:  Matt Hegarty |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  3.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  incorrect padding,   | Triage Stage:  Accepted
  badsignature   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Replying to [comment:11 Torsten Bronger]:
 > Django 3.0.9 is also affected, and according to the release notes,
 3.0.10 probably too.

 This is a fix for a regression in Django 3.1, so Django 3.0 cannot be
 affected.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.a759847fcd02bd09571a76966e984d3b%40djangoproject.com.


Re: [Django] #31895: Decoding an invalid session data crashes.

2020-09-01 Thread Django
#31895: Decoding an invalid session data crashes.
-+-
 Reporter:  Matt Hegarty |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  3.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  incorrect padding,   | Triage Stage:  Accepted
  badsignature   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Torsten Bronger):

 Django 3.0.9 is also affected, and according to the release notes, 3.0.10
 probably too.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.d4e56d0c90a2124f0ddd8aa21a5b6d32%40djangoproject.com.


Re: [Django] #11707: limit_choices_to on a ForeignKey can render duplicate options in formfield

2020-09-01 Thread Django
#11707: limit_choices_to on a ForeignKey can render duplicate options in 
formfield
-+-
 Reporter:  Chris.Wesseling@…|Owner:  Crowley
 |  Shaita
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  ForeingKey   | Triage Stage:  Accepted
  limit_choices_to, dceu2011 |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Crowley Shaita):

 Replying to [comment:32 felixxm]:
 > Crowley, please stop changing a triage stage without any reason.
 Sorry, I thought that's how I would get it to be reviewed.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.f1d73c51ba63554485640f31fa8b1a7c%40djangoproject.com.


Re: [Django] #31941: FileField with a callable storage does not deconstruct properly

2020-09-01 Thread Django
#31941: FileField with a callable storage does not deconstruct properly
-+-
 Reporter:  Brian Helba  |Owner:  Brian
 |  Helba
 Type:  Bug  |   Status:  assigned
Component:  File |  Version:  3.1
  uploads/storage|
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * type:  Uncategorized => Bug
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Hi Brian. Thanks for the report.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.0cddf7bd4868f3276f4550825eff3af0%40djangoproject.com.


Re: [Django] #5815: Adds per-view cache refreshing (clearing)

2020-09-01 Thread Django
#5815: Adds per-view cache refreshing (clearing)
-+
 Reporter:  k0001|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  cache refresh clear  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by Carlton Gibson):

 #31938 was a duplicate request similar functionality.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.68957e9d4ef6a0199f19dda304cf0fab%40djangoproject.com.


Re: [Django] #31938: Add a mechanism for page cache invalidation. (was: page cache invalidation)

2020-09-01 Thread Django
#31938: Add a mechanism for page cache invalidation.
-+-
 Reporter:  Laurent Tramoy   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Cache system)  |  Version:  3.1
 Severity:  Normal   |   Resolution:  duplicate
 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 Carlton Gibson):

 * status:  new => closed
 * resolution:   => duplicate
 * component:  Utilities => Core (Cache system)
 * stage:  Unreviewed => Accepted


Comment:

 Hi Laurent.

 Thanks for the report. I was going to Accept this as a new feature — I've
 spent a good amount of time rifling through cache keys to work out which
 one to delete by hand. I think this would be a good addition.

 **But** it looks to me like #5815 is the same issue, so let's close as a
 duplicate.

 Can I ask you take your idea to the DevelopersMailingList and ask for some
 input of your thoughts for an implementation? I would be good if you want
 to take this on to push it forwards! 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.27ed2f5862bfe1e4df45ba7f6ea7dc9d%40djangoproject.com.


Re: [Django] #29887: Add support for pymemcache

2020-09-01 Thread Django
#29887: Add support for pymemcache
-+-
 Reporter:  Adrian Turjak|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  pymemcache   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"cc1f2c6a199ca2318acdc59bf0731d2cdd7a4e4a" cc1f2c6a]:
 {{{
 #!CommitTicketReference repository=""
 revision="cc1f2c6a199ca2318acdc59bf0731d2cdd7a4e4a"
 Refs #29887 -- Simplified memcached client instantiation.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.15d2a1799a6cdaceaa524ba0eb9c6955%40djangoproject.com.


Re: [Django] #30422: Temporary files do not get deleted on canceled upload request.

2020-09-01 Thread Django
#30422: Temporary files do not get deleted on canceled upload request.
-+-
 Reporter:  drutalj  |Owner:  Sanskar
 |  Jaiswal
 Type:  Bug  |   Status:  assigned
Component:  File |  Version:  master
  uploads/storage|
 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 Sanskar Jaiswal):

 * needs_better_patch:  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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.ecf06baf8a25299237f7fc8163ac026f%40djangoproject.com.


Re: [Django] #31921: Python 3.7: new behavior of os.makedirs breaks FileSystemStorage permissions on intermediate directories

2020-09-01 Thread Django
#31921: Python 3.7: new behavior of os.makedirs breaks FileSystemStorage
permissions on intermediate directories
-+-
 Reporter:  WhiteSage|Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  2.2
  uploads/storage|
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  python3.7 makedirs   | Triage Stage:  Accepted
  permissions|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Fixed in 8d7271578d7b153435b40fe40236ebec43cbf1b9

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.90a49fd754a38c8e69b7bf83ac8e0010%40djangoproject.com.


Re: [Django] #31901: Content will out of screen when nav-sidebar is open

2020-09-01 Thread Django
#31901: Content will out of screen when nav-sidebar is open
-+-
 Reporter:  007  |Owner:  007
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  3.1
 Severity:  Normal   |   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:  1
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"2bc38bc7cae002f949157d95e3f0c19ea6b8ca5c" 2bc38bc7]:
 {{{
 #!CommitTicketReference repository=""
 revision="2bc38bc7cae002f949157d95e3f0c19ea6b8ca5c"
 Fixed #31901 -- Prevented content overflowing in the admin changelist with
 navigation sidebar.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.052371101abc02ec9831ad3326e951d0%40djangoproject.com.


Re: [Django] #31901: Content will out of screen when nav-sidebar is open

2020-09-01 Thread Django
#31901: Content will out of screen when nav-sidebar is open
-+-
 Reporter:  007  |Owner:  007
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  3.1
 Severity:  Normal   |   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:  1
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"dfa31f8e87b11c819d6564f925743c0978ea3351" dfa31f8e]:
 {{{
 #!CommitTicketReference repository=""
 revision="dfa31f8e87b11c819d6564f925743c0978ea3351"
 [3.1.x] Fixed #31901 -- Prevented content overflowing in the admin
 changelist with navigation sidebar.

 Backport of 2bc38bc7cae002f949157d95e3f0c19ea6b8ca5c 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.c4740dcefaf1d9819a9aa6a01a662935%40djangoproject.com.


Re: [Django] #23771: Optimisation idea for Paginator object

2020-09-01 Thread Django
#23771: Optimisation idea for Paginator object
-+-
 Reporter:  GP89 |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  paginator| Triage Stage:  Accepted
  optimization performance   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Smeaton):

 Adding my +1 to this, as it makes it extremely difficult to optimise
 readonly annotations in the admin. As an example:

 {{{

 class MyAdmin(admin.ModelAdmin):
 list_display = ("f1", "f2", "related_count")

 def related_count(self, obj):
 return obj.related_count

 def get_queryset(self, request):
 return
 super().get_queryset(request).annotate(related_count=Count("related"))

 }}}

 If QuerySet had a way to remove annotations like select_related(None) or
 order_by(), then we could implement a Paginator like so:

 {{{

 class BetterCountPaginator(Paginator):
 @cached_property
 def count(self):
 return self.object_list.annotate(None).count()

 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.9d0f6e8398e2db7fa893ab65407eebac%40djangoproject.com.


Re: [Django] #31901: Content will out of screen when nav-sidebar is open

2020-09-01 Thread Django
#31901: Content will out of screen when nav-sidebar is open
-+-
 Reporter:  007  |Owner:  007
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  3.1
 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:  1
-+-
Changes (by felixxm):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.bfba1366fa9896df42d43ea23af8b029%40djangoproject.com.