Re: [Django] #33008: Document prefetch_related for GenericForeignKey - Object doesn't exist behaviour

[Django]

#33008: Document prefetch_related for GenericForeignKey - Object doesn't exist
behaviour
--+
 Reporter:  Martin Svoboda|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.contenttypes  |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  Documentation | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Simon Charette):

 Thanks for trying it out.

 There must be a way to avoid this assignment overriding somehow as this
 analogous situation doesn't result in attribute loss

 {{{#!python
 class UserRef(models.Model):
 user = models.ForeignKey(User, models.DO_NOTHING, null=True,
 db_constraint=False)

 UserRef.objects.create(user_id=42)
 ref = UserRef.objects.prefetch_related('user')[0]
 assert ref.user is None
 assert ref.user_id == 42
 }}}

 The distinction between the two is due to
 
[https://github.com/django/django/blob/3a6431db5461b88e691d770abdba6a2793ef699d/django/db/models/query.py#L1933-L1941
 this branch] where `GenericForeignKey.get_prefetch_queryset` sets
 `is_descriptor` to `True`.

 I haven't tried it out but I suspect that switching `is_descriptor` to
 `False`
 
[https://github.com/django/django/blob/3a6431db5461b88e691d770abdba6a2793ef699d/django/contrib/contenttypes/fields.py#L216
 instead] now that `GenericForeignKey` has been changed to use the fields
 cache (bfb746f983aa741afa3709794e70f1e0ab6040b5) would address your issue
 and unify behaviours.

-- 
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.0382e9c645735ad98d6e6945fdf8bde0%40djangoproject.com.

Re: [Django] #32800: CsrfViewMiddleware unnecessarily masks CSRF cookie

[Django]

#32800: CsrfViewMiddleware unnecessarily masks CSRF cookie
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  CSRF |  Version:  dev
 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 Chris Jerdonek):

 * has_patch:  0 => 1


Comment:

 PR: https://github.com/django/django/pull/14761

-- 
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.5a79697b57d18bc58e56c99ead6d97c3%40djangoproject.com.

Re: [Django] #33008: Document prefetch_related for GenericForeignKey - Object doesn't exist behaviour

[Django]

#33008: Document prefetch_related for GenericForeignKey - Object doesn't exist
behaviour
--+
 Reporter:  Martin Svoboda|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.contenttypes  |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  Documentation | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Martin Svoboda):

 Thank you, you are right, assignment  {{{ tags_2[0].content_object = None
 }}} also set object_id and content_type_id is to None. However I am not
 sure if "modification" of a source object is the correct behaviour for
 prefetch_related.


 Replying to [comment:3 Simon Charette]:
 > I didn't look at the issue in detail but I assume this is happening due
 to the prefetching logic performing a `tags_2[0].content_object = None`
 assignment.
 >
 > How does the following code behaves?
 >
 > {{{#!python
 > tags_1 = TaggedItem.objects.filter(tag='test')
 > tags_1.content_object = None
 > assert tags_1.object_id is None
 > assert tags_1.content_type_id is None
 > }}}

-- 
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.827755afb4a4558b3d6bd26c2aba873e%40djangoproject.com.

Re: [Django] #33001: ManifestStaticFilesStorage is problematic - need changes here

[Django]

#33001: ManifestStaticFilesStorage is problematic - need changes here
-+-
 Reporter:  Man Python   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  File |  Version:  3.2
  uploads/storage|
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  Static   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Man Python):

 Replying to [comment:3 Mariusz Felisiak]:
 > I appreciate you'd like to reopen the ticket, but please
 [https://docs.djangoproject.com/en/stable/internals/contributing/triaging-
 tickets/#closing-tickets follow the triaging guidelines with regards to
 wontfix tickets] and take this to DevelopersMailingList.
 >
 > > The collecstatic sucsks.. it's not copying this same from site-
 packages\django\contrib\admin\static\
 >
 > Please may I also refer you to the
 [https://www.djangoproject.com/conduct/ code of conduct] for your
 consideration.

 Thats why any efforts not going to report details or support DJango with
 idea to work by own.

-- 
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.d73c4ef21869b57570b1daee56350796%40djangoproject.com.

Re: [Django] #33001: ManifestStaticFilesStorage is problematic - need changes here

[Django]

#33001: ManifestStaticFilesStorage is problematic - need changes here
-+-
 Reporter:  Man Python   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  File |  Version:  3.2
  uploads/storage|
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  Static   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Man Python):

 Also python manage.py runserver --statichash can be ok

