Re: InlineAdmin unable to delete object with read only primary key

2022-11-21 Thread David Sanders 
Hi Gagan,

Interesting quirk you've found there, it's possible it could be a bug
though further digging may be required.

A couple of interesting notes I found while fiddling with your example code:

   - If you press "Save and continue editing" there are unspecified form
   errors
   - Setting `editable=False` on the token key fixes these unspecified
   errors and also allows you to delete the token
   - Note that while inline works with `editable=False` it also means that
   you can't create a disabled token because of the nature of how checkboxes
   are handled. This is a separate issue.


David

On Tue, 22 Nov 2022 at 04:42, Gagan Deep 
wrote:

> Hello everyone!
>
> In my project, I have created a model (Token) which uses a custom primary
> key (i.e. it uses a field defined by the model for the primary key instead
> of using "id"). I created an InlineAdmin class for this model and added the
> primary key field to InlineAdmin.readonly_fields. This InlineAdmin is added
> to ModelAdmin.inlines of another model.
>
> After making these changes, it is *not possible* to delete a Token object
> from the InlineAdmin (web interface). After selecting the delete checkbox
> for the Token object and clicking on the "Save and continue" button (of
> ModelAdmin), the page reloads with the Token object still there.
>
> I have created a simple Demo project to replicate this issue,
> https://github.com/pandafy/inline_admin_pk_bug.
>
> I have done some initial debugging, and found that when the primary key is
> added to the InlineAdmin.readonly_fields, an HTML input element for that
> field is not created.
>
> This does not occur when a model has "id" field for the primary key and
> the "id" field is added to InlineAdmin.readonly_fields.
>
> [image: Screenshot from 2022-11-21 23-05-22.png]
>
> I believe this is inconsistent behaviour. I will be more than happy to
> open an issue for this on Trac and work on a potential fix if this is a
> bug.
>
> Regards,
> Gagan Deep
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/85d9b570-d3dc-46ca-8976-8ffcff061c01n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADyZw-7OguU6p%2BdSFrRKX_uOOLPpiFSbhPQEvaqnaAQROfoV3Q%40mail.gmail.com.

Re: Set a reasonable default for EMAIL_TIMEOUT

2022-11-21 Thread Federico Capoano 
Hi there,

yes I can add EMAIL_TIMEOUT in my applications and I am already doing that.

The reason I wanted to bring this up here is that I care about Django.
This behavior goes against a well known concept of the Unix Philosophy 
which is to  "Write programs which fail in a way that is easy to diagnose".

I believe we can all agree that any potentially long running operation 
should have a default timeout after which the operation fails and a trace 
is left on a log somewhere for the system administrators to find
I can't see the benefit in not failing, not leaving log traces and keeping 
an app blocked indefinitely.

What are the benefits vs the downsides of such a change?

Benefit: any issue in production systems will be quickly understood and 
dealt with.
Downsides? Backward compatibility? Systems relying on the default timeout 
being set elsewhere? Anything else?

Even if we allow configuring different email backends, I am still 
wonderfing: why do we think it's good to have an email sending operation 
which can potentially stall indefinitely?

Best regards
Federico
On Friday, November 18, 2022 at 11:28:14 AM UTC-3 Michiel Beijen wrote:

