Re: [Django] #26261: QuerySet.exclude() crashes when referencing related_query_name of GenericRelation

[Django]

#26261: QuerySet.exclude() crashes when referencing related_query_name of
GenericRelation
-+-
 Reporter:  Amir Hadi|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.8
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  GenericRelation  | Triage Stage:  Accepted
  exclude|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Todor Velichkov):

 Since this is not fixed yet, a workaround would be to use Conditional
 Expressions


 {{{
 from django.db import models
 Insights.objects.annotate(
 is_a_name_eq_to_test=models.Case(
 models.When(
 a__name='Test2',
 then=models.Value(True),
 ),
 default=models.Value(False),
 output_field=models.BooleanField(),
 )
 ).filter(is_a_name_eq_to_test=False)
 }}}

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

Re: [Django] #29656: Range Fields do not support blank values via ModelForm

[Django]

#29656: Range Fields do not support blank values via ModelForm
---+--
 Reporter:  James Addison  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.11
 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 Addison):

 * Attachment "rangefield.tgz" added.

 sample project reproducing the 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 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.092e7c20bfc9c6ba36132dd6ae65c112%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29656: Range Fields do not support blank values via ModelForm

[Django]

#29656: Range Fields do not support blank values via ModelForm
-+
   Reporter:  James Addison  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Forms  |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  |
-+
 The filing of this issue is based on a discussion in IRC (see
 https://botbot.me/freenode/django/2018-08-09/?msg=103129716&page=12 and
 prior messages), followed up by creating a test project to reproduce the
 issue.

 Please do correct me if I am misusing range fields.

 

 Saving a modelform with a model's rangefield 2 inputs left empty triggers
 an DB integrity error. I think the culprit lies with `empty_values` not
 containing `['', '']` as a possible empty value. (see the code around
 https://github.com/django/django/blob/1.11.15/django/forms/fields.py#L1026)

 With a view like:

 {{{
 def home(request):
 if request.method == 'POST':
 form = RangeTestForm(request.POST)
 if form.is_valid():
 instance = form.save()
 else:
 form = RangeTestForm(request.POST)

 return render(request, 'rangefieldtest/home.html', {'form': form})
 }}}

 Form like:
 {{{
 class RangeTestForm(forms.ModelForm):
 class Meta:
 model = RangeTest
 fields = '__all__'
 }}}

 and Model like:
 {{{
 from django.contrib.postgres.fields import FloatRangeField
 from psycopg2._range import NumericRange

 class RangeTest(models.Model):
 name = models.CharField(max_length=50, blank=True, default='')
 age_range = FloatRangeField(blank=True, default=NumericRange)
 }}}

 I will attach a sample project demonstrating this (use runserver, load the
 home page, click save)


 
 psql table definition:
 {{{
   Table "public.rangefieldtest_rangetest"
   Column   | Type  |
 Modifiers
 
---+---+---
  id| integer   | not null default
 nextval('rangefieldtest_rangetest_id_seq'::regclass)
  name  | character varying(50) | not null
  age_range | numrange  | not null
 Indexes:
 "rangefieldtest_rangetest_pkey" PRIMARY KEY, btree (id)
 }}}

 data successfully stored on save (when at least one of the rangefield's 2
 inputs are filled in):
 {{{
  id | name | age_range
 +--+---
   2 |  | [3.0,)
 (1 row)
 }}}

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

Re: [Django] #21978: Add optional gunicorn support to runserver

[Django]

#21978: Add optional gunicorn support to runserver
-+-
 Reporter:  Tim Graham   |Owner:  Berker
 |  Peksag
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 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 Tom Forbes):

 It's been a while since the django-developers thread with some
 alternatives, and since then there are a few new viable options with
 Windows support which seems to be the big blocker here. I'm not sure if
 support will ever be added to Gunicorn.

 Waitress seems quite nice:
 https://docs.pylonsproject.org/projects/waitress/en/latest/

 And I've had good results with aiohttp-wsgi: https://aiohttp-
 wsgi.readthedocs.io/en/stable/wsgi.html

 `--reload` is a nice feature to have handled upstream, but their
 implementation is not particularly advanced or complicated, and may be
 harder to extend
 (https://github.com/benoitc/gunicorn/blob/master/gunicorn/reloader.py).

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

Re: [Django] #21978: Add optional gunicorn support to runserver

[Django]

#21978: Add optional gunicorn support to runserver
-+-
 Reporter:  Tim Graham   |Owner:  Berker
 |  Peksag
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 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 Tom Forbes):

 * cc: Tom Forbes (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/062.25d44b7435479422790022ecf0175e70%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28458: Add ModelMultipleChoiceField.validate_choices()

[Django]

#28458: Add ModelMultipleChoiceField.validate_choices()
---+
 Reporter:  Daniel Hahler  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Forms  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Zach Bresser):

 Replying to [comment:2 Tim Graham]:

 Tim,

 I see Blueyed is fairly silent on this. Would you mind if I picked up from
 his changes and fixed some of the things you pointed out?

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