-- 
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.ff0ad7f65336f74900d97e3dff0cb238%40djangoproject.com.

Re: [Django] #33001: ManifestStaticFilesStorage is problematic - need changes here

[Django]

#33001: ManifestStaticFilesStorage is problematic - need changes here
-+-
 Reporter:  Man Python   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  File |  Version:  3.2
  uploads/storage|
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  Static   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 I appreciate you'd like to reopen the ticket, but please
 [https://docs.djangoproject.com/en/stable/internals/contributing/triaging-
 tickets/#closing-tickets follow the triaging guidelines with regards to
 wontfix tickets] and take this to DevelopersMailingList.

 > The collecstatic sucsks.. it's not copying this same from site-
 packages\django\contrib\admin\static\

 Please may I also refer you to the [https://www.djangoproject.com/conduct/
 code of conduct] for your consideration.

-- 
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.a49b3f4ee005cdd28bba6a5f5c5c180b%40djangoproject.com.

Re: [Django] #33001: ManifestStaticFilesStorage is problematic - need changes here

[Django]

#33001: ManifestStaticFilesStorage is problematic - need changes here
-+-
 Reporter:  Man Python   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  File |  Version:  3.2
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:  Static   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Man Python):

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


Comment:

 Replying to [comment:1 Carlton Gibson]:
 > Hi. This behaviour has been unchanged since
 [https://docs.djangoproject.com/en/3.2/releases/1.7/#django-contrib-
 staticfiles ManifestStaticFilesStorage was introduced in Django 1.7].
 You're welcome to make whatever adjustments you need in a subclass (or
 configure your webserver to route `styles.css?` requests to the
 right file) but it's not something we can just change.
 >
 Well.. I think it should be changed as default with this settings to has
 static files due many problems around cache on servers and enviroment in
 case user can not recognize in first the problem around cache (not onlt
 CDN, etc. but dedicated solutions in panels for apache ngnix wsgi, pushion
 passenger).

 > You say "problematic" but don't explain that at all. Likely it's your
 set up but if you can narrow down a specific issue in Django we're happy
 to have a look.
 > Thanks

 There is many issues.. but I tired to report all.
 Eg.


 {{{
 ?: (staticfiles.E002) The STATICFILES_DIRS setting should not contain the
 STATIC_ROOT setting.
 }}}


 {{{
 STATIC_URL = '/static/'
 STATICFILES_DIRS = [
 os.path.join(BASE_DIR, "public/static")
 ]
 STATIC_ROOT = os.path.join(BASE_DIR, 'public/', 'static/')
 STATIC_DIR = os.path.join(BASE_DIR, 'public/', 'static/')
 MEDIA_ROOT = os.path.join(BASE_DIR, 'public/', 'media/')
 }}}
 Users on boards like stack suggesting to delete/comment - I still not
 understand the reason for this "separation".


 {{{
 STATICFILES_DIRS = [
 os.path.join(BASE_DIR, "public/static")
 ]
 }}}
 https://stackoverflow.com/questions/27213752/collecting-staticfiles-
 throws-improperlyconfigured
 Then sure.. working, but not the overided templates and css
 {{{
 STATIC_URL = '/static/'
 STATIC_ROOT = os.path.join(BASE_DIR, 'public/', 'static/')
 STATIC_DIR = os.path.join(BASE_DIR, 'public/', 'static/')
 MEDIA_ROOT = os.path.join(BASE_DIR, 'public/', 'media/')
 }}}
 Many aps need the STATICFILES_DIRS from INSTALLED_APPS and if not exist,
 then django not starting

 Then user starting combine with rename dirs, move dirs, and caching
 canchges.. the .pyc often not include changes in settings.py this doing
 problems (sure.. advanced user know about problem, but anyway something
 can be complicated and not included in right way - fast refresh server
 overloaded, this same on dev/debug in local what I meet [eg. debugpy
 lags]).
 Hash refresh for static can help to see current stage/session in relation
 to code change (eg. ?unixtime).

 Finally I have 2 dirs public and public2


 {{{
 STATIC_URL = '/static/'
 STATICFILES_DIRS = [
 os.path.join(BASE_DIR, "./public2/static")
 ]
 STATIC_ROOT = os.path.join(BASE_DIR, 'public/', 'static/')
 STATIC_DIR = os.path.join(BASE_DIR, 'public/', 'static/')
 MEDIA_ROOT = os.path.join(BASE_DIR, 'public/', 'media/')
 }}}

 This is not end..

 The collecstatic sucsks..  it's not copying this same from  site-
 packages\django\contrib\admin\static\
 https://docs.djangoproject.com/en/3.2/ref/contrib/staticfiles/
 Then overiding not working! Coz .css for overiding is differnt from  site-
 packages\django\contrib\admin\static\admin\css\base.css
 Eg. original is:

 {{{
 /*
 DJANGO Admin styles
 */

 @import url(fonts.css);

 /* VARIABLE DEFINITIONS */
 :root {
   --primary: #79aec8;
   --secondary: #417690;
   --accent: #f5dd5d;
   --primary-fg: #fff;

   --body-fg: #333;
   --body-bg: #fff;
   --body-quiet-color: #666;
   --body-loud-color: #000;
 }}}

 Copied

 {{{
 /*
 DJANGO Admin styles
 */

 @import url(fonts.css);

 body {
 margin: 0;
 padding: 0;
 font-size: 14px;
 font-family: "Roboto","Lucida Grande","DejaVu Sans","Bitstream Vera
 Sans",Verdana,Arial,sans-serif;
 color: #333;
 background: #fff;
 }

 }}}

 Who can discover the detail? It's impossible if dev is not advanced.
 Problematic, coz no logs around templates/loaders around with overriding
 or any of around.

 What user doing next.. trying with .html similary.. creating "template"
 dirs in
 

Re: [Django] #33011: my_model.manyrelation_set.all() return empty value

[Django]

#33011: my_model.manyrelation_set.all() return empty value
-+-
 Reporter:  Floréal Cabanettes   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  model set querying   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Hi, could you please provide minimal models and code to reproduce the
 issue? Ideally, you could also
 [https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
 tickets/#bisecting-a-regression bisect] to find the commit where the
 behavior changed.

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

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

[Django] #33011: my_model.manyrelation_set.all() return empty value

[Django]

#33011: my_model.manyrelation_set.all() return empty value
-+-
   Reporter:  Floréal|  Owner:  nobody
  Cabanettes |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  model set querying
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I have a problem which occurred since django 3.2 (no problem with django
 3.1).

 I use django rest framework. On the view, I have a model "Run" and a model
 "Experiment". On the view, I get experiments with :
 my_experiments = my_run.experiment_set.all()

 But since django 3.2, this returns an empty queryset. If I add a
 breakpoint in pycharm just after this line, the queryset is no more empty.

 Also, this line works perferctly:
 my_experiments = Experiment.objects.filter(run_id=my_run.id)

 But I think the first code is more beautiful... so why this problem?

-- 
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/053.ef6b28efa91decb23e8ffabd94687b69%40djangoproject.com.

Re: [Django] #33010: id to uuid type casting bug in Django 2.2

[Django]

#33010: id to uuid type casting bug in Django 2.2
-+-
 Reporter:  Stygmate |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for the report, it was fixed in
 325d5d64452118d89624d8b4c8679f0d2cb3d6d6 (see #30477). Unfortunately, the
 issue has been present since the feature was introduced. Per our
 backporting policy this means it doesn't qualify for a backport to 2.2.x.
 See https://docs.djangoproject.com/en/stable/internals/release-process/
 for more details. Moreover Django 2.2 is in extended support so it doesn't
 receive bugfixes anymore (except security patches).

-- 
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.fe34bc2cbe931e3267e4b3a37d849a56%40djangoproject.com.

Re: [Django] #33008: Document prefetch_related for GenericForeignKey - Object doesn't exist behaviour

[Django]

#33008: Document prefetch_related for GenericForeignKey - Object doesn't exist
behaviour
--+
 Reporter:  Martin Svoboda|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.contenttypes  |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  Documentation | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Simon Charette):

 I didn't look at the issue in detail but I assume this is happening due to
 the prefetching logic performing a `tags_2[0].content_object = None`
 assignment.

 How does the following code behaves?

 {{{#!python
 tags_1 = TaggedItem.objects.filter(tag='test')
 tags_1.content_object = None
 assert tags_1.object_id is None
 assert tags_1.content_type_id is None
 }}}

-- 
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.52b0e17ba5c4ebe9d735a0fe3118afd1%40djangoproject.com.

[Django] #33010: id to uuid type casting bug in Django 2.2

[Django]

#33010: id to uuid type casting bug in Django 2.2
-+-
   Reporter:  Stygmate   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 in some case Django try to convert simple incremental integer id to UUID.

 this problem was encountered while trying django-computedfields lib.
 here is the test project, initialy created to check if the bug come from
 django-computedfields: https://github.com/stygmate/dcftest
 (check the models.py in dcfapp)
 when doing:
 ModelA.objects.filter(modelb=some_modelb_instance)
 the SQL query generated is casting id to uuid resulting in
 -.-0001 and in a query error.

 Things seems to work well with django 3.2, can someone backport the
 correction to django 2.2 ?

-- 
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.abd1112bbaf3ec0aa1c9acd12a5d51ff%40djangoproject.com.

Re: [Django] #26142: Provide a way for model formsets to disallow new object creation

[Django]

#26142: Provide a way for model formsets to disallow new object creation
-+
 Reporter:  Tim Graham   |Owner:  Vlad
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by Jacob Walls):

 * needs_tests:  0 => 1


Comment:

 Patch still lacks a regression test that fails on main (upon removing the
 keyword introduced by the PR). Luckily, there is one we can use in the
 previous PR. Vlad, can you update your patch with additional tests from
 the previous 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/067.3b718b4906473e6b7a3849d7c5e42201%40djangoproject.com.

Re: [Django] #29205: MultiValueField ignores a required value of a sub field

[Django]

#29205: MultiValueField ignores a required value of a sub field
-+-
 Reporter:  Takayuki Hirai   |Owner:  Jacob
 |  Walls
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.11
 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:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"3a6431db5461b88e691d770abdba6a2793ef699d" 3a6431db]:
 {{{
 #!CommitTicketReference repository=""
 revision="3a6431db5461b88e691d770abdba6a2793ef699d"
 Refs #29205 -- Added MultiValueField test for rendering of optional
 subfields.
 }}}