> Hi Mariusz,
>
> > Op 17 nov. 2022, om 18:18 heeft Mariusz Felisiak  
> het volgende geschreven:
> > 
> > "Why is there no default for EMAIL_TIMEOUT?"
> > The Django's SMTP backend is a wrapper around smtplib.SMTP/SMTP_SSL and 
> we only pass the "timeout" parameter to the smtplib API, so I'd first ask 
> why there is no default value for a timeout parameter in smtplib.
>
> Well, Django’s docs say:
>
> > If unspecified, the default timeout will be the one provided by 
> socket.getdefaulttimeout(), which defaults to None(no timeout).
> (ref https://docs.djangoproject.com/en/4.1/topics/email/#smtp-backend)
>
> So if you say: why is there no default value in smtplib, the smtplib 
> maintainer can so go one level up and ask why there is no default timeout 
> for `socket` :D
>
> Nevertheless, I would argue that having a timeout in django, set to a 
> rather conservative value such as 60 seconds, is much better than having no 
> timeout at all; especially because what the OP posted:
>
> > so at least if and when this happens, developers will find error traces 
> in the logs and quickly understand where the problem is coming from, 
> instead of spending hours to debug it like I did in the past week.
>
> In the typical scenario, people are much better off with specified 
> timeouts than with a timeout of None
>
> —
> Michiel
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8ae42cd2-6c6c-47cb-8f56-7f0f46424df6n%40googlegroups.com.

InlineAdmin unable to delete object with read only primary key

2022-11-21 Thread Gagan Deep 


Hello everyone! 

In my project, I have created a model (Token) which uses a custom primary 
key (i.e. it uses a field defined by the model for the primary key instead 
of using "id"). I created an InlineAdmin class for this model and added the 
primary key field to InlineAdmin.readonly_fields. This InlineAdmin is added 
to ModelAdmin.inlines of another model.

After making these changes, it is *not possible* to delete a Token object 
from the InlineAdmin (web interface). After selecting the delete checkbox 
for the Token object and clicking on the "Save and continue" button (of 
ModelAdmin), the page reloads with the Token object still there. 

I have created a simple Demo project to replicate this issue,  
https://github.com/pandafy/inline_admin_pk_bug.  

I have done some initial debugging, and found that when the primary key is 
added to the InlineAdmin.readonly_fields, an HTML input element for that 
field is not created. 

This does not occur when a model has "id" field for the primary key and the 
"id" field is added to InlineAdmin.readonly_fields. 

[image: Screenshot from 2022-11-21 23-05-22.png]

I believe this is inconsistent behaviour. I will be more than happy to open 
an issue for this on Trac and work on a potential fix if this is a bug. 

Regards, 
Gagan Deep 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/85d9b570-d3dc-46ca-8976-8ffcff061c01n%40googlegroups.com.

Re: Fellow Reports - November 2022

2022-11-21 Thread Mariusz Felisiak 
Week ending November 20, 2022 

*Triaged: *
   https://code.djangoproject.com/ticket/34152 - Add the ability to store 
logs in a table (wontfix) 
   https://code.djangoproject.com/ticket/34155 - 
ModelAdmin.render_change_form does not lowercase the app_label when setting 
template directories (needsinfo) 
   https://code.djangoproject.com/ticket/34156 - TypedChoiceField not 
compatible with IntegerChoices (invalid) 
   https://code.djangoproject.com/ticket/34158 - Optimise count() for 
querysets that contain field lookups (invalid) 
   https://code.djangoproject.com/ticket/34161 - Wrong Name in Django 
Relationship (invalid) 
   https://code.djangoproject.com/ticket/34160 - Django 4.1 Expression 
contains mixed types for (Big/Small)IntegerFields. (accepted) 
   https://code.djangoproject.com/ticket/34163 - ImproperlyConfigured: 
Requested setting INSTALLED_APPS, but settings are not configured (invalid) 
   https://code.djangoproject.com/ticket/34164 - django-graphql-auth 0.3.16 
&& django-mongoengine 0.5.4 dont work with django-4.1.3 (invalid) 
   https://code.djangoproject.com/ticket/34162 - Wrong URL generated by 
get_admin_url in admin index "Recent Actions" panel in custom Django Admin 
Site (duplicate) 
   https://code.djangoproject.com/ticket/34165 - migrate management command 
does not respect database parameter when adding Permissions. (accepted) 
   https://code.djangoproject.com/ticket/34166 - UniqueConstraint with 
condition not validated if the condition field is not editable. (wontfix) 
   https://code.djangoproject.com/ticket/34167 - Set a reasonable default 
for EMAIL_TIMEOUT (wontfix) 
   https://code.djangoproject.com/ticket/34168 - Add support for list of 
parameters to the QuerySet.raw(). (wontfix) 
   https://code.djangoproject.com/ticket/34169 - Regex bug in 
EmailValidator class allows top domain label of an email address's 
domain_part to start with a hyphen (duplicate) 

*Reviewed/committed: *
   https://github.com/django/django/pull/16295 - Fixed #34154 -- Made mixin 
headers consistent in auth docs. 
   https://github.com/django/django/pull/16291 - Refs #28477 -- Fixed 
handling aliased annotations on aggregation. 
   https://github.com/django/django/pull/16293 - Refs #25307 -- Replaced 
SQLQuery.rewrite_cols() by replace_expressions(). 
   https://github.com/django/django/pull/16163 - Fixed #34074 -- Added 
headers argument to RequestFactory and Client classes. 
   https://github.com/django/django/pull/16186 - Fixed #34099 -- Added 
release notes for QuerySet.update_or_create() changes. 
   https://github.com/django/django/pull/16296 - Fixed #34123 -- Fixed 
combinator order by alias when using select_related(). 
   https://github.com/django/django/pull/16297 - Refs #33308 -- Used 
get_db_prep_value() to adapt JSONFields. 
   https://github.com/django/django/pull/16281 - Fixed #28987 -- Fixed 
altering ManyToManyField when changing to self-referential. 
   https://github.com/django/django/pull/16303 - Fixed #26056 -- Added 
QuerySet.values()/values_list() support for ArrayField's __overlap lookup. 
   https://github.com/django/django/pull/16306 - Fixed #34148 -- Reverted 
"Fixed #32901 -- Optimized BaseForm.__getitem__()." 
   https://github.com/django/django/pull/16305 - Fixed #26261 -- Fixed 
queryset crash when excluding reverse GenericRelation. 
   https://github.com/django/django/pull/16229 - Fixed #34119 -- Prevented 
callable default hidden widget value from being overridden. 

*Authored: *
   https://github.com/django/django/pull/16298 - Refs #34118 -- Skipped not 
compatible requirements on daily builds for Python 3.12. 
   https://github.com/django/django/pull/16299 - Refs #34118 -- Used 
smtplib's context parameter instead of keyfile and certfile. 
   https://github.com/django/django/pull/16308 - Removed unnecessary 
ForeignKey.get_reverse_path_info().

Best,
Mariusz

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f4c21aa0-37bf-443b-9ab5-085d596b1681n%40googlegroups.com.