Re: [Django] #29446: Include template context in error page when relevant

[Django]

#29446: Include template context in error page when relevant
-+
 Reporter:  Shai Berger  |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Error reporting  |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  template debug   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+

Comment (by Zach Bresser):

 Shai,

 Can you elaborate on what you mean? Are you suggesting we put the local
 context variables in a special section instead of with the rest of the
 local variables?

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

Re: [Django] #29644: String representation of SearchQuery gives inaccurate results

[Django]

#29644: String representation of SearchQuery gives inaccurate results
+--
 Reporter:  Alex Krupp  |Owner:  Tom Forbes
 Type:  Bug |   Status:  assigned
Component:  contrib.postgres|  Version:  2.0
 Severity:  Normal  |   Resolution:
 Keywords:  SearchQuery search  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Tom Forbes):

 * has_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.de8443f91c264eefdb4908515ffc57ba%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29612: Add prefetch_related() cache invalidation for GenericRelations

[Django]

#29612: Add prefetch_related() cache invalidation for GenericRelations
-+-
 Reporter:  obayemi  |Owner:  Tom
 |  Forbes
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  master
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tom Forbes):

 * has_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.40bceda6d040704a328f6201fc46b1d7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20205: PositiveIntegerfield does not handle empty values well

[Django]

#20205: PositiveIntegerfield does not handle empty values well
-+-
 Reporter:  anonymous|Owner:  Amine
 |  Zyad
 Type:  Bug  |   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
-+-