-- 
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.3089327dab8b2ef80590e91bc0f25887%40djangoproject.com.

Re: [Django] #32997: Errors in 404 templates are hard to debug

[Django]

#32997: Errors in 404 templates are hard to debug
-+--
 Reporter:  jooadam  |Owner:  (none)
 Type:  Bug  |   Status:  closed
Component:  Error reporting  |  Version:  3.2
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Carlton Gibson):

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


Comment:

 Hi. Thanks for the extra info.

 > I have a custom 404.html template...

 So custom error templates should (in general) be entirely straight-
 forward, in order to be certain not to raise an error themselves.
 (Adding complexity to the default error handlers here isn't something we
 want to get into.)

 In your case, where you want a more complex template, it's incumbent upon
 you to also
 [https://docs.djangoproject.com/en/3.2/topics/http/views/#s-id1 customise
 the error views] to ensure any possible exceptions are appropriately dealt
 with.

 Minimally, you could add logging if you introduce the possibility of an
 exception:


 {{{
 import logging

 from django.views.defaults import page_not_found


 logger = logging.getLogger(__name__)


 def custom_page_not_found(request, exception, template_name='404.html'):
 try:
 page_not_found(request, exception, template_name)
 except:
 logger.exception("ERROR OCCURRED")
 raise


 handler404 = 'foo.urls.custom_page_not_found'
 }}}

 Your traceback is then available.

 See also the [https://docs.djangoproject.com/en/3.2/topics/http/views
 /#testing-custom-error-views Testing custom error views] section, that
 will enable you to make sure your error handling works before putting it
 live.

-- 
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.6dbd588f1174311125479ed291296c89%40djangoproject.com.

Re: [Django] #33008: Document prefetch_related for GenericForeignKey - Object doesn't exist behaviour (was: prefetch_related for GenericForeignKey - Object doesn't exist behaviour)

[Django]

#33008: Document prefetch_related for GenericForeignKey - Object doesn't exist
behaviour
--+
 Reporter:  Martin Svoboda|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.contenttypes  |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  Documentation | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

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

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

Re: [Django] #33008: prefetch_related for GenericForeignKey - Object doesn't exist behaviour

[Django]

#33008: prefetch_related for GenericForeignKey - Object doesn't exist behaviour
--+
 Reporter:  Martin Svoboda|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.contenttypes  |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  Documentation | 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):

 * cc: Simon Charette, Mariusz Felisiak (added)
 * keywords:   => Documentation
 * type:  Uncategorized => Cleanup/optimization
 * component:  Database layer (models, ORM) => contrib.contenttypes
 * stage:  Unreviewed => Accepted


Comment:

 Hi Martin. I do agree that's a little surprising. I'll accept as a
 Documentation issue on the content types app, but I'll cc Simon and
 Mariusz, in case they want to take it as a bug. Thanks.

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

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

Re: [Django] #32999: Admin Tabular Stacked Inline widget headings are not aligned headings

[Django]

#32999: Admin Tabular Stacked Inline widget headings are not aligned headings
-+-
 Reporter:  Michael  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  contrib.admin|  Version:  3.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  tabularinline css| Triage Stage:
  style styling  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi Michael. Thanks for the report.

 Just to clarify, there are **two** controls in play here:

 [[Image(https://code.djangoproject.com/raw-
 attachment/ticket/32999/Screenshot%202021-08-10%20at%2008.49.16.png)]]

 The "Delete?" header corresponds to the checkbox input that controls
 whether the existing inline instance should be deleted.

 The "X" marks are JavaScript powered, and allow deleting the initially
 empty "extra" inlines.

 Those **shouldn't** line up.

 In your "wider" example, they are being squashed together for lack of
 space, but I wonder if/what we'd be able to do about that… 樂

 In your screenshots the checkboxes for delete are not showing — how
 exactly is that coming up? Do you have `can_delete=False` set, or are
 there restricted permissions in play? (etc)
 It may be that we could optimise to not show the Delete? header at all in
 this case.
 Can I ask you to provide a fuller example (perhaps a sample project?)
 recreating this?

 Thanks again!

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

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