Comment (by Brenton Partridge):

 For others who might come across this error, check to make sure that you
 (and your colleagues' code) are using a forms.IntegerField and not a
 forms.CharField (or similar). forms.IntegerField, if left blank by the
 submitter, will send None to the model field, but forms.CharField will
 send an empty string which triggers OP's error.

 That said, this is a way for someone to shoot themselves in the foot, and
 the error message could be cleaner. One possible way forward would be for
 `Field.get_prep_value` to check if the field has `empty_strings_allowed =
 False`, and if so and if the value is an empty string, to throw some type
 of error with a more meaningful error message. That said, it's not
 strictly necessary, as someone will likely find this very thread from the
 current error message, and realize what the problem is.

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

Re: [Django] #29654: Truncate should use horizontal ellipsis character instead of three dots

[Django]

#29654: Truncate should use horizontal ellipsis character instead of three dots
--+
 Reporter:  Sudhanshu Mishra  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Utilities |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  string, truncator | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Vishvajit Pathak):

 Sudhanshu,
 Do you mean the expected output should be like below :

 {{{
 >>> Truncator("Hello world is not so long").chars(18)[-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.ac4d666d2833d177e13e640e4752e759%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29655: Cannot enter Django admin interface when model instances are validated on save

[Django]

#29655: Cannot enter Django admin interface when model instances are validated 
on
save
-+--
 Reporter:  Evgeny Arshinov  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  2.1
 Severity:  Normal   |   Resolution:  invalid
 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 Simon Charette):

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


Comment:

 Enabling model validation on save is likely to break a few things and
 degrade performance significantly. I don't think that's a pattern we
 should encourage or support at this point.

 Django and third-party applications simply don't expect `ValidationError`
 to be thrown on `save()`, this effectively change the signature of the
 function.

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

Re: [Django] #29637: KeyError on empty_form.fields in InlineAdminFormSet when user don't have 'add' permission for the child model

[Django]

#29637: KeyError on empty_form.fields in InlineAdminFormSet when user don't have
'add' permission for the child model
-+-
 Reporter:  Clément Mangin   |Owner:  Clément
 |  Mangin
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   Resolution:
 Keywords:  admin, permission,   | Triage Stage:  Accepted
  inline |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Clément Mangin):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/10281 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/071.68f5a478317959a044cb388046cbabac%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29637: KeyError on empty_form.fields in InlineAdminFormSet when user don't have 'add' permission for the child model

[Django]

#29637: KeyError on empty_form.fields in InlineAdminFormSet when user don't have
'add' permission for the child model
-+-
 Reporter:  Clément Mangin   |Owner:  Clément
 |  Mangin
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   Resolution:
 Keywords:  admin, permission,   | Triage Stage:  Accepted
  inline |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Clément Mangin):

 * status:  new => assigned
 * owner:  nobody => Clément Mangin


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

Re: [Django] #28575: Allow pickling dynamically created Model exception classes (DoesNotExist, MultipleObjectsReturned, RelatedObjectDoesNotExist)

[Django]

#28575: Allow pickling dynamically created Model exception classes 
(DoesNotExist,
MultipleObjectsReturned, RelatedObjectDoesNotExist)
-+-
 Reporter:  Rachel Tobin |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Frankie Dintino):

 Are there any plans to backport this patch to Django 1.11?

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

Re: [Django] #29655: Cannot enter Django admin interface when model instances are validated on save

[Django]

#29655: Cannot enter Django admin interface when model instances are validated 
on
save
-+--
 Reporter:  Evgeny Arshinov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  2.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 Evgeny Arshinov):

 As a temporary solution in our project we excluded instances of
 `django.contrib.sessions.Session` objects from validation:

 {{{
 @receiver(pre_save)
 def pre_save_handler(sender, instance, *args, **kwargs):
 if not isinstance(instance, Session):
 instance.full_clean()
 pass
 }}}

 but it certainly is an ugly workaround.

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

Re: [Django] #29655: Cannot enter Django admin interface when model instances are validated on save

[Django]

#29655: Cannot enter Django admin interface when model instances are validated 
on
save
-+--
 Reporter:  Evgeny Arshinov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  2.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 Evgeny Arshinov):

 I have committed a demo project:

 https://github.com/earshinov/django_sample/tree/issue-29655

 For reproducing:

 {{{
 git clone https://github.com/earshinov/django_sample.git
 cd django_sample
 git checkout issue-29655
 python3 -m venv venv
 . ./venv/bin/activate
 pip install -r requirements.txt
 python manage.py migrate
 python manage.py createsuperuser
 # enter credentials to your liking
 python manage.py runserver 127.0.0.1:9726
 }}}

 Next, visit http://localhost:9726/admin/, enter the credentials and click
 the [Log in] button.

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

[Django] #29655: Cannot enter Django admin interface when model instances are validated on save

[Django]

#29655: Cannot enter Django admin interface when model instances are validated 
on
save
---+
   Reporter:  Evgeny Arshinov  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Uncategorized|Version:  2.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|
---+
 Hello,

 In #29549 I was advised to enable model validation on save to properly
 validate choice fields, like this:

 {{{
 @receiver(pre_save)
 def pre_save_handler(sender, instance, *args, **kwargs):
 instance.full_clean()
 }}}

 Turned out this approach breaks Django session's middleware and, as a
 result, no one can enter Django admin interface (which uses the session
 middleware).

 Scenario:
 1. Use a project that includes Django admin interface.
 2. Enable model validation:

 {{{
 from django.db.models.signals import pre_save
 from django.dispatch import receiver

 @receiver(pre_save)
 def pre_save_handler(sender, instance, *args, **kwargs):
 instance.full_clean()
 }}}

 3. Visit Django admin interface start page (`/admin`).
 4. Enter valid credentials.

 The result is error 500 due to a `ValidationError`:

 {{{
 Internal Server Error: /admin/login/
 Traceback (most recent call last):
   File "C:\django_sample\venv\lib\site-
 packages\django\core\handlers\exception.py", line 34, in inner
 response = get_response(request)
   File "C:\django_sample\venv\lib\site-
 packages\django\utils\deprecation.py", line 93, in __call__
 response = self.process_response(request, response)
   File "C:\django_sample\venv\lib\site-
 packages\django\contrib\sessions\middleware.py", line 58, in
 process_response
 request.session.save()
   File "C:\django_sample\venv\lib\site-
 packages\django\contrib\sessions\backends\db.py", line 87, in save
 obj.save(force_insert=must_create, force_update=not must_create,
 using=using)
   File "C:\django_sample\venv\lib\site-packages\django\db\models\base.py",
 line 717, in save
 force_update=force_update, update_fields=update_fields)
   File "C:\django_sample\venv\lib\site-packages\django\db\models\base.py",
 line 742, in save_base
 update_fields=update_fields,
   File "C:\django_sample\venv\lib\site-
 packages\django\dispatch\dispatcher.py", line 175, in send
 for receiver in self._live_receivers(sender)
   File "C:\django_sample\venv\lib\site-
 packages\django\dispatch\dispatcher.py", line 175, in 
 for receiver in self._live_receivers(sender)
   File "C:\django_sample\django_sample\models.py", line 41, in
 pre_save_handler
 instance.full_clean()
   File "C:\django_sample\venv\lib\site-packages\django\db\models\base.py",
 line 1151, in full_clean
 raise ValidationError(errors)
 django.core.exceptions.ValidationError: {'session_key': ['Session with
 this Session key already exists.']}
 }}}

 We dug this problem a bit, and found out that during the login procedure
 saving a `django.contrib.sessions.Session` instance is performed twice
 with the same session key:
 - In the first case, the object is saved with `force_insert=True,
 force_update=False`
 - In the second case, the object is saved with `force_insert=False,
 force_update=True`
 - Hovewer, in both cases the object's `_state.adding` flag is `True`,
 which causes `django.db.Model._perform_unique_checks` to include the value
 of the unique field of the object being saved (in this case, a session
 key) in unique validation. Since there is already an object with the given
 session key in the database after the first save, `validate_unique`
 reports an error.

 Traceback for the first save operation (some bottom frames omitted for
 brevity):

 {{{
   ...
   File "C:\django_sample\venv\lib\site-
 packages\django\contrib\auth\views.py", line 90, in form_valid
 auth_login(self.request, form.get_user())
   File "C:\django_sample\venv\lib\site-
 packages\django\contrib\auth\__init__.py", line 108, in login
 request.session.cycle_key()
   File "C:\django_sample\venv\lib\site-
 packages\django\contrib\sessions\backends\base.py", line 298, in cycle_key
 self.create()
   File "C:\django_sample\venv\lib\site-
 packages\django\contrib\sessions\backends\db.py", line 55, in create
 self.save(must_create=True)
   File "C:\django_sample\venv\lib\site-
 packages\django\contrib\sessions\backends\db.py", line 87, in save
 obj.save(force_insert=must_create, force_update=not must_create,
 using=using)
   File "C:\django_sample\venv\lib\site-packages\django\db\models\base.py",
 line 717, in save
 force_update=force_update, update_fields=update_fields)
   File "C:\django_

Re: [Django] #29549: Document that Field.choices are enforced by model validation

[Django]

#29549: Document that Field.choices are enforced by model validation
-+-
 Reporter:  Evgeny Arshinov  |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Evgeny Arshinov:

Old description:

> This is basically a sequel of #6967.
>
> For some reason, only form validation was considered in the original
> ticket, but data validation is not limited to that, but also includes
> data integrity checks running when one calls `model_instance.save()`.
>
> As a developer, I would expect `model_instance.save()` to validate the
> `choices` field against the list of possible choices, not least because
> the list is defined at the model level, participates in db migrations
> etc., so it should take effect on modal instances.
>
> I haven't been able to find any documentation or existing bug reports
> that clearly state that
> [https://docs.djangoproject.com/en/2.0/ref/models/fields/#choices
> choices] argument only affects the corresponding model form field
> presentation and does not ensure data integrity.
>
> In summary:
> 1. I would like to know the rationale for ignoring `choices` during data
> integrity checks, in case I am missing something.
> 2. Please consider providing an option to turn data integrity check on.
> 3. If the current behavior is left intact, it should be explicitly
> documented in the official documentation.

New description:

 This is basically a sequel of #6967.

 For some reason, only form validation was considered in the original
 ticket, but data validation is not limited to that, but also includes data
 integrity checks running when one calls `model_instance.save()`.

 As a developer, I would expect `model_instance.save()` to validate the
 `choices` field against the list of possible choices, not least because
 the list is defined at the model level, participates in db migrations
 etc., so it should take effect on model instances.

 I haven't been able to find any documentation or existing bug reports that
 clearly state that
 [https://docs.djangoproject.com/en/2.0/ref/models/fields/#choices choices]
 argument only affects the corresponding model form field presentation and
 does not ensure data integrity.

 In summary:
 1. I would like to know the rationale for ignoring `choices` during data
 integrity checks, in case I am missing something.
 2. Please consider providing an option to turn data integrity check on.
 3. If the current behavior is left intact, it should be explicitly
 documented in the official documentation.

--

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

Re: [Django] #29654: Truncate should use horizontal ellipsis character instead of three dots

[Django]

#29654: Truncate should use horizontal ellipsis character instead of three dots
--+
 Reporter:  Sudhanshu Mishra  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Utilities |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  string, truncator | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Claude Paroz):

 But there are many more occurrences in the Django source code and
 comments. We should be consistent. Does this need a discussion?

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

Re: [Django] #29654: Truncate should use horizontal ellipsis character instead of three dots

[Django]

#29654: Truncate should use horizontal ellipsis character instead of three dots
--+
 Reporter:  Sudhanshu Mishra  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Utilities |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  string, truncator | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Claude Paroz):

 * needs_better_patch:  0 => 1
 * ui_ux:  1 => 0
 * component:  Template system => Utilities
 * version:  2.1 => master
 * stage:  Unreviewed => Accepted


Comment:

 I'd be in favour of this change.

 [https://github.com/django/django/pull/10280 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.be5c1ea46125110b224ac717ee409551%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29654: Truncate should use horizontal ellipsis character instead of three dots

[Django]

#29654: Truncate should use horizontal ellipsis character instead of three dots
-+-
 Reporter:  Sudhanshu Mishra |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  string, truncator| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Sudhanshu Mishra):

 * has_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.b28e1a9cb1c64878617418d984bc4d67%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29654: Truncate should use horizontal ellipsis character instead of three dots

[Django]

#29654: Truncate should use horizontal ellipsis character instead of three dots
-+-
   Reporter:  Sudhanshu  |  Owner:  nobody
  Mishra |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Template   |Version:  2.1
  system |
   Severity:  Normal |   Keywords:  string, truncator
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  1  |
-+-
 In the following example the value returns a string which has a length of
 18 and including 3 dots.


 {{{
 >>> from django.utils.text import Truncator
 >>> Truncator("Hello world is not so long").chars(18)
 'Hello world is ...'
 >>> Truncator("Hello world is not so long").chars(18)[-1]
 '.'

 }}}

 IMHO, the `Truncator` should use `...` (ellipsis) character instead.

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

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

Re: [Django] #29647: "Please correct the error below." when saving edit model form with inline formset and space at the end of primary key value

[Django]

#29647: "Please correct the error below." when saving edit model form with 
inline
formset and space at the end of primary key value
---+--
 Reporter:  Alex Uralov|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:  invalid
 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 Alex Uralov):

 Thank you for the advice!

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