Re: [Django] #32993: Refactor AutocompleteJsonView to support extra fields in autocomplete response

[Django]

#32993: Refactor AutocompleteJsonView to support extra fields in autocomplete
response
-+-
 Reporter:  mrts |Owner:  mrts
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  dev
 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:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"9b1158a7e0784686bbe5118a88d4804b99fa4fe1" 9b1158a7]:
 {{{
 #!CommitTicketReference repository=""
 revision="9b1158a7e0784686bbe5118a88d4804b99fa4fe1"
 Fixed #32993 -- Added AutocompleteJsonView.serialize_result() to allow
 customization.
 }}}

-- 
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.0eb6558816f2f3441cc0faca09078006%40djangoproject.com.

Re: [Django] #32999: Admin Tabular Stacked Inline widget headings are not aligned headings

[Django]

#32999: Admin Tabular Stacked Inline widget headings are not aligned headings
-+-
 Reporter:  Michael  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  contrib.admin|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  tabularinline css| Triage Stage:
  style styling  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * Attachment "Screenshot 2021-08-10 at 08.49.16.png" added.

 Screenshot from admin showing Delete input and remove "extra" inline
 controls.

-- 
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.64195771edc5c98d101c2e2732c22b16%40djangoproject.com.

Re: [Django] #33001: ManifestStaticFilesStorage is problematic - need changes here

[Django]

#33001: ManifestStaticFilesStorage is problematic - need changes here
-+-
 Reporter:  Man Python   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  File |  Version:  3.2
  uploads/storage|
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  Static   | 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:   => wontfix


Comment:

 Hi. This behaviour has been unchanged since
 [https://docs.djangoproject.com/en/3.2/releases/1.7/#django-contrib-
 staticfiles ManifestStaticFilesStorage was introduced in Django 1.7].
 You're welcome to make whatever adjustments you need in a subclass (or
 configure your webserver to route `styles.css?` requests to the
 right file) but it's not something we can just change.

 You say "problematic" but don't explain that at all. Likely it's your set
 up but if you can narrow down a specific issue in Django we're happy to
 have a look.
 Thanks

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

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

Re: [Django] #33007: `form_clean()` performance

[Django]

#33007: `form_clean()` performance
--+
 Reporter:  David Smith   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by David Smith):

 Replying to [comment:5 Carlton Gibson]:
 > But I guess details can be discussed on the django-bench repo…

 I ''finally'' got round to finishing my thoughts on benchmarking more
 generally. [https://github.com/django/djangobench/issues/38 see post].

-- 
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.9ac2aef2562a37dc67e6b543a53bc13e%40djangoproject.com.