Re: Permissions don't get translated in admin interface

[Mariusz Felisiak]

Is it not partly fixed by a52bdea5a27ba44b13eda93642231c65c581e083 

?

-- 
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/999dfe6a-230e-4bd7-b3f4-455142d24c6en%40googlegroups.com.

Re: Permissions don't get translated in admin interface

[Thibaud Colas]

 without further input, I’m not quite sure what to do with this. We need 
this ticket re-opened so anyone actually considers working on a fix for 
this. For reference, the initial reason for closing this bug report was:

> The permissions are stored in the database and don't get translated.

To me at least this is a poor reason. First off this is still a clear bug 
from the perspective of people who expect the admin to be in the language 
of their choosing. Second, there are clear ways to improve upon this even 
without significantly re-engineering how permission names are generated 
(see message above – and my proof of concept 
<https://github.com/thibaudcolas/django/pull/1>).

Any takers? Should I post this elsewhere?
On Friday, 14 October 2022 at 05:45:34 UTC+1 Thibaud Colas wrote:

> I worked on a potential fix for this yesterday at the Django London’s hack 
> day with Nick (hi Nick if you’re reading this!). 
>
>- Here is where translation names get created: 
>
> https://github.com/django/django/blob/main/django/contrib/auth/management/__init__.py#L31
>- And where the strings are generated for display: 
>
> https://github.com/django/django/blob/main/django/contrib/auth/models.py#L78
>- As well as: 
>
> https://github.com/django/django/blob/main/django/contrib/contenttypes/models.py#L150
>
> And here is a draft PR that makes those labels fully translate-able at 
> least for the default permissions: 
> https://github.com/thibaudcolas/django/pull/1
>
> It seems to work well. As far as I could see, there’s no reason for at 
> least the app name to be displayed in english (just need to switch from 
> app_label to verbose_name).
> On Sunday, 25 September 2022 at 14:02:33 UTC+1 Thibaud Colas wrote:
>
>> Thank you all for your suggestions so far :) Just to give a little bit 
>> more background – aside from ticket #1688 Permissions don't get 
>> translated in admin interface 
>> <https://code.djangoproject.com/ticket/1688>, this had also been 
>> discussed in Translation of group permissions 
>> <https://groups.google.com/g/django-developers/c/w93rJrPTPy0/m/1XfgIF28BgAJ> 
>> on 
>> the mailing list (though it’s not just for groups).
>>
>> To clarify what I’m after – in my opinion this needs to be treated as a 
>> bug to fix in Django itself – at least for translations of built-in 
>> permissions. Having a way to do this for custom ones would be nice too (see 
>> for example Wagtail issue #5341 
>> <https://github.com/wagtail/wagtail/issues/5341>). So devising how to 
>> fix this would be nice, but right now this is officially a "wontfix" so 
>> this would need to be addressed first.
>>
>> For reference, here is a screenshot of the current state, in Arabic 
>> (right-to-left language so the UI is partly mirrored):
>>
>> [image: translations-current-state.png]
>>
>> Translation names aren’t translated, while their model names are 
>> translated, and the app name isn’t translated ("auth" vs. app label 
>> "المصادقة والتفويض" in the sidebar).
>> On Sunday, 25 September 2022 at 12:12:21 UTC+1 ramez...@gmail.com wrote:
>>
>>> Hello 
>>>
>>> it's for this reason, i created this package 
>>> https://github.com/RamezIssac/django-tabular-permissions
>>> It displays the permissions in a table that is easily translated , and 
>>> easier to work with
>>>
>>> Aside from a 3rd party app, a workaround (like the one suggested above) 
>>> will be the way to go.
>>> For Django core, it think its very hard to do it as one can also have 
>>> more than one non English of languages supported .. which permission 
>>> language will be recorded in the database then ?
>>>
>>> Screen shot for tabular permissions
>>> [image: tabular_permisions.png]
>>>
>>> On Sunday, September 25, 2022 at 3:07:27 AM UTC+2 baido...@gmail.com 
>>> wrote:
>>>
>>>> Thanks
>>>>
>>>> On Sat, Sep 24, 2022, 22:28 Danilov Maxim  wrote:
>>>>
>>>>> Hi, Tribaud.
>>>>>
>>>>>  
>>>>>
>>>>> In your case you can override Permission admin to show translated 
>>>>> names of permissions and for widgets you can override modelchoiceiterator
>>>>>
>>>>> The name of permission you can translate like model.verbose_name + 
>>>>> gettext( ‘can’) + gettext(view/change/delete) and it should be translated.
>>>>>
>>>>> With custom translation is a little bit  more work, but it also works. 
>

Re: Drop CSRF middleware from the settings template

[Deepak Sain]

hello everyone i am deepak kumar sain new to tensorflow also new to 
opensource contributiuons , i am an student , i want to start my open 
source contribution journey can anyone helpme how can i contribute and what 
can i contribute am learning DSA in c++ and Flutter currently . thank you


On Friday, 5 May 2023 at 18:55:38 UTC+5:30 Ryan Hiebert wrote:

> I've been working on setting up a new project that's never going to see 
> the light of production, so I went down the road of just disabling CSRF for 
> that purpose. I notably found that the Django admin still requires CSRF, 
> even when the middleware has been removed from the MIDDLEWARE setting. I 
> found this because the development environment I was working in, 
> Codespaces, forwards and redirects to a browser via a public address rather 
> than localhost, and that difference means that CSRF checks were enforced in 
> that environment, though I had no trouble with localhost. There's likely 
> some details I'm missing in laying out this scenario, but it felt 
> interesting enough to mention in the context of this conversation.

-- 
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/30877bdf-e468-4f28-ae4f-7324521a9c79n%40googlegroups.com.

Re: Proposal on how add configuration options to Email Backends

[Mariusz Felisiak]

It seems we have a consensus here to support multiple email backends. 
Jacob, feel-free to create a new ticket.

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/a637ef14-58af-41ac-b20c-dd01079537c4n%40googlegroups.com.

Re: Fellow Reports - May 2023

[Mariusz Felisiak]

Week ending May 21, 2023

*Triaged:*
https://code.djangoproject.com/ticket/34565 - Add acheck_password() 
async method. (accepted)
https://code.djangoproject.com/ticket/34563 - 
ManifestStaticFilesStorage support for CSS module scripts in Javascript 
files. (someday/maybe)
https://code.djangoproject.com/ticket/34567 - slugify template filter 
with allow_unicode (duplicate)
https://code.djangoproject.com/ticket/28056 - Reverse migration for 
model rename with cross-app ForeignKey fails (duplicate)
https://code.djangoproject.com/ticket/34570 - QuerySet.defer() raises 
an AttributeError when the field is ManyToManyField or GenericForeignKey 
(accepted)
https://code.djangoproject.com/ticket/34568 - makemigrations --update 
should respect the --name option. (accepted)
https://code.djangoproject.com/ticket/34572 - Confirm/Add support for 
GDAL 3.7. (created)
https://code.djangoproject.com/ticket/34521 - Use __slots__ for 
template Node classes (wontfix)
https://code.djangoproject.com/ticket/34573 - Typo in "Writing your 
first Django app, part 5" - assertQuerysetEqual() (invalid)
https://code.djangoproject.com/ticket/34574 - Extend docs for 
`autoescape` and `escape` with examples using filters that operate with 
sequences (accepted)
https://code.djangoproject.com/ticket/34577 - New template filter 
`escapeseq` (accepted)
https://code.djangoproject.com/ticket/34579 - Documentation points to 
`django-developers` mailing list as primary point of contact for discussion 
(accepted)
https://code.djangoproject.com/ticket/34578 - Template filter `join` 
should not escape the joining string if `autoescape` is `off` (accepted)
https://code.djangoproject.com/ticket/34585 - Can we use Class with 
urlpatterns attribute for parameter in include method? (invalid)

*Reviewed/committed:*
https://github.com/django/django/pull/16858 - Fixed #34539 -- Restored 
get_prep_value() call when adapting JSONFields.
https://github.com/django/django/pull/16862 - Fixed #34570 -- Silenced 
noop deferral of many-to-many and GFK.
https://github.com/django/django/pull/16869 - Avoided parallel 
assignment in template classes.
https://github.com/django/django/pull/16855 - Fixed #34565 -- Added 
support for async checking of user passwords.
https://github.com/django/django/pull/16873 - Fixed #34578 -- Made 
"join" template filter respect autoescape for joiner.
https://github.com/django/django/pull/16800 - Refs #31949 -- Made 
@xframe_options_(deny/sameorigin/exempt) decorators to work with async 
functions.

*Reviewed:*
https://github.com/django/django/pull/16805 - Fixed #34521 -- Used 
__slots__ for more template classes.

*Authored:*
https://github.com/django/djangoproject.com/pull/1359 - Fixed Stripe 
webhooks crash when object is empty.
https://github.com/django/django/pull/16865 - Fixed #34568 -- Made 
makemigrations --update respect --name option.

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/a0464c9b-753f-4df6-acee-fdc9db1fc9c3n%40googlegroups.com.

Re: Ticket #30382 force_insert flag is not passed when saving parents on inherited models

[charettes]

I left some notes on the PR but I think the crux of the issue here is that 
you are trying to change the meaning of Model.save(force_insert=True) from 
force the insert of the current model to force the insert of the model and 
all its bases.

This is a problem not only for QuerySet.create but likely for a many other 
use cases in the wild that need a way to only force the creation of the 
leaf table but not others. In other words, the change you are proposing 
take one feature way (only insert leaf model) to introduce a new one 
(insert all bases) and thus is fundamentally backward incompatible.

To me the only way forward here is to introduce a new feature but as you've 
mentioned changing the signature of Model.save() is comple.

The only viable option I can think of is to change the accepted type for 
force_insert from bool to Type[Model] | Tuple[Type[Model]] to allow 
save_parent to determine which one should be forced inserted and which 
shouldn't.

In the case of the reported usage case

```
class ParentModel(models.Model):
id = models.BigIntegerField(primary_key=True)

class ChildModel(ParentModel): pass
```

That would mean that force_insert=ParentModel must be passed to opt-in into 
the full insertion mode (both issubclass(ChildModel, ParentModel) and 
issubclass(ParentModel, ParentModel))

```
ChildModel(id=1).save(force_insert=ParentModel)
```

That seems  like a viable option to me because

- An empty tuple is falsy which is coherent with force_insert=False
- A non-empty tuple is truthy and which is coherent with the fact the 
current leaf model must be inserted (current behavior)
- Complex MTI scenario forced insertion needs can be targeted with 
specially crafted base tuples (think of diamond inheritance)
- If a deep ancestor must be inserted then it means that all its children 
must also be inserted (makes sense due to how children must reference to 
parent)
- force_insert=models.Model can be used as a generic way to specify that 
all bases must be inserted independently of the chain of models involved

Hope that makes sense!

Cheers,
Simon

Le jeudi 18 mai 2023 à 22:46:35 UTC-4, Akash Sen a écrit :

> *[*Looking for an alternate approach*]*
> *Ticket link : *https://code.djangoproject.com/ticket/30382
>
> *Problem : *When saving we pass force_insert=True to prevent the extra 
> UPDATE statement that precedes the INSERT. The force_insert flag is 
> respected on the child table but not on the parent.
>
> *The main problem : *On our first go this issue would seem an easy 
> picking as we just have to pass the force_insert flag while saving the 
> parents, but as mentioned here 
>  it is going to 
> create a disaster of integrity errors in the Model.objects.create() method 
> with non-abstract inherited parents as the create method assumes 
> force_insert=True.
>
> *Approach 1: *Set the force_insert=False inside create method if that 
> contains a non-abstract parent model. 
>
> The problem with it is it generates an extra query while creating the non 
> abstract child model when the parent exists, more details can be found 
> here... 
>  (Tried 
> in the PR)
>
> *Approach 2: *Pass an extra flag to the save method and if the method 
> call is coming from create then prevent passing force_insert flag(i.e set 
> it to false) while saving parents when called via create, but as we cannot 
> change the signature of the save method we cannot simply take an extra 
> flag, so this comes down to a very simple question : 
>
> *How to pass a flag to a python method without changing its signature:*
> I can think of three approaches for this,
> 1. Inspecting a stack frame(Deprecated because of performance issues) - 
> Tried in the PR
> 2. Using a global variable (Deprecated because of performance issues)
> 3. Using a class variable (Deprecated because of backward compatibility as 
> names can collide with method, variable, property name of a model) - Tried 
> in the PR
>
> *PR link :* https://github.com/django/django/pull/16830
>
> If someone can suggest an alternate approach that would be great!
>

-- 
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/09ed76ee-6db9-4687-a18e-8416221f329bn%40googlegroups.com.

Re: Ticket #34555 ModelBase prevents addition of model Fields via __init_subclass__

[hottwaj]

Thanks for this!  Agree with your points and would be happy to add that 
documentation to the PR

On your point about accessing `_meta` in `__init_subclass__`:  in the 
interest of avoiding overcomplication I didn't bring it up in issue #34555, 
but now that the cat is out of the bag...  :)

I separately wrote a further change and initial unittests that would allow 
`_meta` to be added/modified in `__init_subclass__` - please see diff 
(relative to changes proposed for #34555) here:
https://github.com/hottwaj/django/pull/1/files

My plan was/is to submit this as a separate issue/PR if the changes in 
#34555 get the green light.

Some notes on implementation:
- I could not figure out how to change `ModelBase.__new__` to call 
`super().__new__` and set the `_meta` attr such that `__init_subclass__` 
could access the `_meta` attribute **without** breaking existing 
unittests.  Maybe someone more familiar with it than me can figure it out 
though I think this is mainly a design feature of current implementation
- instead, I tweaked `ModelBase.__new__` to pass a kwarg `cls_meta` to 
super().__new__` which is absorbed by `AltersData.__init_subclass__`.  
Probably a new (otherwise blank) method `ModelBase.__init_subclass__` would 
be a better place to absorb the new `cls_meta` kwarg instead.  
- with this approach you can see in the unittests that if a user wants to 
add/edit `_meta` in their implementation of `__init_subclass__` some extra 
setup is needed to create a blank `_meta` if one is not present.  Probably 
this boilerplate should go in a classmethod or as preparatory stuff in 
`ModelBase.__new__`

I think this change is also fairly unobtrusive, except that existing 
packages/users that make use of `__init_subclass__` would have to take care 
to pass through to `super().__init_subclass__` the new `cls_meta` kwarg so 
that it is available in a multiple inheritance scenario.  

Either way, you are right that `__init_subclass__` will not have access to 
model fields defined in the "usual" way (unless a similar approach of 
passing them as a kwarg is used), which will probably be surprising

Thanks!

On Tuesday, May 16, 2023 at 7:17:19 PM UTC+1 charettes wrote:

> Just wanted to publicly +1 here as well. I was skeptical that we could add 
> support for it without invasive changes at first but it seems to be 
> relatively straightforward to support.
>
> One ask I would add is that we explicitly document what is support and 
> what isn't. For example, at the time `__init_subclass__` is called one 
> should not expect `_meta` or any other subclass fields to be available and 
> that even when calling `super().__init_subclass__`. That might come as a 
> surprise to users that want to do anything to a trivial field addition 
> (e.g. perform model introspection). For non-trivial use cases a 
> class_prepared signal seems like it's still the best way to run code once 
> the class is fully initialized.
>
> Changing these expectations could be done by moving most of the 
> ModelBase.__new__ logic to Model.__init_subclass__ but this would require a 
> massive re-enginering of meta programming logic that is remain unchanged 
> for years.
>
> Le vendredi 12 mai 2023 à 09:38:04 UTC-4, Adam Johnson a écrit :
>
>> +1 from me. As Simon covered on the ticket, the change is small. Making 
>> Django classes support __init_subclass__ might unlock some nice dynamic 
>> field patterns.
>>
>> On Thu, May 11, 2023 at 12:47 PM hottwaj  wrote:
>>
>>> Hi there, I opened the above ticket and submitted a PR with fix and test 
>>> added.  I was asked to bring the issue here for wider review before the 
>>> ticket is re-opened (if that is what people agree to do)
>>>
>>> For reference, links to the ticket and PR are:
>>> https://code.djangoproject.com/ticket/34555
>>> https://github.com/django/django/pull/16849
>>>
>>> The issue raised is that current implementation of ModelBase.__new__ 
>>> prevents use of __init_subclass__ on a Model to add model fields
>>>
>>> e.g. the code listed at the end of this email does not currently work 
>>> (the PR fixes this).  
>>>
>>> Currently the same result could be achieved by i) writing a new 
>>> metaclass e.g. BaseBookModelMeta or ii) using a class decorator where 
>>> cls.add_to_class(field) is called.  
>>>
>>> Using __init_subclass__ is advised as a simpler alternative to writing a 
>>> metaclass to customise class creation, hence this PR.
>>>
>>> Hope that makes sense and appreciate any feedback.  Thanks!
>>>
>>>
>>> class BaseBookModel(models.Model):
>>> class Meta:
>>> abstract = True
>>>
>>> def __init_subclass__(

Re: Ticket #34555 ModelBase prevents addition of model Fields via __init_subclass__

[charettes]

Just wanted to publicly +1 here as well. I was skeptical that we could add 
support for it without invasive changes at first but it seems to be 
relatively straightforward to support.

One ask I would add is that we explicitly document what is support and what 
isn't. For example, at the time `__init_subclass__` is called one should 
not expect `_meta` or any other subclass fields to be available and that 
even when calling `super().__init_subclass__`. That might come as a 
surprise to users that want to do anything to a trivial field addition 
(e.g. perform model introspection). For non-trivial use cases a 
class_prepared signal seems like it's still the best way to run code once 
the class is fully initialized.

Changing these expectations could be done by moving most of the 
ModelBase.__new__ logic to Model.__init_subclass__ but this would require a 
massive re-enginering of meta programming logic that is remain unchanged 
for years.

Le vendredi 12 mai 2023 à 09:38:04 UTC-4, Adam Johnson a écrit :

> +1 from me. As Simon covered on the ticket, the change is small. Making 
> Django classes support __init_subclass__ might unlock some nice dynamic 
> field patterns.
>
> On Thu, May 11, 2023 at 12:47 PM hottwaj  wrote:
>
>> Hi there, I opened the above ticket and submitted a PR with fix and test 
>> added.  I was asked to bring the issue here for wider review before the 
>> ticket is re-opened (if that is what people agree to do)
>>
>> For reference, links to the ticket and PR are:
>> https://code.djangoproject.com/ticket/34555
>> https://github.com/django/django/pull/16849
>>
>> The issue raised is that current implementation of ModelBase.__new__ 
>> prevents use of __init_subclass__ on a Model to add model fields
>>
>> e.g. the code listed at the end of this email does not currently work 
>> (the PR fixes this).  
>>
>> Currently the same result could be achieved by i) writing a new metaclass 
>> e.g. BaseBookModelMeta or ii) using a class decorator where 
>> cls.add_to_class(field) is called.  
>>
>> Using __init_subclass__ is advised as a simpler alternative to writing a 
>> metaclass to customise class creation, hence this PR.
>>
>> Hope that makes sense and appreciate any feedback.  Thanks!
>>
>>
>> class BaseBookModel(models.Model):
>> class Meta:
>> abstract = True
>>
>> def __init_subclass__(cls, author_cls, **kwargs):
>> super().__init_subclass__(**kwargs)
>> cls.author = models.ForeignKey(author_cls, 
>> on_delete=models.CASCADE)
>>
>> class Author(models.Model):
>> name = models.CharField(max_length=256, unique=True)
>>
>> class Book(BaseBookModel, author_cls=Author):
>> pass
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/015a5798-d084-4afb-b800-e83154301ec7n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/015a5798-d084-4afb-b800-e83154301ec7n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/ffaba0d3-c31d-4e49-bdaf-effb021c149bn%40googlegroups.com.

Re: Fellow Reports - May 2023

[Mariusz Felisiak]

Week ending May 14, 2023

*Triaged:*
https://code.djangoproject.com/ticket/34546 - Failed migration yields 
to unmigratable app:""OperationalError: (1050, "Table '' already 
exists") (invalid)
https://code.djangoproject.com/ticket/34547 - Deprecate 
DatabaseOperations.field_cast_sql(). (created)
https://code.djangoproject.com/ticket/34549 - Extra select query when 
parent model consists of primary key only (duplicate)
https://code.djangoproject.com/ticket/34539 - `get_prep_value` no 
longer called for JSONField (accepted)
https://code.djangoproject.com/ticket/34550 - Send email with 
EMAIL_USE_TLS=True but get SSL error. (duplicate)
https://code.djangoproject.com/ticket/34551 - Case-When aggregation 
over aggregated fields doesn't work since 4.2 (accepted)
https://code.djangoproject.com/ticket/34554 - Reverse(Value(...)) 
crashes on Oracle. (created)
https://code.djangoproject.com/ticket/34555 - Dynamic model fields 
without using a metaclass (invalid)
https://code.djangoproject.com/ticket/34557 - Time-based model field 
cleaning and TypeErrors (duplicate)
https://code.djangoproject.com/ticket/34558 - QuerySet.bulk_create() 
crashes with Now() on Oracle. (created)
https://code.djangoproject.com/ticket/34552 - Delaying get_from_clause 
call as much as possible. (needsinfo)
https://code.djangoproject.com/ticket/34560 - Update admin's jQuery to 
3.7.X. (created)
https://code.djangoproject.com/ticket/34561 - "DatabaseError: Forced 
update did not affect any rows" on SessionStore save() (invalid)
https://code.djangoproject.com/ticket/34564 - returning None instead of 
zero in Count annotation (accepted)

*Reviewed/committed:*
https://github.com/django/django/pull/16834 - Fixed #34545 -- Corrected 
the number of months in installation FAQ.
https://github.com/django/django/pull/16836 - Refs #34534 -- Reduced 
Add/RemoveConstraint and Add/RenameIndex operations when optimizing 
migrations.
https://github.com/django/django/pull/16840 - Fixed #34553 -- Fixed 
improper % escaping of literal in constraints.
https://github.com/django/django/pull/16092 - Fixed #470 -- Added 
support for database defaults on fields.

*Authored:*
https://github.com/django/django/pull/16835 - Fixed #34544 -- Avoided 
DBMS_LOB.SUBSTR() wrapping with IS NULL condition on Oracle.
https://github.com/django/django/pull/16842 - Fixed #34554 -- Fixed 
Reverse(Value(…)) crash on Oracle.

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/e78b2e38-4833-4947-9dbb-c314df2bb74an%40googlegroups.com.

Re: Fellow Reports - May 2023

[natali...@gmail.com]

Hello everyone!

I've posted my fellow report in the 
forum: https://forum.djangoproject.com/t/django-fellow-report-natalia/20942
Following reports will be threaded in that topic \o/

Thank you! Natalia.

On Monday, May 8, 2023 at 9:33:15 AM UTC-3 natali...@gmail.com wrote:

> Week ending 2023-05-07 (week 19)
>
> Triaged:
>   https://code.djangoproject.com/ticket/34531 - Rendering form throws 
> deprecation warning (invalid)
>   https://code.djangoproject.com/ticket/34539 - `get_prep_value` no 
> longer called for JSONField (accepted with ongoing conversations)
>   https://code.djangoproject.com/ticket/34540 - [feature request] Run 
> FileField storage callable during runtime and not during buildtime (wontfix)
>   https://code.djangoproject.com/ticket/34542 - Required fields not 
> enforced when interactively using createsuperuser (invalid)
>   https://code.djangoproject.com/ticket/34543 - Thousand separator 
> breaking templates (needsinfo)
>
> Commented on:
>   https://code.djangoproject.com/ticket/32827 - Squashing migrations 
> isn't very effective in complicated projects; rewrite docs to provide a 
> preferred manual trimming process
>
> Reviewed:
>  https://github.com/django/django/pull/16820 - Fixed #34529, Refs #34525 
> -- Reduced index operations with Meta.indexes/index_together when 
> optimizing migrations.
>   https://github.com/django/django/pull/16822 -  Update tutorial04.txt to 
> make location of change explicit
>   https://github.com/django/django/pull/16777 - Fixed #12780 -- Added 
> compound form/formset validation in ModelAdmin
>   https://github.com/django/django/pull/16592 - Fixed #30386 -- Fixed 
> primary key quoting in admin related object links.
>
> Reviewed and landed:
>   https://github.com/django/django/pull/16821 - Fixed #34530 -- Improved 
> docs when customizing storage for FileField.
>   https://github.com/django/django/pull/14499 - Refs #31369 -- Improved 
> hint message in NullBooleanField's deprecation warning.
>
> PR Cleanup
>   https://github.com/django/django/pull/14783 - Tab completion when 
> executing as `./manage.py`
>
> Other/Misc:
>   Watched and learnt from Mariusz while he released Django 4.2.1, 4.1.9 
> and 3.2.19.
>   Resurfaced conversation on (completing?) migrating to the forum, still 
> unclear how that'll continue.
>   DjangoCon US flight tickets! :tada:
>

-- 
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/877c65a9-6e43-425e-aeb7-9533dc527120n%40googlegroups.com.

Re: Added support for Database Level Cascades

[jatin singh]

signals ?..

On Sun, May 14, 2023 at 12:01 PM Harro  wrote:

> I have just one question, will this still trigger on delete signals for
> cascaded models?
> That's the main reason the cascade happens in Django and not in the
> database.
>
> On Saturday, 13 May 2023 at 16:35:01 UTC+2 Akash Sen wrote:
>
>> *Added support for Database Level Cascades*
>>
>> *PR link *: https://github.com/django/django/pull/16851
>>
>> *Ref discussion : *
>> https://groups.google.com/g/django-developers/c/Sxj7eS7-8SQ/m/jaM1rPbZEQAJ
>>
>> *Approach :*
>> The on_delete argument for ForeignKey class now supports an extra option
>> DB_CASCADE this will behave like DO_NOTHING in Django, but leverage  the
>> Database level cascading options supported by SQL.
>>
>> A new optional ar gument named  on_delete_db is also passed to the
>> ForeignKey. This will specify the type of database level cascading we are
>> looking for if the on_delete is set to DB_CASCADE. Supported values of the
>> on_delete_db argument can be the following:
>>
>> ON_DELETE_DB_CHOICES.DO_NOTHING_DB : Does nothing, used as default value.
>> ON_DELETE_DB_CHOICES.CASCADE_DB : Deletes the child on parent deletion.
>> ON_DELETE_DB_CHOICES.RESTRICT_DB : Prevent the deletion if child exists.
>> ON_DELETE_DB_CHOICES.SET_NULL_DB : Set the value to null in child table.
>>
>> This will modify the SQL query during foreignkey generation.
>>
>> *Checks performed :*
>> 1. on_delete = DB_CASCADE and the model containing the field has a non
>> abstract parent model. As inherited the model contains a parent_ptr with
>> in-python cascading options,(OneToOneField with on_delete=models.CASCADE)
>>  both cannot be used  together.
>> *Code :*
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1041
>> *Related testcase :*
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L93
>>
>> 2. on_delete = DB_CASCADE and the model containing generic foreign keys
>> or generic relation. In that case we prevent using DB_CASCADE too.
>> *Code :*
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1060
>> *Related testcase :*
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L144
>>
>> 3. Both on_delete and on_delete_db are specified. In order to specify the
>> value of on_delete_db, on_delete must be set to DB_CASCADE.
>> *Code :*
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1137
>> *Related testcase :*
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L11
>>
>> 4. on_delete_db is set to SET_NULL_DB but the field is not nullable.
>> *Code :*
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1150
>> *Related testcase :*
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L66
>>
>> 5. Restricting the use of normal cascading if the foreignkey parent uses
>> DB_CASCADING as this will generate untracable integrity errors.
>> *Code :*  1.
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1104
>>   2.
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1162
>> *Related testcase :*
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L33
>>
>> --
> 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/fef26391-c9ec-49d6-9ce9-a1d4fc52b1a3n%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/CAPXsortYbyzOo0%3Dju7KVsuXgYgGUNts1V1sKpM7h5xKaKs9H0A%40mail.gmail.com.

Re: Added support for Database Level Cascades

[Akash Sen]

No it will not trigger the delete signals. The point is to delete an object 
with O(1) database queries instead of O(n), Have to add another warning 
message if the signals are being used with DB level cascading.

On Sunday, May 14, 2023 at 11:45:56 AM UTC+5:30 Harro wrote:

> I have just one question, will this still trigger on delete signals for 
> cascaded models?
> That's the main reason the cascade happens in Django and not in the 
> database.
>
> On Saturday, 13 May 2023 at 16:35:01 UTC+2 Akash Sen wrote:
>
>> *Added support for Database Level Cascades*
>>
>> *PR link *: https://github.com/django/django/pull/16851
>>
>> *Ref discussion : *
>> https://groups.google.com/g/django-developers/c/Sxj7eS7-8SQ/m/jaM1rPbZEQAJ
>>
>> *Approach :*
>> The on_delete argument for ForeignKey class now supports an extra option 
>> DB_CASCADE this will behave like DO_NOTHING in Django, but leverage  the 
>> Database level cascading options supported by SQL.
>>
>> A new optional ar gument named  on_delete_db is also passed to the 
>> ForeignKey. This will specify the type of database level cascading we are 
>> looking for if the on_delete is set to DB_CASCADE. Supported values of the 
>> on_delete_db argument can be the following:
>>
>> ON_DELETE_DB_CHOICES.DO_NOTHING_DB : Does nothing, used as default value.
>> ON_DELETE_DB_CHOICES.CASCADE_DB : Deletes the child on parent deletion.
>> ON_DELETE_DB_CHOICES.RESTRICT_DB : Prevent the deletion if child exists.
>> ON_DELETE_DB_CHOICES.SET_NULL_DB : Set the value to null in child table.
>>
>> This will modify the SQL query during foreignkey generation.
>>
>> *Checks performed :*
>> 1. on_delete = DB_CASCADE and the model containing the field has a non 
>> abstract parent model. As inherited the model contains a parent_ptr with 
>> in-python cascading options,(OneToOneField with on_delete=models.CASCADE) 
>>  both cannot be used  together.
>> *Code :* 
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1041
>> *Related testcase :* 
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L93
>>
>> 2. on_delete = DB_CASCADE and the model containing generic foreign keys 
>> or generic relation. In that case we prevent using DB_CASCADE too.
>> *Code :* 
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1060
>> *Related testcase :* 
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L144
>>
>> 3. Both on_delete and on_delete_db are specified. In order to specify the 
>> value of on_delete_db, on_delete must be set to DB_CASCADE.
>> *Code :* 
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1137
>> *Related testcase :* 
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L11
>>
>> 4. on_delete_db is set to SET_NULL_DB but the field is not nullable.
>> *Code :* 
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1150
>> *Related testcase :* 
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L66
>>
>> 5. Restricting the use of normal cascading if the foreignkey parent uses 
>> DB_CASCADING as this will generate untracable integrity errors.
>> *Code :*  1. 
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1104
>>   2. 
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1162
>> *Related testcase :* 
>> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L33
>>
>>

-- 
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/3e17a21f-7c90-4254-a429-fae6d8bc67e8n%40googlegroups.com.

Re: Added support for Database Level Cascades

[Harro]

I have just one question, will this still trigger on delete signals for 
cascaded models?
That's the main reason the cascade happens in Django and not in the 
database.

On Saturday, 13 May 2023 at 16:35:01 UTC+2 Akash Sen wrote:

> *Added support for Database Level Cascades*
>
> *PR link *: https://github.com/django/django/pull/16851
>
> *Ref discussion : *
> https://groups.google.com/g/django-developers/c/Sxj7eS7-8SQ/m/jaM1rPbZEQAJ
>
> *Approach :*
> The on_delete argument for ForeignKey class now supports an extra option 
> DB_CASCADE this will behave like DO_NOTHING in Django, but leverage  the 
> Database level cascading options supported by SQL.
>
> A new optional ar gument named  on_delete_db is also passed to the 
> ForeignKey. This will specify the type of database level cascading we are 
> looking for if the on_delete is set to DB_CASCADE. Supported values of the 
> on_delete_db argument can be the following:
>
> ON_DELETE_DB_CHOICES.DO_NOTHING_DB : Does nothing, used as default value.
> ON_DELETE_DB_CHOICES.CASCADE_DB : Deletes the child on parent deletion.
> ON_DELETE_DB_CHOICES.RESTRICT_DB : Prevent the deletion if child exists.
> ON_DELETE_DB_CHOICES.SET_NULL_DB : Set the value to null in child table.
>
> This will modify the SQL query during foreignkey generation.
>
> *Checks performed :*
> 1. on_delete = DB_CASCADE and the model containing the field has a non 
> abstract parent model. As inherited the model contains a parent_ptr with 
> in-python cascading options,(OneToOneField with on_delete=models.CASCADE) 
>  both cannot be used  together.
> *Code :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1041
> *Related testcase :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L93
>
> 2. on_delete = DB_CASCADE and the model containing generic foreign keys or 
> generic relation. In that case we prevent using DB_CASCADE too.
> *Code :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1060
> *Related testcase :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L144
>
> 3. Both on_delete and on_delete_db are specified. In order to specify the 
> value of on_delete_db, on_delete must be set to DB_CASCADE.
> *Code :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1137
> *Related testcase :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L11
>
> 4. on_delete_db is set to SET_NULL_DB but the field is not nullable.
> *Code :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1150
> *Related testcase :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L66
>
> 5. Restricting the use of normal cascading if the foreignkey parent uses 
> DB_CASCADING as this will generate untracable integrity errors.
> *Code :*  1. 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1104
>   2. 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1162
> *Related testcase :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L33
>
>

-- 
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/fef26391-c9ec-49d6-9ce9-a1d4fc52b1a3n%40googlegroups.com.

Re: Deprecate CICharField, CIEmailField, CITextField

['Johannes Maron' via Django developers (Contributions to Django itself)]

Hi,

Yes, I hope Django will continue to expand expression support. I worked so
hard on the SQL compiler to facilitate those kinds of features.
Anyhow, since db collations are not an adequate replacement for CI text, we
will create an open-source backport of the CITEXT fields.
Once we are done, I will open a PR to alter the documentation, to point
towards this option. This should allow users to choose, and will probably
easy migration to Django 5 for some.

But first, I gotta play Tears of the Kindom….

Cheers!
Joe


On Fri, May 12, 2023 at 1:37 PM 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

>
> What I am struggling now with is whenever I specify
>> `db_collation="case_insensitive"` on the field and this field is used in
>> `ModelAdmin.search_fields` - Django simply breaks (as it by default uses
>> `icontains` lookup).
>> That is quite unfortunate for the big projects, as I have to come up with
>> some generic solution to something that was not broken before this feature
>> deprecation (and the docs does not mention this case).
>> Good that Adam covered it in the article, but I feel that this could be
>> handled on a lower level than right now. Currently, we'd need to write a
>> manual annotation for admin queryset in almost every project that uses
>> usernames or emails (which my guess is something you'd want to be
>> case-insensitive on a database level).
>>
>
> Yes, I discovered this too. It's what prompted me to write the
> parametrized admin tests covered in my later blog post:
> https://adamj.eu/tech/2023/03/17/django-parameterized-tests-model-admin-classes/
>
> Annotating appropriately is what I found to work.
>
> Tom Carrick wrote earlier:
>
> I actually think the best practice right now for having searchable
>> case-insensitive emails is to do it old-school - have a regular EmailField
>> with an index on UPPER("email") and then make sure you always use iexact,
>> istartswith etc. and this will properly use the indexes and result in a
>> faster search.
>>
>
> I also think this may be a better approach, now. But I haven't tried it.
>
> Django 5.0 will hopefully come with generated fields:
> https://github.com/django/django/pull/16417 . We may then be able to
> store the user-provided email in "email_original_cased" (or whatever) and
> make "email" a GeneratedField(expression=Lower("email")), with the
> lowercase collation and a unique consrtaint. We'll have to see...
>
>
>> For example, in terms of documentation, we could add a note on
>> `db_collation` to `icontains` page:
>> https://docs.djangoproject.com/en/4.2/ref/models/querysets/#icontains
>
>
> That sounds like too specific a note to add. Many different data types in
> many different databases fail to work with some existing lookups, such as
> several custom fields in Django-MySQL:
> https://django-mysql.readthedocs.io/en/latest/model_fields/index.html
>
>
> On Sat, May 6, 2023 at 9:50 AM 'Johannes Maron' via Django developers
> (Contributions to Django itself) 
> wrote:
>
>> Hello again,
>>
>> I trust Mariusz' assessment regarding the maintainability. In that case,
>> I presume a separate package from a 3rd party with commercial interest
>> might be the best option going forward.
>>
>> Thanks for all the considerations and explanations.
>>
>> Cheers!
>> Joe
>>
>> On Wed, Apr 19, 2023 at 3:48 PM fly.a...@gmail.com 
>> wrote:
>>
>>> Hey everyone!
>>>
>>> Thanks for the discussion.
>>> And special thanks @Adam, for the great article, helped us with the
>>> migration.
>>>
>>> What I am struggling now with is whenever I specify
>>> `db_collation="case_insensitive"` on the field and this field is used in
>>> `ModelAdmin.search_fields` - Django simply breaks (as it by default uses
>>> `icontains` lookup).
>>> That is quite unfortunate for the big projects, as I have to come up
>>> with some generic solution to something that was not broken before this
>>> feature deprecation (and the docs does not mention this case).
>>> Good that Adam covered it in the article, but I feel that this could be
>>> handled on a lower level than right now. Currently, we'd need to write a
>>> manual annotation for admin queryset in almost every project that uses
>>> usernames or emails (which my guess is something you'd want to be
>>> case-insensitive on a database level).
>>>
>>> I wonder how we could move forward (in case reverting this is not an
>>> option) and reduce overall aftermath stress.
>>> For example, in terms of documentation, we could add a note on
>>> `db_collation` to `icontains` page:
>>> https://docs.djangoproject.com/en/4.2/ref/models/querysets/#icontains
>>>
>>> But I also feel that might not be enough.
>>>
>>> Best,
>>> Rust
>>>
>>>
>>> On Tuesday, 18 April 2023 at 09:52:20 UTC+2 Johannes Maron wrote:
>>>
 Thanks Adam,

 of course I read your well-written article before diving into this
 topic, thanks for sharing.

 However, I don't agree about the index. The best solution is using the
 

Re: Conclusion of ticket #26761

['Adam Johnson' via Django developers (Contributions to Django itself)]

I have replied on the ticket with an example using arbitrary HTML as
required.

On Wed, May 10, 2023 at 10:30 AM Carsten Fuchs 
wrote:

> Hello,
>
> ticket #26761 was closed as wontfix, however I don't understand the reason.
> https://code.djangoproject.com/ticket/26761#comment:19
>
> The ticket's author asked to add a help_text-like attribute for read-only
> fields that are specified via functions. The intention was for it to work
> analogously to the help_text attribute of model fields.
>
> For such an attribute, there are two places that it might affect:
>
>   - the list page (where the help_text of a model field is available as a
> tooltip over a "(?)" mark in the column header)
>
>   - the change object page (where the help_text of a model field is
> available as a message below the field's value)
>
> Please see that attached image for an example.
>
> Unfortunately, Mariusz closed the ticket with the argument that
> `short_description` could be used in place of `help_text`. However, to the
> best of my understanding, that is not right: `short_description` changes
> the *label* of the fields (in the screenshot "Lokaler Zeitpunkt" and
> "Bewertung"), but not the text below the values.
>
> May this be reconsidered?
>
> Best regards,
> Carsten
>
> --
> 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/8e72c318-f28d-465f-8707-47e77a5d0d20%40cafu.de
> .
>

-- 
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/CAMyDDM1Ha2vj_ZM7KmCHd4bSF1GpzKxDYtuFMRHdg5xwq_grmg%40mail.gmail.com.

Re: Ticket #34555 ModelBase prevents addition of model Fields via __init_subclass__

['Adam Johnson' via Django developers (Contributions to Django itself)]

+1 from me. As Simon covered on the ticket, the change is small. Making
Django classes support __init_subclass__ might unlock some nice dynamic
field patterns.

On Thu, May 11, 2023 at 12:47 PM hottwaj 
wrote:

> Hi there, I opened the above ticket and submitted a PR with fix and test
> added.  I was asked to bring the issue here for wider review before the
> ticket is re-opened (if that is what people agree to do)
>
> For reference, links to the ticket and PR are:
> https://code.djangoproject.com/ticket/34555
> https://github.com/django/django/pull/16849
>
> The issue raised is that current implementation of ModelBase.__new__
> prevents use of __init_subclass__ on a Model to add model fields
>
> e.g. the code listed at the end of this email does not currently work (the
> PR fixes this).
>
> Currently the same result could be achieved by i) writing a new metaclass
> e.g. BaseBookModelMeta or ii) using a class decorator where
> cls.add_to_class(field) is called.
>
> Using __init_subclass__ is advised as a simpler alternative to writing a
> metaclass to customise class creation, hence this PR.
>
> Hope that makes sense and appreciate any feedback.  Thanks!
>
>
> class BaseBookModel(models.Model):
> class Meta:
> abstract = True
>
> def __init_subclass__(cls, author_cls, **kwargs):
> super().__init_subclass__(**kwargs)
> cls.author = models.ForeignKey(author_cls,
> on_delete=models.CASCADE)
>
> class Author(models.Model):
> name = models.CharField(max_length=256, unique=True)
>
> class Book(BaseBookModel, author_cls=Author):
> pass
>
> --
> 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/015a5798-d084-4afb-b800-e83154301ec7n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/015a5798-d084-4afb-b800-e83154301ec7n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAMyDDM2OojqTe5r_SBiWcVAgOLSZHNcdwg9qvLBT%2BBOpxR2yyg%40mail.gmail.com.

Re: Deprecate CICharField, CIEmailField, CITextField

['Adam Johnson' via Django developers (Contributions to Django itself)]

> What I am struggling now with is whenever I specify
> `db_collation="case_insensitive"` on the field and this field is used in
> `ModelAdmin.search_fields` - Django simply breaks (as it by default uses
> `icontains` lookup).
> That is quite unfortunate for the big projects, as I have to come up with
> some generic solution to something that was not broken before this feature
> deprecation (and the docs does not mention this case).
> Good that Adam covered it in the article, but I feel that this could be
> handled on a lower level than right now. Currently, we'd need to write a
> manual annotation for admin queryset in almost every project that uses
> usernames or emails (which my guess is something you'd want to be
> case-insensitive on a database level).
>

Yes, I discovered this too. It's what prompted me to write the parametrized
admin tests covered in my later blog post:
https://adamj.eu/tech/2023/03/17/django-parameterized-tests-model-admin-classes/

Annotating appropriately is what I found to work.

Tom Carrick wrote earlier:

I actually think the best practice right now for having searchable
> case-insensitive emails is to do it old-school - have a regular EmailField
> with an index on UPPER("email") and then make sure you always use iexact,
> istartswith etc. and this will properly use the indexes and result in a
> faster search.
>

I also think this may be a better approach, now. But I haven't tried it.

Django 5.0 will hopefully come with generated fields:
https://github.com/django/django/pull/16417 . We may then be able to store
the user-provided email in "email_original_cased" (or whatever) and make
"email" a GeneratedField(expression=Lower("email")), with the lowercase
collation and a unique consrtaint. We'll have to see...


> For example, in terms of documentation, we could add a note on
> `db_collation` to `icontains` page:
> https://docs.djangoproject.com/en/4.2/ref/models/querysets/#icontains


That sounds like too specific a note to add. Many different data types in
many different databases fail to work with some existing lookups, such as
several custom fields in Django-MySQL:
https://django-mysql.readthedocs.io/en/latest/model_fields/index.html


On Sat, May 6, 2023 at 9:50 AM 'Johannes Maron' via Django developers
(Contributions to Django itself)  wrote:

> Hello again,
>
> I trust Mariusz' assessment regarding the maintainability. In that case, I
> presume a separate package from a 3rd party with commercial interest might
> be the best option going forward.
>
> Thanks for all the considerations and explanations.
>
> Cheers!
> Joe
>
> On Wed, Apr 19, 2023 at 3:48 PM fly.a...@gmail.com 
> wrote:
>
>> Hey everyone!
>>
>> Thanks for the discussion.
>> And special thanks @Adam, for the great article, helped us with the
>> migration.
>>
>> What I am struggling now with is whenever I specify
>> `db_collation="case_insensitive"` on the field and this field is used in
>> `ModelAdmin.search_fields` - Django simply breaks (as it by default uses
>> `icontains` lookup).
>> That is quite unfortunate for the big projects, as I have to come up with
>> some generic solution to something that was not broken before this feature
>> deprecation (and the docs does not mention this case).
>> Good that Adam covered it in the article, but I feel that this could be
>> handled on a lower level than right now. Currently, we'd need to write a
>> manual annotation for admin queryset in almost every project that uses
>> usernames or emails (which my guess is something you'd want to be
>> case-insensitive on a database level).
>>
>> I wonder how we could move forward (in case reverting this is not an
>> option) and reduce overall aftermath stress.
>> For example, in terms of documentation, we could add a note on
>> `db_collation` to `icontains` page:
>> https://docs.djangoproject.com/en/4.2/ref/models/querysets/#icontains
>>
>> But I also feel that might not be enough.
>>
>> Best,
>> Rust
>>
>>
>> On Tuesday, 18 April 2023 at 09:52:20 UTC+2 Johannes Maron wrote:
>>
>>> Thanks Adam,
>>>
>>> of course I read your well-written article before diving into this
>>> topic, thanks for sharing.
>>>
>>> However, I don't agree about the index. The best solution is using the
>>> CITEXT db type, which is very much alive.
>>> Should Django to deprecate support for the db type, a 3rd party package
>>> seems the bast choice for me.
>>> With the downside of me having to maintain yet another package. But I
>>> can understand if the Django project has no interest in maintenance.
>>>
>>> In any event, I opened a ticket:
>>> https://code.djangoproject.com/ticket/34501
>>>
>>> Best Joe
>>>
>>>
>>> On Fri, Apr 14, 2023 at 11:36 AM 'Adam Johnson' via Django developers
>>> (Contributions to Django itself)  wrote:
>>>
 Just to note, for anyone that finds it useful, that I wrote a blog post
 on migrating to collations:
 https://adamj.eu/tech/2023/02/23/migrate-django-postgresql-ci-fields-case-insensitive-collation/

 

Re: Can we move the activity on this list to the Forum now?

[natali...@gmail.com]

I'm also available to do some moderation in the forum. I'll try to chase 
getting moderator perms to help!

On Saturday, May 6, 2023 at 5:09:51 AM UTC-3 Carlton Gibson wrote:

> Hey Curtis. 
>
> The notifications settings are very flexible, and allow good filtering (to 
> your inbox) if that's how you want them. 
>
> For example, I'm able to get notifications for the Django Internals 
> category, and the Async subcategory of Using Django (and then I'm able to 
> keep up with the rest just by glancing at the latest tab.) 
>
> The water is nice  
> C.
>
>
> On Thu, 4 May 2023 at 07:29, Curtis Maloney  wrote:
>
>> Does the Forum allow me to get email notifications / summaries?
>>
>> If not, it will mean I disconnect with that part of the community.
>>
>> --
>> Curtis
>>
>> On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:
>>
>> Yes please!
>>
>>
>>
>> On May 3, 2023 at 11:19:12 PM, jure.er...@gmail.com (jure.er...@gmail.com) 
>> wrote:
>>
>>
>> +1
>>
>>  
>>
>> *From:* django-d...@googlegroups.com  *On 
>> Behalf Of *natali...@gmail.com
>> *Sent:* sreda, 03. maj 2023 20:10
>> *To:* Django developers (Contributions to Django itself) <
>> django-d...@googlegroups.com>
>> *Subject:* Re: Can we move the activity on this list to the Forum now?
>>
>>  
>>
>> Hello everyone!
>>
>>  
>>
>> I was wondering if we could make a decision about this topic. On the one 
>> hand, and as far as I understand, the forum is the preferred channel of 
>> communication. On the other hand, having multiple channels of communication 
>> can spread important discussions too thin, making it difficult to have 
>> productive conversations in one place.
>>
>>  
>>
>> As a newcomer to the contributing community, I can attest that the 
>> current situation causes some confusion. IMHO, the same applies to the chat 
>> options: there is IRC and the Discord server (though perhaps I should start 
>> a new forum topic about that in order to keep decisions separated).
>>
>>  
>>
>> In summary, I'm +1 to "move on-mass (all few of us :) over there"!
>>
>>  
>>
>> Thank you!
>>
>> Natalia.
>>
>> On Thursday, January 26, 2023 at 10:07:36 AM UTC-3 Alex Krupp wrote:
>>
>> I just submitted a proposal to create a Discourse plugin to improve the 
>> accuracy of their inbound email parsing. This would enable two things:
>>
>>- Folks who prefer to live in their inbox could continue to do so and 
>>contribute by just replying to emails. Discourse currently has 
>>reply-by-email, but it often mangles formatting and/or entirely deletes 
>>text. Once these issues are fixed, folks who like the current experience 
>>would be able to just pretend the forum doesn't exist and continue having 
>>the same experience as they currently have with Google Groups.
>>- Right now importing the archives from Google Groups into Discourse 
>>isn't realistic for the same reasons; some messages will import 
>> correctly, 
>>but others will be mangled or missing text. This would also be made 
>>possible.
>>
>> If this is something you care about (positively or negatively), here is 
>> the exploratory proposal:
>>
>>  
>>
>>
>> https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944
>>
>>  
>>
>> Any feedback and/or testing would be much appreciated! Right now 
>> Discourse recognizes that this is a problem and is interested in solving 
>> it, but getting it prioritized will require folks to A) speak up saying 
>> they want it done B) test the underlying API to verify that it actually 
>> solves the problem.
>>
>>  
>>
>> Alex
>>
>>  
>>
>> On Fri, Jan 20, 2023 at 2:24 AM Carlton Gibson  
>> wrote:
>>
>> OK, I've updated the Trac wiki page to point to the forum too. (We use 
>> this as a wiki-link in responses to guide folk onwards.) 
>>
>>  
>>
>> The docs have a `|django-developers|` shortcut used in quite a few places 
>> so that needs a moment more to review and adjust. 
>>
>> (I'll look at it soon-ish... — if no-one beats me to it :) 
>>
>>  
>>
>> Thanks. 
>>
>> C
>>
>>  
>>
>> On Thu, 19 Jan 2023 at 18:15, Andrew Godwin  wrote:
>>
>> We should at least update those Trac and Triage Workflow docs to point to 
>>

Re: Deprecate CICharField, CIEmailField, CITextField

['Johannes Maron' via Django developers (Contributions to Django itself)]

Hello again,

I trust Mariusz' assessment regarding the maintainability. In that case, I
presume a separate package from a 3rd party with commercial interest might
be the best option going forward.

Thanks for all the considerations and explanations.

Cheers!
Joe

On Wed, Apr 19, 2023 at 3:48 PM fly.a...@gmail.com 
wrote:

> Hey everyone!
>
> Thanks for the discussion.
> And special thanks @Adam, for the great article, helped us with the
> migration.
>
> What I am struggling now with is whenever I specify
> `db_collation="case_insensitive"` on the field and this field is used in
> `ModelAdmin.search_fields` - Django simply breaks (as it by default uses
> `icontains` lookup).
> That is quite unfortunate for the big projects, as I have to come up with
> some generic solution to something that was not broken before this feature
> deprecation (and the docs does not mention this case).
> Good that Adam covered it in the article, but I feel that this could be
> handled on a lower level than right now. Currently, we'd need to write a
> manual annotation for admin queryset in almost every project that uses
> usernames or emails (which my guess is something you'd want to be
> case-insensitive on a database level).
>
> I wonder how we could move forward (in case reverting this is not an
> option) and reduce overall aftermath stress.
> For example, in terms of documentation, we could add a note on
> `db_collation` to `icontains` page:
> https://docs.djangoproject.com/en/4.2/ref/models/querysets/#icontains
>
> But I also feel that might not be enough.
>
> Best,
> Rust
>
>
> On Tuesday, 18 April 2023 at 09:52:20 UTC+2 Johannes Maron wrote:
>
>> Thanks Adam,
>>
>> of course I read your well-written article before diving into this topic,
>> thanks for sharing.
>>
>> However, I don't agree about the index. The best solution is using the
>> CITEXT db type, which is very much alive.
>> Should Django to deprecate support for the db type, a 3rd party package
>> seems the bast choice for me.
>> With the downside of me having to maintain yet another package. But I can
>> understand if the Django project has no interest in maintenance.
>>
>> In any event, I opened a ticket:
>> https://code.djangoproject.com/ticket/34501
>>
>> Best Joe
>>
>>
>> On Fri, Apr 14, 2023 at 11:36 AM 'Adam Johnson' via Django developers
>> (Contributions to Django itself)  wrote:
>>
>>> Just to note, for anyone that finds it useful, that I wrote a blog post
>>> on migrating to collations:
>>> https://adamj.eu/tech/2023/02/23/migrate-django-postgresql-ci-fields-case-insensitive-collation/
>>>
>>> But yes, I have also been thinking like Tom that indexing UPPER("email")
>>> seems to be the path of least complexity...
>>>
>>> On Thu, Apr 13, 2023 at 8:12 AM Tom Carrick  wrote:
>>>
 Hi,

 I wrote most of the code for collation support, and I also argued
 (softly) against deprecating citext support for the reasons you stated.

 However, I've changed my mind on this now. As you can't index the
 citext column for LIKE queries, doing these types of searches on any real
 amount of data is going to be too slow in most cases. I actually think the
 best practice right now for having searchable case-insensitive emails is to
 do it old-school - have a regular EmailField with an index on
 UPPER("email") and then make sure you always use iexact, istartswith etc.
 and this will properly use the indexes and result in a faster search.

 So I see very few advantages now to keeping CITEXT at all, and they're
 quite easy to add as a third party package as Mariusz suggested if anyone
 is so inclined.

 Cheers,
 Tom

 On Wed, 12 Apr 2023 at 12:09, Mariusz Felisiak 
 wrote:

> Hi
>
> > Unless we want to drop support for the CITEXT extension, ...
>
> What do you mean by that? As far as I'm now, we don't do anything
> special to support CITEXT extension 樂.
>
> > I'd caution to revert the deprecation and keep support ...
>
> I'm obviously biased as the author of this proposition and patch,
> however, IMO, small differences between using CI fields and collations
> don't justify maintaining 3 additional fields that were mostly untested.
> Also, they are deprecated in a LTS so folks still have *3* more years
> to update their code. In the worst case someone can create 3rd party
> package with them.
>
> Unless something is fundamentally broken I'm against reverting.
>
> 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-develop...@googlegroups.com.
> To view this discussion on the web visit
> 

Re: Can we move the activity on this list to the Forum now?

[Carlton Gibson]

Hey Curtis.

The notifications settings are very flexible, and allow good filtering (to
your inbox) if that's how you want them.

For example, I'm able to get notifications for the Django Internals
category, and the Async subcategory of Using Django (and then I'm able to
keep up with the rest just by glancing at the latest tab.)

The water is nice  
C.


On Thu, 4 May 2023 at 07:29, Curtis Maloney  wrote:

> Does the Forum allow me to get email notifications / summaries?
>
> If not, it will mean I disconnect with that part of the community.
>
> --
> Curtis
>
> On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:
>
> Yes please!
>
>
>
> On May 3, 2023 at 11:19:12 PM, jure.erznoz...@gmail.com (
> jure.erznoz...@gmail.com) wrote:
>
>
> +1
>
>
>
> *From:* django-developers@googlegroups.com <
> django-developers@googlegroups.com> *On Behalf Of *natali...@gmail.com
> *Sent:* sreda, 03. maj 2023 20:10
> *To:* Django developers (Contributions to Django itself) <
> django-developers@googlegroups.com>
> *Subject:* Re: Can we move the activity on this list to the Forum now?
>
>
>
> Hello everyone!
>
>
>
> I was wondering if we could make a decision about this topic. On the one
> hand, and as far as I understand, the forum is the preferred channel of
> communication. On the other hand, having multiple channels of communication
> can spread important discussions too thin, making it difficult to have
> productive conversations in one place.
>
>
>
> As a newcomer to the contributing community, I can attest that the current
> situation causes some confusion. IMHO, the same applies to the chat
> options: there is IRC and the Discord server (though perhaps I should start
> a new forum topic about that in order to keep decisions separated).
>
>
>
> In summary, I'm +1 to "move on-mass (all few of us :) over there"!
>
>
>
> Thank you!
>
> Natalia.
>
> On Thursday, January 26, 2023 at 10:07:36 AM UTC-3 Alex Krupp wrote:
>
> I just submitted a proposal to create a Discourse plugin to improve the
> accuracy of their inbound email parsing. This would enable two things:
>
>- Folks who prefer to live in their inbox could continue to do so and
>contribute by just replying to emails. Discourse currently has
>reply-by-email, but it often mangles formatting and/or entirely deletes
>text. Once these issues are fixed, folks who like the current experience
>would be able to just pretend the forum doesn't exist and continue having
>the same experience as they currently have with Google Groups.
>- Right now importing the archives from Google Groups into Discourse
>isn't realistic for the same reasons; some messages will import correctly,
>but others will be mangled or missing text. This would also be made
>possible.
>
> If this is something you care about (positively or negatively), here is
> the exploratory proposal:
>
>
>
>
> https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944
>
>
>
> Any feedback and/or testing would be much appreciated! Right now Discourse
> recognizes that this is a problem and is interested in solving it, but
> getting it prioritized will require folks to A) speak up saying they want
> it done B) test the underlying API to verify that it actually solves the
> problem.
>
>
>
> Alex
>
>
>
> On Fri, Jan 20, 2023 at 2:24 AM Carlton Gibson 
> wrote:
>
> OK, I've updated the Trac wiki page to point to the forum too. (We use
> this as a wiki-link in responses to guide folk onwards.)
>
>
>
> The docs have a `|django-developers|` shortcut used in quite a few places
> so that needs a moment more to review and adjust.
>
> (I'll look at it soon-ish... — if no-one beats me to it :)
>
>
>
> Thanks.
>
> C
>
>
>
> On Thu, 19 Jan 2023 at 18:15, Andrew Godwin  wrote:
>
> We should at least update those Trac and Triage Workflow docs to point to
> both, maybe with the Forum first?
>
>
>
> Andrew
>
>
>
> On Thu, Jan 19, 2023, at 12:30 AM, Carlton Gibson wrote:
>
> I'm trying to begin new conversations there where I can.
>
>
>
> The main issue is that we're still pointing people here from Trac and the
> Triage Workflow docs — so if there's a rough "Yeah, let's do it" we can
> adjust practice there.
>
>
>
> I expect there will always be the "How do I start?" posts. The Forum at
> least has a pinned post for that. ...
>
>
>
> On Thu, 19 Jan 2023 at 01:04, 'Kye Russell' via Django developers
> (Contributions to Django itself)  wrote:
>
> Hi all,
>
>
>
> I find that the sig

Re: Drop CSRF middleware from the settings template

['Ryan Hiebert' via Django developers (Contributions to Django itself)]

I've been working on setting up a new project that's never going to see the 
light of production, so I went down the road of just disabling CSRF for 
that purpose. I notably found that the Django admin still requires CSRF, 
even when the middleware has been removed from the MIDDLEWARE setting. I 
found this because the development environment I was working in, 
Codespaces, forwards and redirects to a browser via a public address rather 
than localhost, and that difference means that CSRF checks were enforced in 
that environment, though I had no trouble with localhost. There's likely 
some details I'm missing in laying out this scenario, but it felt 
interesting enough to mention in the context of this conversation.

-- 
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/72019908-a072-45fc-bd55-3dbf675711cdn%40googlegroups.com.

Re: Can we move the activity on this list to the Forum now?

[Ken Whitesell]

Hi Tim,

I'm one of the Moderators of the forum, and yes, I am actively working 
on cleaning up the categorization of the messages. (It's a slow grind, 
but I'm making gradual-but-reasonably-steady progress.) I do try to stay 
on top of new messages - but I'm also going back through existing messages.


Admittedly, I've been most focused on cleaning up the "Using Django" 
dumping ground. However, if there's any request for me to change my 
focus for a bit to get the Internals category cleaned up, I'd be more 
than happy to oblige.


Ken Whitesell

On 5/4/2023 11:02 AM, Tim Graham wrote:

I agree with Carsten. I find the groups.google.com web interface much 
easier to follow and to quickly scan and see which threads I've read 
and which have new activity. I follow this mailing list more closely 
than the forum and prefer writing to it.


Incidentally, when I look at the "Django Internals" category of the 
forum, I see a lot of inappropriate usage questions that get answered 
there rather than pointed to the correct category. Is there a way to 
recategorize those posts?


On Thursday, May 4, 2023 at 2:09:35 AM UTC-4 Carsten Fuchs wrote:

Hello,

unfortunately, the subject lines of the emails sent by the forum
have the forum category prepended. These prefixes are long and
make it difficult to parse a large number of emails quickly, which
significantly reduces one of the main strengths of mail(ing-list)s.

To be honest, I'm surprised that not more mailing list members
argue in favor of the mailing list.

The mailing list makes it easy to read or at least glance at every
single message, if desired, while enabling readers to skip
uninteresting threads quickly. This is a lot more difficult on the
forum, especially with the user interface as implemented by
Discourse, which wastes a lot of white space (lines with much
vertical spacing, as with the topic lines on the Latest page, are
difficult to parse quickly) und whose „last visit“ line is
unreliable, especially if you read the forum on multiple devices
(home, office, mobile, …) with possibly several tabs open at the
same time.

I'm aware that I'm in a minority and that there is no way to
convince the relevant people to keep the mailing-lists, but in my
opinion the switch the forum is a step backwards in accessibility,
usability and easy of use.

Best regards,
Carsten

Am 04.05.23 um 07:49 schrieb Jure Erznožnik:


This has been answered affirmatively in this very thread before.

The forum even has a "Mailing list mode" in addition to several
other mailing options (including a nifty "activity summary").

LP,
Jure

On 4. 05. 23 07:28, Curtis Maloney wrote:

Does the Forum allow me to get email notifications / summaries?

If not, it will mean I disconnect with that part of the community.

--
Curtis

On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:

Yes please!



On May 3, 2023 at 11:19:12 PM, jure.er...@gmail.com
(jure.er...@gmail.com) wrote:



+1


*From:*django-d...@googlegroups.com
 *On Behalf Of *natali...@gmail.com
*Sent:* sreda, 03. maj 2023 20:10
*To:* Django developers (Contributions to Django itself)

*Subject:* Re: Can we move the activity on this list to the
Forum now?


Hello everyone!


I was wondering if we could make a decision about this topic.
On the one hand, and as far as I understand, the forum is the
preferred channel of communication. On the other hand, having
multiple channels of communication can spread important
discussions too thin, making it difficult to have productive
conversations in one place.


As a newcomer to the contributing community, I can attest that
the current situation causes some confusion. IMHO, the same
applies to the chat options: there is IRC and the Discord
server (though perhaps I should start a new forum topic about
that in order to keep decisions separated).


In summary, I'm +1 to "move on-mass (all few of us :) over there"!


Thank you!

Natalia.



--
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/2c6cf8cc-91f5-48d9-a3a9-337fff1f3439n%40googlegroups.com 
<https://groups.google.com/d/msgid/django-developers/2c6cf8cc-91f5-48d9-a3a9-337fff1f3439n%40googlegroups.com?utm_medium=email_source=footer>.


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

Re: Can we move the activity on this list to the Forum now?

[Tim Graham]

I agree with Carsten. I find the groups.google.com web interface much 
easier to follow and to quickly scan and see which threads I've read and 
which have new activity. I follow this mailing list more closely than the 
forum and prefer writing to it.

Incidentally, when I look at the "Django Internals" category of the forum, 
I see a lot of inappropriate usage questions that get answered there rather 
than pointed to the correct category. Is there a way to recategorize those 
posts?

On Thursday, May 4, 2023 at 2:09:35 AM UTC-4 Carsten Fuchs wrote:

> Hello,
>
> unfortunately, the subject lines of the emails sent by the forum have the 
> forum category prepended. These prefixes are long and make it difficult to 
> parse a large number of emails quickly, which significantly reduces one of 
> the main strengths of mail(ing-list)s.
>
> To be honest, I'm surprised that not more mailing list members argue in 
> favor of the mailing list. 
>
> The mailing list makes it easy to read or at least glance at every single 
> message, if desired, while enabling readers to skip uninteresting threads 
> quickly. This is a lot more difficult on the forum, especially with the 
> user interface as implemented by Discourse, which wastes a lot of white 
> space (lines with much vertical spacing, as with the topic lines on the 
> Latest page, are difficult to parse quickly) und whose „last visit“ line is 
> unreliable, especially if you read the forum on multiple devices (home, 
> office, mobile, …) with possibly several tabs open at the same time.
>
> I'm aware that I'm in a minority and that there is no way to convince the 
> relevant people to keep the mailing-lists, but in my opinion the switch the 
> forum is a step backwards in accessibility, usability and easy of use.
>
> Best regards,
> Carsten
>
> Am 04.05.23 um 07:49 schrieb Jure Erznožnik:
>
> This has been answered affirmatively in this very thread before. 
>
> The forum even has a "Mailing list mode" in addition to several other 
> mailing options (including a nifty "activity summary").
>
> LP,
> Jure
> On 4. 05. 23 07:28, Curtis Maloney wrote:
>
> Does the Forum allow me to get email notifications / summaries?
>
> If not, it will mean I disconnect with that part of the community.
>
> --
> Curtis
>
> On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:
>
> Yes please!
>
>
>
> On May 3, 2023 at 11:19:12 PM, jure.er...@gmail.com (jure.er...@gmail.com) 
> wrote:
>
>
> +1
>
>  
>
> *From:* django-d...@googlegroups.com  *On 
> Behalf Of *natali...@gmail.com
> *Sent:* sreda, 03. maj 2023 20:10
> *To:* Django developers (Contributions to Django itself) <
> django-d...@googlegroups.com>
> *Subject:* Re: Can we move the activity on this list to the Forum now?
>
>  
>
> Hello everyone!
>
>  
>
> I was wondering if we could make a decision about this topic. On the one 
> hand, and as far as I understand, the forum is the preferred channel of 
> communication. On the other hand, having multiple channels of communication 
> can spread important discussions too thin, making it difficult to have 
> productive conversations in one place.
>
>  
>
> As a newcomer to the contributing community, I can attest that the current 
> situation causes some confusion. IMHO, the same applies to the chat 
> options: there is IRC and the Discord server (though perhaps I should start 
> a new forum topic about that in order to keep decisions separated).
>
>  
>
> In summary, I'm +1 to "move on-mass (all few of us :) over there"!
>
>  
>
> Thank you!
>
> Natalia.
>
>
>

-- 
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/2c6cf8cc-91f5-48d9-a3a9-337fff1f3439n%40googlegroups.com.

Re: Can we move the activity on this list to the Forum now?

[Carsten Fuchs]

Hello,

unfortunately, the subject lines of the emails sent by the forum have the forum 
category prepended. These prefixes are long and make it difficult to parse a 
large number of emails quickly, which significantly reduces one of the main 
strengths of mail(ing-list)s.

To be honest, I'm surprised that not more mailing list members argue in favor 
of the mailing list.

The mailing list makes it easy to read or at least glance at every single 
message, if desired, while enabling readers to skip uninteresting threads 
quickly. This is a lot more difficult on the forum, especially with the user 
interface as implemented by Discourse, which wastes a lot of white space (lines 
with much vertical spacing, as with the topic lines on the Latest page, are 
difficult to parse quickly) und whose „last visit“ line is unreliable, 
especially if you read the forum on multiple devices (home, office, mobile, …) 
with possibly several tabs open at the same time.

I'm aware that I'm in a minority and that there is no way to convince the 
relevant people to keep the mailing-lists, but in my opinion the switch the 
forum is a step backwards in accessibility, usability and easy of use.

Best regards,
Carsten

Am 04.05.23 um 07:49 schrieb Jure Erznožnik:
>
> This has been answered affirmatively in this very thread before.
>
> The forum even has a "Mailing list mode" in addition to several other mailing 
> options (including a nifty "activity summary").
>
> LP,
> Jure
>
> On 4. 05. 23 07:28, Curtis Maloney wrote:
>> Does the Forum allow me to get email notifications / summaries?
>>
>> If not, it will mean I disconnect with that part of the community.
>>
>> --
>> Curtis
>>
>> On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:
>>> Yes please!
>>>
>>>
>>>
>>> On May 3, 2023 at 11:19:12 PM, jure.erznoz...@gmail.com 
>>> (jure.erznoz...@gmail.com) wrote:
>>>
>>>>
>>>> +1
>>>>
>>>>  
>>>>
>>>> *From:*django-developers@googlegroups.com 
>>>>  *On Behalf Of *natali...@gmail.com
>>>> *Sent:* sreda, 03. maj 2023 20:10
>>>> *To:* Django developers (Contributions to Django itself) 
>>>> 
>>>> *Subject:* Re: Can we move the activity on this list to the Forum now?
>>>>
>>>>  
>>>>
>>>> Hello everyone!
>>>>
>>>>  
>>>>
>>>> I was wondering if we could make a decision about this topic. On the one 
>>>> hand, and as far as I understand, the forum is the preferred channel of 
>>>> communication. On the other hand, having multiple channels of 
>>>> communication can spread important discussions too thin, making it 
>>>> difficult to have productive conversations in one place.
>>>>
>>>>  
>>>>
>>>> As a newcomer to the contributing community, I can attest that the current 
>>>> situation causes some confusion. IMHO, the same applies to the chat 
>>>> options: there is IRC and the Discord server (though perhaps I should 
>>>> start a new forum topic about that in order to keep decisions separated).
>>>>
>>>>  
>>>>
>>>> In summary, I'm +1 to "move on-mass (all few of us :) over there"!
>>>>
>>>>  
>>>>
>>>> Thank you!
>>>>
>>>> Natalia.
>>>>

-- 
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/ecfbf957-a2a6-4054-cc0e-a6274fa3c74e%40cafu.de.

Re: Can we move the activity on this list to the Forum now?

[Jure Erznožnik]

This has been answered affirmatively in this very thread before.

The forum even has a "Mailing list mode" in addition to several other 
mailing options (including a nifty "activity summary").


LP,
Jure

On 4. 05. 23 07:28, Curtis Maloney wrote:

Does the Forum allow me to get email notifications / summaries?

If not, it will mean I disconnect with that part of the community.

--
Curtis

On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:

Yes please!



On May 3, 2023 at 11:19:12 PM, jure.erznoz...@gmail.com 
(jure.erznoz...@gmail.com) wrote:




+1


*From:*django-developers@googlegroups.com 
 *On Behalf Of *natali...@gmail.com

*Sent:* sreda, 03. maj 2023 20:10
*To:* Django developers (Contributions to Django itself) 


*Subject:* Re: Can we move the activity on this list to the Forum now?


Hello everyone!


I was wondering if we could make a decision about this topic. On the 
one hand, and as far as I understand, the forum is the preferred 
channel of communication. On the other hand, having multiple 
channels of communication can spread important discussions too thin, 
making it difficult to have productive conversations in one place.



As a newcomer to the contributing community, I can attest that the 
current situation causes some confusion. IMHO, the same applies to 
the chat options: there is IRC and the Discord server (though 
perhaps I should start a new forum topic about that in order to keep 
decisions separated).



In summary, I'm +1 to "move on-mass (all few of us :) over there"!


Thank you!

Natalia.

On Thursday, January 26, 2023 at 10:07:36 AM UTC-3 Alex Krupp wrote:

I just submitted a proposal to create a Discourse plugin to
improve the accuracy of their inbound email parsing. This would
enable two things:

  * Folks who prefer to live in their inbox could continue to do
so and contribute by just replying to emails. Discourse
currently has reply-by-email, but it often mangles
formatting and/or entirely deletes text. Once these issues
are fixed, folks who like the current experience would be
able to just pretend the forum doesn't exist and continue
having the same experience as they currently have with
Google Groups.
  * Right now importing the archives from Google Groups into
Discourse isn't realistic for the same reasons; some
messages will import correctly, but others will be mangled
or missing text. This would also be made possible.

If this is something you care about (positively or negatively),
here is the exploratory proposal:



https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944


Any feedback and/or testing would be much appreciated! Right now
Discourse recognizes that this is a problem and is interested in
solving it, but getting it prioritized will require folks to A)
speak up saying they want it done B) test the underlying API to
verify that it actually solves the problem.


Alex


On Fri, Jan 20, 2023 at 2:24 AM Carlton Gibson
 wrote:

OK, I've updated the Trac wiki page to point to the forum
too. (We use this as a wiki-link in responses to guide folk
onwards.)


The docs have a `|django-developers|` shortcut used in quite
a few places so that needs a moment more to review and adjust.

(I'll look at it soon-ish... — if no-one beats me to it :)


Thanks.

C


On Thu, 19 Jan 2023 at 18:15, Andrew Godwin
 wrote:

We should at least update those Trac and Triage Workflow
docs to point to both, maybe with the Forum first?


Andrew


On Thu, Jan 19, 2023, at 12:30 AM, Carlton Gibson wrote:

I'm trying to begin new conversations there where I
can.


The main issue is that we're still pointing people
here from Trac and the Triage Workflow docs — so if
there's a rough "Yeah, let's do it" we can adjust
practice there.


I expect there will always be the "How do I start?"
posts. The Forum at least has a pinned post for
that. ...


On Thu, 19 Jan 2023 at 01:04, 'Kye Russell' via
Django developers (Contributions to Django itself)
 wrote:

Hi all,


I find that the signal-to-noise ratio on this
mailing list is (by my determination) quite bad
around this time of year.


Is a move to the forum still on the cards?


Kye

On 6 Dec 2022 at 7:16 AM +0800, Andrew Godwin
, wrote:


I did some investigation of moving
django-users and django-developer

Re: Can we move the activity on this list to the Forum now?

[Curtis Maloney]

Does the Forum allow me to get email notifications / summaries?

If not, it will mean I disconnect with that part of the community.

--
Curtis

On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:
> Yes please!
> 
> 
> 
> On May 3, 2023 at 11:19:12 PM, jure.erznoz...@gmail.com 
> (jure.erznoz...@gmail.com) wrote:
> 
>> 
>> +1
>>  
>> *From:* django-developers@googlegroups.com 
>>  *On Behalf Of *natali...@gmail.com
>> *Sent:* sreda, 03. maj 2023 20:10
>> *To:* Django developers (Contributions to Django itself) 
>> 
>> *Subject:* Re: Can we move the activity on this list to the Forum now?
>>  
>> Hello everyone!
>>  
>> I was wondering if we could make a decision about this topic. On the one 
>> hand, and as far as I understand, the forum is the preferred channel of 
>> communication. On the other hand, having multiple channels of communication 
>> can spread important discussions too thin, making it difficult to have 
>> productive conversations in one place.
>>  
>> As a newcomer to the contributing community, I can attest that the current 
>> situation causes some confusion. IMHO, the same applies to the chat options: 
>> there is IRC and the Discord server (though perhaps I should start a new 
>> forum topic about that in order to keep decisions separated).
>>  
>> In summary, I'm +1 to "move on-mass (all few of us :) over there"!
>>  
>> Thank you!
>> Natalia.
>> On Thursday, January 26, 2023 at 10:07:36 AM UTC-3 Alex Krupp wrote:
>>> I just submitted a proposal to create a Discourse plugin to improve the 
>>> accuracy of their inbound email parsing. This would enable two things:
>>>  • Folks who prefer to live in their inbox could continue to do so and 
>>> contribute by just replying to emails. Discourse currently has 
>>> reply-by-email, but it often mangles formatting and/or entirely deletes 
>>> text. Once these issues are fixed, folks who like the current experience 
>>> would be able to just pretend the forum doesn't exist and continue having 
>>> the same experience as they currently have with Google Groups.
>>>  • Right now importing the archives from Google Groups into Discourse isn't 
>>> realistic for the same reasons; some messages will import correctly, but 
>>> others will be mangled or missing text. This would also be made possible.
>>> If this is something you care about (positively or negatively), here is the 
>>> exploratory proposal:
>>>  
>>> https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944
>>>  
>>> Any feedback and/or testing would be much appreciated! Right now Discourse 
>>> recognizes that this is a problem and is interested in solving it, but 
>>> getting it prioritized will require folks to A) speak up saying they want 
>>> it done B) test the underlying API to verify that it actually solves the 
>>> problem.
>>>  
>>> Alex
>>>  
>>> On Fri, Jan 20, 2023 at 2:24 AM Carlton Gibson  wrote:
>>>> OK, I've updated the Trac wiki page to point to the forum too. (We use 
>>>> this as a wiki-link in responses to guide folk onwards.) 
>>>>  
>>>> The docs have a `|django-developers|` shortcut used in quite a few places 
>>>> so that needs a moment more to review and adjust. 
>>>> (I'll look at it soon-ish... — if no-one beats me to it :) 
>>>>  
>>>> Thanks. 
>>>> C
>>>>  
>>>> On Thu, 19 Jan 2023 at 18:15, Andrew Godwin  wrote:
>>>>> We should at least update those Trac and Triage Workflow docs to point to 
>>>>> both, maybe with the Forum first?
>>>>>  
>>>>> Andrew
>>>>>  
>>>>> On Thu, Jan 19, 2023, at 12:30 AM, Carlton Gibson wrote:
>>>>>> I'm trying to begin new conversations there where I can. 
>>>>>>  
>>>>>> The main issue is that we're still pointing people here from Trac and 
>>>>>> the Triage Workflow docs — so if there's a rough "Yeah, let's do it" we 
>>>>>> can adjust practice there. 
>>>>>>  
>>>>>> I expect there will always be the "How do I start?" posts. The Forum at 
>>>>>> least has a pinned post for that. ... 
>>>>>>  
>>>>>> On Thu, 19 Jan 2023 at 01:04, 'Kye Russell' via Django developers 
>>>>>> (Contributions to Django itself)  wrote:
>>>>>>> Hi all,
&

RE: Can we move the activity on this list to the Forum now?

[Arthur Rio]

Yes please!


On May 3, 2023 at 11:19:12 PM, jure.erznoz...@gmail.com (
jure.erznoz...@gmail.com) wrote:

+1



*From:* django-developers@googlegroups.com <
django-developers@googlegroups.com> *On Behalf Of *natali...@gmail.com
*Sent:* sreda, 03. maj 2023 20:10
*To:* Django developers (Contributions to Django itself) <
django-developers@googlegroups.com>
*Subject:* Re: Can we move the activity on this list to the Forum now?



Hello everyone!



I was wondering if we could make a decision about this topic. On the one
hand, and as far as I understand, the forum is the preferred channel of
communication. On the other hand, having multiple channels of communication
can spread important discussions too thin, making it difficult to have
productive conversations in one place.



As a newcomer to the contributing community, I can attest that the current
situation causes some confusion. IMHO, the same applies to the chat
options: there is IRC and the Discord server (though perhaps I should start
a new forum topic about that in order to keep decisions separated).



In summary, I'm +1 to "move on-mass (all few of us :) over there"!



Thank you!

Natalia.

On Thursday, January 26, 2023 at 10:07:36 AM UTC-3 Alex Krupp wrote:

I just submitted a proposal to create a Discourse plugin to improve the
accuracy of their inbound email parsing. This would enable two things:

   - Folks who prefer to live in their inbox could continue to do so and
   contribute by just replying to emails. Discourse currently has
   reply-by-email, but it often mangles formatting and/or entirely deletes
   text. Once these issues are fixed, folks who like the current experience
   would be able to just pretend the forum doesn't exist and continue having
   the same experience as they currently have with Google Groups.
   - Right now importing the archives from Google Groups into Discourse
   isn't realistic for the same reasons; some messages will import correctly,
   but others will be mangled or missing text. This would also be made
   possible.

If this is something you care about (positively or negatively), here is the
exploratory proposal:



https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944



Any feedback and/or testing would be much appreciated! Right now Discourse
recognizes that this is a problem and is interested in solving it, but
getting it prioritized will require folks to A) speak up saying they want
it done B) test the underlying API to verify that it actually solves the
problem.



Alex



On Fri, Jan 20, 2023 at 2:24 AM Carlton Gibson  wrote:

OK, I've updated the Trac wiki page to point to the forum too. (We use this
as a wiki-link in responses to guide folk onwards.)



The docs have a `|django-developers|` shortcut used in quite a few places
so that needs a moment more to review and adjust.

(I'll look at it soon-ish... — if no-one beats me to it :)



Thanks.

C



On Thu, 19 Jan 2023 at 18:15, Andrew Godwin  wrote:

We should at least update those Trac and Triage Workflow docs to point to
both, maybe with the Forum first?



Andrew



On Thu, Jan 19, 2023, at 12:30 AM, Carlton Gibson wrote:

I'm trying to begin new conversations there where I can.



The main issue is that we're still pointing people here from Trac and the
Triage Workflow docs — so if there's a rough "Yeah, let's do it" we can
adjust practice there.



I expect there will always be the "How do I start?" posts. The Forum at
least has a pinned post for that. ...



On Thu, 19 Jan 2023 at 01:04, 'Kye Russell' via Django developers
(Contributions to Django itself)  wrote:

Hi all,



I find that the signal-to-noise ratio on this mailing list is (by my
determination) quite bad around this time of year.



Is a move to the forum still on the cards?



Kye

On 6 Dec 2022 at 7:16 AM +0800, Andrew Godwin , wrote:



I did some investigation of moving django-users and django-developers to
the Forum right after DjangoCon; I wanted to see if we could import all the
old posts too, which we probably could, but I'm not entirely sure of the
utility of that.



I will say that the forum is a lot easier to moderate - the ability to
moderate after a post has gone out, rather than gating all posts behind
approval if they're untrusted, is a big step in itself, not to mention the
ability to remove sensitive or offensive content once it's posted.



Andrew



On Monday, November 28, 2022 at 10:01:17 PM UTC-7 m...@kye.id.au wrote:

IMO django-announce and django-updates serve a very different purpose and I
would be against moving them if it were suggested.



I am incredibly strongly in favour of moving django-developers and
django-users to the forums. IMO being able to more easily trap people
misusing this list as a tech support channel is itself reason enough to
move. Beyond that, I’d argue that the plentiful UX issues with Google
Groups, and mailing lists in general, certainly don’t do the comm

RE: Can we move the activity on this list to the Forum now?

[jure.erznoznik]

+1

 

From: django-developers@googlegroups.com  
On Behalf Of natali...@gmail.com
Sent: sreda, 03. maj 2023 20:10
To: Django developers (Contributions to Django itself) 

Subject: Re: Can we move the activity on this list to the Forum now?

 

Hello everyone!

 

I was wondering if we could make a decision about this topic. On the one hand, 
and as far as I understand, the forum is the preferred channel of 
communication. On the other hand, having multiple channels of communication can 
spread important discussions too thin, making it difficult to have productive 
conversations in one place.

 

As a newcomer to the contributing community, I can attest that the current 
situation causes some confusion. IMHO, the same applies to the chat options: 
there is IRC and the Discord server (though perhaps I should start a new forum 
topic about that in order to keep decisions separated).

 

In summary, I'm +1 to "move on-mass (all few of us :) over there"!

 

Thank you!

Natalia.

On Thursday, January 26, 2023 at 10:07:36 AM UTC-3 Alex Krupp wrote:

I just submitted a proposal to create a Discourse plugin to improve the 
accuracy of their inbound email parsing. This would enable two things:

*   Folks who prefer to live in their inbox could continue to do so and 
contribute by just replying to emails. Discourse currently has reply-by-email, 
but it often mangles formatting and/or entirely deletes text. Once these issues 
are fixed, folks who like the current experience would be able to just pretend 
the forum doesn't exist and continue having the same experience as they 
currently have with Google Groups.
*   Right now importing the archives from Google Groups into Discourse 
isn't realistic for the same reasons; some messages will import correctly, but 
others will be mangled or missing text. This would also be made possible.

If this is something you care about (positively or negatively), here is the 
exploratory proposal:

 

https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944


 

Any feedback and/or testing would be much appreciated! Right now Discourse 
recognizes that this is a problem and is interested in solving it, but getting 
it prioritized will require folks to A) speak up saying they want it done B) 
test the underlying API to verify that it actually solves the problem.

 

Alex

 

On Fri, Jan 20, 2023 at 2:24 AM Carlton Gibson mailto:carlton...@gmail.com> > wrote:

OK, I've updated the Trac wiki page to point to the forum too. (We use this as 
a wiki-link in responses to guide folk onwards.) 

 

The docs have a `|django-developers|` shortcut used in quite a few places so 
that needs a moment more to review and adjust. 

(I'll look at it soon-ish... — if no-one beats me to it :) 

 

Thanks. 

C

 

On Thu, 19 Jan 2023 at 18:15, Andrew Godwin mailto:and...@aeracode.org> > wrote:

We should at least update those Trac and Triage Workflow docs to point to both, 
maybe with the Forum first?

 

Andrew

 

On Thu, Jan 19, 2023, at 12:30 AM, Carlton Gibson wrote:

I'm trying to begin new conversations there where I can. 

 

The main issue is that we're still pointing people here from Trac and the 
Triage Workflow docs — so if there's a rough "Yeah, let's do it" we can adjust 
practice there. 

 

I expect there will always be the "How do I start?" posts. The Forum at least 
has a pinned post for that. ... 

 

On Thu, 19 Jan 2023 at 01:04, 'Kye Russell' via Django developers 
(Contributions to Django itself) mailto:django-d...@googlegroups.com> > wrote:

Hi all,

 

I find that the signal-to-noise ratio on this mailing list is (by my 
determination) quite bad around this time of year.

 

Is a move to the forum still on the cards? 

 

Kye

On 6 Dec 2022 at 7:16 AM +0800, Andrew Godwin mailto:and...@aeracode.org> >, wrote:

 

I did some investigation of moving django-users and django-developers to the 
Forum right after DjangoCon; I wanted to see if we could import all the old 
posts too, which we probably could, but I'm not entirely sure of the utility of 
that. 

 

I will say that the forum is a lot easier to moderate - the ability to moderate 
after a post has gone out, rather than gating all posts behind approval if 
they're untrusted, is a big step in itself, not to mention the ability to 
remove sensitive or offensive content once it's posted.

 

Andrew

 

On Monday, November 28, 2022 at 10:01:17 PM UTC-7 m...@kye.id.au 
<mailto:m...@kye.id.au>  wrote:

IMO django-announce and django-updates serve a very different purpose and I 
would be against moving them if it were suggested.

 

I am incredibly strongly in favour of moving django-developers and django-users 
to the forums. IMO being able to more easily trap people misusing this list as 
a tech support channel is itself reason enough to move. Beyond that, I’d argue 
that the plentiful UX issues with Google Groups, and mailing lis

Re: Can we move the activity on this list to the Forum now?

[natali...@gmail.com]

Hello everyone!

I was wondering if we could make a decision about this topic. On the one 
hand, and as far as I understand, the forum is the preferred channel of 
communication. On the other hand, having multiple channels of communication 
can spread important discussions too thin, making it difficult to have 
productive conversations in one place.

As a newcomer to the contributing community, I can attest that the current 
situation causes some confusion. IMHO, the same applies to the chat 
options: there is IRC and the Discord server (though perhaps I should start 
a new forum topic about that in order to keep decisions separated).

In summary, I'm +1 to "move on-mass (all few of us :) over there"!

Thank you!
Natalia.

On Thursday, January 26, 2023 at 10:07:36 AM UTC-3 Alex Krupp wrote:

> I just submitted a proposal to create a Discourse plugin to improve the 
> accuracy of their inbound email parsing. This would enable two things:
>
>- Folks who prefer to live in their inbox could continue to do so and 
>contribute by just replying to emails. Discourse currently has 
>reply-by-email, but it often mangles formatting and/or entirely deletes 
>text. Once these issues are fixed, folks who like the current experience 
>would be able to just pretend the forum doesn't exist and continue having 
>the same experience as they currently have with Google Groups.
>- Right now importing the archives from Google Groups into Discourse 
>isn't realistic for the same reasons; some messages will import correctly, 
>but others will be mangled or missing text. This would also be made 
>possible.
>
> If this is something you care about (positively or negatively), here is 
> the exploratory proposal:
>
>
> https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944
>
> Any feedback and/or testing would be much appreciated! Right now Discourse 
> recognizes that this is a problem and is interested in solving it, but 
> getting it prioritized will require folks to A) speak up saying they want 
> it done B) test the underlying API to verify that it actually solves the 
> problem.
>
> Alex
>
> On Fri, Jan 20, 2023 at 2:24 AM Carlton Gibson  
> wrote:
>
>> OK, I've updated the Trac wiki page to point to the forum too. (We use 
>> this as a wiki-link in responses to guide folk onwards.) 
>>
>> The docs have a `|django-developers|` shortcut used in quite a few places 
>> so that needs a moment more to review and adjust. 
>> (I'll look at it soon-ish... — if no-one beats me to it :) 
>>
>> Thanks. 
>> C
>>
>> On Thu, 19 Jan 2023 at 18:15, Andrew Godwin  wrote:
>>
>>> We should at least update those Trac and Triage Workflow docs to point 
>>> to both, maybe with the Forum first?
>>>
>>> Andrew
>>>
>>> On Thu, Jan 19, 2023, at 12:30 AM, Carlton Gibson wrote:
>>>
>>> I'm trying to begin new conversations there where I can. 
>>>
>>> The main issue is that we're still pointing people here from Trac and 
>>> the Triage Workflow docs — so if there's a rough "Yeah, let's do it" we can 
>>> adjust practice there. 
>>>
>>> I expect there will always be the "How do I start?" posts. The Forum at 
>>> least has a pinned post for that. ... 
>>>
>>> On Thu, 19 Jan 2023 at 01:04, 'Kye Russell' via Django developers 
>>> (Contributions to Django itself)  wrote:
>>>
>>> Hi all,
>>>
>>> I find that the signal-to-noise ratio on this mailing list is (by my 
>>> determination) quite bad around this time of year.
>>>
>>> Is a move to the forum still on the cards? 
>>>
>>> Kye
>>> On 6 Dec 2022 at 7:16 AM +0800, Andrew Godwin , 
>>> wrote:
>>>
>>> I did some investigation of moving django-users and django-developers to 
>>> the Forum right after DjangoCon; I wanted to see if we could import all the 
>>> old posts too, which we probably could, but I'm not entirely sure of the 
>>> utility of that. 
>>>
>>> I will say that the forum is a lot easier to moderate - the ability to 
>>> moderate after a post has gone out, rather than gating all posts behind 
>>> approval if they're untrusted, is a big step in itself, not to mention the 
>>> ability to remove sensitive or offensive content once it's posted.
>>>
>>> Andrew
>>>
>>> On Monday, November 28, 2022 at 10:01:17 PM UTC-7 m...@kye.id.au wrote:
>>>
>>> IMO django-announce and django-updates serve a very different purpose 
>>> and I would be against moving them if it were suggested.
>>>
>>> I am incredibly strongly in favour of moving django-developers and 
>>> django-users to the forums. IMO being able to more easily trap people 
>>> misusing this list as a tech support channel is itself reason enough to 
>>> move. Beyond that, I’d argue that the plentiful UX issues with Google 
>>> Groups, and mailing lists in general, certainly don’t do the community any 
>>> favours in terms of getting more people on board. 
>>>
>>> Kye
>>>
>>> On 28 Nov 2022 at 11:40 PM +0800, 'Tobias McNulty' via Django developers 
>>> (Contributions to Django itself) 

Re: Fellow Reports - April 2023

[Natalia Bidart]

Week ending 2023-04-30 (Week 18)

Triaged:
  https://code.djangoproject.com/ticket/34523 - update_or_create not work
in parallel insertion
  https://code.djangoproject.com/ticket/34520 - ModelAdmin.fields: wrapping
in tuples does not have any effect (each field on separate line) (invalid)
  https://code.djangoproject.com/ticket/34525 - index_together warning
after migration to new style (accepted)

Landed:
  https://github.com/django/django/pull/16757 - Fixed #34481 -- Added
checks for reverse related fields in admin's list_display
  https://github.com/django/django/pull/16808 - Restored multiprocessing
concurrency on coverage.py settings

Reviewed:
  https://github.com/django/django/pull/16777 - Fixed #12780 -- Added
compound form/formset validation in ModelAdmin
  https://github.com/django/django/pull/16798 - fix: correct 'decade'
computation
  https://github.com/django/django/pull/16797 - Fixed #34515 -- Updated to
redirect to request language when from translated default url.
  https://github.com/django/django/pull/16804 - Avoided creating default
form fields in fields_for_model() when declared on form.
  https://github.com/django/django/pull/16808 - Restored multiprocessing
concurrency on coverage.py settings #16808

PR Cleanup:
  https://github.com/django/django/pull/14499 - Improve accuracy of
NullBooleanField deprecation warning hint.
  https://github.com/django/django/pull/14408 - Fixed #32827 -- Adjusted
docs on squashing migrations.
  https://github.com/django/django/pull/14082 - docs/ref/databases:
rephrase persistent connections section
  https://github.com/django/django/pull/13169 - Add field_name to the
non-existing readonly_fields error
  https://github.com/django/django/pull/12712 - Fix #27060: Add indexes
identified in constraints to Meta.indexes

Other/Misc:
  Google Summer of Code final review and ranking.
  DjangoCon US travel preparation.
  Deep-dive in the translations framework to assist with the release
blocker https://code.djangoproject.com/ticket/34515

Cheers! Natalia.

On Mon, Apr 24, 2023 at 9:12 AM Natalia Bidart 
wrote:

> Week ending 2023-04-23 (Week 17)
>
> Triaged:
>   https://code.djangoproject.com/ticket/34506 - Visual regressions in
> admin's clearable file input. (accepted)
>   https://code.djangoproject.com/ticket/34507 - AttributeError: Can't
> pickle local object 'convert_exception_to_response..inner'
> (needsinfo)
>
> Reviewed:
>   https://github.com/django/django/pull/16771 - Added
> RemovedInDjangoXXWarning comments to the deprecating a feature docs.
>   https://github.com/django/django/pull/16784 - Added meaningful titles
> to ..admonition:: directives.
>   https://github.com/django/django/pull/16757 - Fixed #34481 -- Added
> checks for reverse related fields in admin's list_display
>   https://github.com/django/django/pull/16636/ - Fixed #34391 -- Added
> async interface to auth (lots of interesting things to read around this!)
>   https://github.com/django/django/pull/14257 - Made SimpleTestCase
> client attributes cached properties.
>
> PR Housekeeping:
>   https://github.com/django/django/pull/7161 - Fixed #25594 -- Propagated
> validators from model to form fields (closed)
>   https://github.com/django/django/pull/8435 - Optimized
> ModelAdmin.changelist_view if actions are not used (closed)
>   https://github.com/django/django/pull/8848 - Allowed (partial) indexes
> for text fields on MySQL (closed)
>   https://github.com/django/django/pull/10708 - Form field label i18n
> performances fixes (closed)
>   https://github.com/django/django/pull/10349 - Fixed #29717 -- Allowed
> tests to use an existing empty database. (closed)
>   https://github.com/django/django/pull/10951 - WIP #30149 -- Empty value
> selected check in Admin Filter prevents subclassing (closed)
>   https://github.com/django/django/pull/11291 - Fixed #30416 -- Restore
> terminal state when reloading. (asked for update)
>   https://github.com/django/django/pull/11981 - Fixed #23051 -- Raise
> exception on only() calls with reverse fields (asked for update)
>   https://github.com/django/django/pull/12090 - Fixed #29058 -- return
> geom type for GeoDjango fields when using Spatialite backend so that
> migrations don't fail. (asked for update)
>   https://github.com/django/django/pull/12274 - [WIP/RFC]
> DateField/TimeField: allow for editable=True with auto_now/auto_now_add
> (closed)
>   https://github.com/django/django/pull/13853 - Refs #21429 -- Added
> SimpleTestCase.assertLogRecords. (asked for update)
>   https://github.com/django/django/pull/12285 - URLValidator: clarify
> comment about maximum length of a host name. (resolved conflict and chasing
> down who can further comment about the change)
>
> Authored:
>   https://github.com/django/django/pull/16791 - Refs #34462 -- Fixed
> query anti-pattern when processing object deletion
>
> Other/Misc:
>   Google Summer of Code proposals review.
>
> On Mon, Apr 17, 2023 at 5:54 PM Natalia Bidart 
> wrote:
>
>> Week ending 2023-04-16 (Week 16)

Re: Issue in admin and sites

[Mohamed El-Kalioby]

Here it is

https://code.djangoproject.com/ticket/34526

On Tue, 2 May 2023, 18:32 אורי,  wrote:

> Can you link to the ticket?
> אורי
> u...@speedy.net
>
>
> On Tue, May 2, 2023 at 5:28 PM Mohamed El-Kalioby 
> wrote:
>
>> Hello everyone,
>>
>>
>> I’ve opened this issue on the issue tracker, and was asked to post here
>> for the sake of discussion.
>>
>> In SaaS product, we have set of organizations (customers), each
>> organization is working under its own subdomain under the SaaS domain, and
>> each is completely independent. Each organization will have a super user
>> who shall have access to the Django admin to edit their organization
>> objects. Currently, Django admin only shows the objects which belong to the
>> SITE_ID even with setting the default_manager to the current_site manager
>> and enabling the sites middleware.
>>
>> I think this behavior is misleading and Django admin shall support sites
>> app, so what do you think?
>>
>> Best regards
>> Mohamed ElKalioby
>>
>>> --
>> 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/CAFJxxNcteC-sA5%3Db1JCjMg4bAOgNsd%3DHrzwb152SjOhnZQRC4g%40mail.gmail.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/CABD5YeH34ivmtsf0Lm4WLkGcsRnL6GNDAKXZEJBMYhwdc-UudA%40mail.gmail.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/CAFJxxNeDDS5Pm43GPy8ogOM-Z%3Dd%3DiBF4vVYx6SWYZ%2B5rB0f5-g%40mail.gmail.com.

Re: Issue in admin and sites

[אורי]

Can you link to the ticket?
אורי
u...@speedy.net


On Tue, May 2, 2023 at 5:28 PM Mohamed El-Kalioby 
wrote:

> Hello everyone,
>
>
> I’ve opened this issue on the issue tracker, and was asked to post here
> for the sake of discussion.
>
> In SaaS product, we have set of organizations (customers), each
> organization is working under its own subdomain under the SaaS domain, and
> each is completely independent. Each organization will have a super user
> who shall have access to the Django admin to edit their organization
> objects. Currently, Django admin only shows the objects which belong to the
> SITE_ID even with setting the default_manager to the current_site manager
> and enabling the sites middleware.
>
> I think this behavior is misleading and Django admin shall support sites
> app, so what do you think?
>
> Best regards
> Mohamed ElKalioby
>
>> --
> 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/CAFJxxNcteC-sA5%3Db1JCjMg4bAOgNsd%3DHrzwb152SjOhnZQRC4g%40mail.gmail.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/CABD5YeH34ivmtsf0Lm4WLkGcsRnL6GNDAKXZEJBMYhwdc-UudA%40mail.gmail.com.

Re: Fellow Reports - April 2023

[Mariusz Felisiak]

Week ending April 30, 2023

*Triaged:*
https://code.djangoproject.com/ticket/34229 - "no such column" when 
combining FilteredRelation and multi-table inheritance models (accepted)
https://code.djangoproject.com/ticket/34515 - Translatable URL patterns 
raise 404 for non-English default language when 
prefix_default_language=False is used. (accepted)
https://code.djangoproject.com/ticket/34517 - ImageField unnecessarily 
adds a post_init signal handler to the model (accepted)
https://code.djangoproject.com/ticket/34518 - "random" template filter 
crashes on an empty list. (accepted)
https://code.djangoproject.com/ticket/34519 - Don't send content in 
responses to HEAD requests (duplicate)
https://code.djangoproject.com/ticket/34521 - Use __slots__ for 
template Node classes (accepted)
https://code.djangoproject.com/ticket/34522 - PUT/PATCH data is not 
encoded for multipart/form-data in Django Test Client (duplicate)
https://code.djangoproject.com/ticket/34524 - Error while sending TLS 
smtp email on "self-signed certificate" server (duplicate)
https://code.djangoproject.com/ticket/34523 - 
Model.objects.update_or_create method sometimes raises 
TransactionManagementError (accepted)
https://code.djangoproject.com/ticket/34527 - Unexpected behavior with 
division in aggregation (invalid)

*Reviewed/committed:*
https://github.com/django/django/pull/16786 - Fixed #33766 -- Resolved 
FilteredRelation.condition at referencing time.
https://github.com/django/django/pull/16776 - Updated admin's XRegExp 
to 5.1.1.
https://github.com/django/django/pull/16436 - Refs #31949 -- Made 
@never_cache and @cache_control() decorators to work with async functions.
https://github.com/django/django/pull/16796 - Replaced docutils link by 
PyPI reference.
https://github.com/django/django/pull/16802 - Fixed #34518 -- Fixed 
crash of random() template filter with an empty list.
https://github.com/django/django/pull/16803 - Doc'd that Count("*") is 
equivalent to COUNT(*) SQL.
https://github.com/django/django/pull/16807 - Refs #33662 -- Corrected 
Sitemap.get_languages_for_item() signature in docs.
https://github.com/django/django/pull/16614 - Fixed #34380 -- Allowed 
specifying a default URL scheme in forms.URLField.

*Reviewed:*
https://github.com/django/django/pull/16757 - Fixed #34481 -- Added 
system check for reverse related fields in ModelAdmin.list_display.

*Authored:*
https://github.com/django/django/pull/16799 - Fixed #34512 -- Restored 
breadcrumbs on admin app index view.
https://github.com/django/django/pull/16804 - Avoided creating default 
form fields in fields_for_model() when declared on form.
https://github.com/django/django/pull/16810 - Fixed #34515 -- Made 
LocaleMiddleware prefer language from paths when i18n patterns are used.
https://github.com/django/django/pull/16812 - Refs #34118, Refs #34504 
-- Added backward incompatibility note about EmailBackend.ssl_context.

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/0f904294-921c-4bde-9e80-000b3bc89e41n%40googlegroups.com.

Re: A different approach for the auto-reloader

[Salomon Roberto Herrera Navarro]

Buenas tardes David, cuentame

El vie, 28 abr 2023 13:15, David Arredondo 
escribió:

> Hola
>
> El vie, 28 de abr de 2023 12:02 p. m., natali...@gmail.com <
> nataliabid...@gmail.com> escribió:
>
>> Hello everyone!
>>
>> I'm conducting a PR cleanse crusade for the project, where I'll try move
>> forward those PRs that still make sense or close them when appropriate.
>> Were there other developments in this topic that would be relevant to make
>> a decision about the PR[0]?
>>
>> Thank you!
>> Natalia.
>>
>> [0] https://github.com/django/django/pull/13154
>>
>> On Wednesday, May 1, 2019 at 3:05:30 PM UTC-3 Adam Johnson wrote:
>>
>>> 1. It’s really hard to know where a request is going at this level, so
>>>> we could end up with a page view triggering 20 static files requests very
>>>> quickly, which would lead to stating all files 20x redundantly.
>>>
>>>
>>> Indeed, maybe this could be solved with a re-stat cooldown?
>>>
>>>
>>>> 2. How would we handle (potentially ridiculous) things like code
>>>> imported from a thread during app ready? In general wouldn’t we need some
>>>> kind of thread to poll for new imports to watch after Django has been
>>>> started?
>>>
>>>
>>> This is less ridiculous than it sounds, I'm working on an APM package
>>> that does something like this.
>>>
>>> On Wed, 1 May 2019 at 18:38, Tom Forbes  wrote:
>>>
>>>> Hey Ramiro,
>>>> This sounds like a pretty awesome idea in general. It would also solve
>>>> one long standing issue where the http socket is closed and re-opened
>>>> during reloading, leading to pageviews after code changes failing.
>>>>
>>>> I’m trying to think of some edge cases where we need to be careful, and
>>>> there are three I can think of:
>>>> 1. It’s really hard to know where a request is going at this level, so
>>>> we could end up with a page view triggering 20 static files requests very
>>>> quickly, which would lead to stating all files 20x redundantly.
>>>>
>>>> 2. How would we handle (potentially ridiculous) things like code
>>>> imported from a thread during app ready? In general wouldn’t we need some
>>>> kind of thread to poll for new imports to watch after Django has been
>>>> started?
>>>>
>>>> 3. Are there any workflows that would be disrupted by this? I can’t
>>>> think of any that I use, but it’s possible that people have come to rely on
>>>> the existing “does this throw an exception” in some cases, and triggering a
>>>> request only to get this could be annoying?
>>>>
>>>> Overall though this feels like a good idea. Stat based reloaders are a
>>>> lot simpler to deal with than platform specific fs monitoring. Ask thanks
>>>> for the kind words about my refactor, I’m glad the abstractions work on
>>>> something like this.
>>>>
>>>> Tom
>>>>
>>>> On 24 Apr 2019, at 05:33, Ramiro Morales  wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I had a stab at a somewhat simpler development server automatic
>>>> reloading strategy
>>>> https://github.com/django/django/compare/master...ramiro:synch-reloader
>>>>
>>>> Intention is to test how an implementation of a design by Gary
>>>> Bernhardt would look. The best written description I could find is this:
>>>>
>>>> https://github.com/devlocker/tychus/issues/3
>>>>
>>>> Gary also had posted some tweets (this is how I got interested in the
>>>> topic) which seems to have been deleted since then.
>>>>
>>>> Main idea is: Actual checking of changes on the filesystem for modules
>>>> under monitoring isn't performed in a loop or by depending on a OS kernel
>>>> feature but per-HTTP request by a front-end proxy process which is in
>>>> charge of restarting the 'upstream' web server process (in our case a
>>>> dumbed-down runserver dev server) only when it detects there have been
>>>> changes.
>>>>
>>>> Been meaning to try this for some time. It would have been much harder
>>>> before Tom Forbes' work on refactoring and cleaning up the reloading code
>>>> for Django 2.2. IMHO Tom's code is so very well thought that for example I
>>>> just had to lightly subclass StatReload to implement 

Re: A different approach for the auto-reloader

[David Arredondo]

Hola

El vie, 28 de abr de 2023 12:02 p. m., natali...@gmail.com <
nataliabid...@gmail.com> escribió:

> Hello everyone!
>
> I'm conducting a PR cleanse crusade for the project, where I'll try move
> forward those PRs that still make sense or close them when appropriate.
> Were there other developments in this topic that would be relevant to make
> a decision about the PR[0]?
>
> Thank you!
> Natalia.
>
> [0] https://github.com/django/django/pull/13154
>
> On Wednesday, May 1, 2019 at 3:05:30 PM UTC-3 Adam Johnson wrote:
>
>> 1. It’s really hard to know where a request is going at this level, so we
>>> could end up with a page view triggering 20 static files requests very
>>> quickly, which would lead to stating all files 20x redundantly.
>>
>>
>> Indeed, maybe this could be solved with a re-stat cooldown?
>>
>>
>>> 2. How would we handle (potentially ridiculous) things like code
>>> imported from a thread during app ready? In general wouldn’t we need some
>>> kind of thread to poll for new imports to watch after Django has been
>>> started?
>>
>>
>> This is less ridiculous than it sounds, I'm working on an APM package
>> that does something like this.
>>
>> On Wed, 1 May 2019 at 18:38, Tom Forbes  wrote:
>>
>>> Hey Ramiro,
>>> This sounds like a pretty awesome idea in general. It would also solve
>>> one long standing issue where the http socket is closed and re-opened
>>> during reloading, leading to pageviews after code changes failing.
>>>
>>> I’m trying to think of some edge cases where we need to be careful, and
>>> there are three I can think of:
>>> 1. It’s really hard to know where a request is going at this level, so
>>> we could end up with a page view triggering 20 static files requests very
>>> quickly, which would lead to stating all files 20x redundantly.
>>>
>>> 2. How would we handle (potentially ridiculous) things like code
>>> imported from a thread during app ready? In general wouldn’t we need some
>>> kind of thread to poll for new imports to watch after Django has been
>>> started?
>>>
>>> 3. Are there any workflows that would be disrupted by this? I can’t
>>> think of any that I use, but it’s possible that people have come to rely on
>>> the existing “does this throw an exception” in some cases, and triggering a
>>> request only to get this could be annoying?
>>>
>>> Overall though this feels like a good idea. Stat based reloaders are a
>>> lot simpler to deal with than platform specific fs monitoring. Ask thanks
>>> for the kind words about my refactor, I’m glad the abstractions work on
>>> something like this.
>>>
>>> Tom
>>>
>>> On 24 Apr 2019, at 05:33, Ramiro Morales  wrote:
>>>
>>> Hi all,
>>>
>>> I had a stab at a somewhat simpler development server automatic
>>> reloading strategy
>>> https://github.com/django/django/compare/master...ramiro:synch-reloader
>>>
>>> Intention is to test how an implementation of a design by Gary Bernhardt
>>> would look. The best written description I could find is this:
>>>
>>> https://github.com/devlocker/tychus/issues/3
>>>
>>> Gary also had posted some tweets (this is how I got interested in the
>>> topic) which seems to have been deleted since then.
>>>
>>> Main idea is: Actual checking of changes on the filesystem for modules
>>> under monitoring isn't performed in a loop or by depending on a OS kernel
>>> feature but per-HTTP request by a front-end proxy process which is in
>>> charge of restarting the 'upstream' web server process (in our case a
>>> dumbed-down runserver dev server) only when it detects there have been
>>> changes.
>>>
>>> Been meaning to try this for some time. It would have been much harder
>>> before Tom Forbes' work on refactoring and cleaning up the reloading code
>>> for Django 2.2. IMHO Tom's code is so very well thought that for example I
>>> just had to lightly subclass StatReload to implement this totally different
>>> strategy.
>>>
>>> Current form of the code is a new experimental 'serverrun' (for lack of
>>> a better name) added to the Django code base whose command line UI mimics
>>> 100% the runserver one.
>>>
>>> It copies code from a few places of our code base: The runserver
>>> command, the WSGI app hosting code, etc.
>>>
>>> I decided to implement thi

Re: A different approach for the auto-reloader

[natali...@gmail.com]

Hello everyone!

I'm conducting a PR cleanse crusade for the project, where I'll try move 
forward those PRs that still make sense or close them when appropriate. 
Were there other developments in this topic that would be relevant to make 
a decision about the PR[0]?

Thank you!
Natalia.

[0] https://github.com/django/django/pull/13154

On Wednesday, May 1, 2019 at 3:05:30 PM UTC-3 Adam Johnson wrote:

> 1. It’s really hard to know where a request is going at this level, so we 
>> could end up with a page view triggering 20 static files requests very 
>> quickly, which would lead to stating all files 20x redundantly.
>
>
> Indeed, maybe this could be solved with a re-stat cooldown?
>  
>
>> 2. How would we handle (potentially ridiculous) things like code imported 
>> from a thread during app ready? In general wouldn’t we need some kind of 
>> thread to poll for new imports to watch after Django has been started?
>
>
> This is less ridiculous than it sounds, I'm working on an APM package that 
> does something like this.
>
> On Wed, 1 May 2019 at 18:38, Tom Forbes  wrote:
>
>> Hey Ramiro,
>> This sounds like a pretty awesome idea in general. It would also solve 
>> one long standing issue where the http socket is closed and re-opened 
>> during reloading, leading to pageviews after code changes failing.
>>
>> I’m trying to think of some edge cases where we need to be careful, and 
>> there are three I can think of:
>> 1. It’s really hard to know where a request is going at this level, so we 
>> could end up with a page view triggering 20 static files requests very 
>> quickly, which would lead to stating all files 20x redundantly.
>>
>> 2. How would we handle (potentially ridiculous) things like code imported 
>> from a thread during app ready? In general wouldn’t we need some kind of 
>> thread to poll for new imports to watch after Django has been started?
>>
>> 3. Are there any workflows that would be disrupted by this? I can’t think 
>> of any that I use, but it’s possible that people have come to rely on the 
>> existing “does this throw an exception” in some cases, and triggering a 
>> request only to get this could be annoying?
>>
>> Overall though this feels like a good idea. Stat based reloaders are a 
>> lot simpler to deal with than platform specific fs monitoring. Ask thanks 
>> for the kind words about my refactor, I’m glad the abstractions work on 
>> something like this.
>>
>> Tom
>>
>> On 24 Apr 2019, at 05:33, Ramiro Morales  wrote:
>>
>> Hi all,
>>
>> I had a stab at a somewhat simpler development server automatic reloading 
>> strategy 
>> https://github.com/django/django/compare/master...ramiro:synch-reloader
>>
>> Intention is to test how an implementation of a design by Gary Bernhardt 
>> would look. The best written description I could find is this:
>>
>> https://github.com/devlocker/tychus/issues/3
>>
>> Gary also had posted some tweets (this is how I got interested in the 
>> topic) which seems to have been deleted since then.
>>
>> Main idea is: Actual checking of changes on the filesystem for modules 
>> under monitoring isn't performed in a loop or by depending on a OS kernel 
>> feature but per-HTTP request by a front-end proxy process which is in 
>> charge of restarting the 'upstream' web server process (in our case a 
>> dumbed-down runserver dev server) only when it detects there have been 
>> changes. 
>>
>> Been meaning to try this for some time. It would have been much harder 
>> before Tom Forbes' work on refactoring and cleaning up the reloading code 
>> for Django 2.2. IMHO Tom's code is so very well thought that for example I 
>> just had to lightly subclass StatReload to implement this totally different 
>> strategy.
>>
>> Current form of the code is a new experimental 'serverrun' (for lack of a 
>> better name) added to the Django code base whose command line UI mimics 
>> 100% the runserver one. 
>>
>> It copies code from a few places of our code base: The runserver command, 
>> the WSGI app hosting code, etc.
>>
>> I decided to implement this as a new built-in command for now a) to ease 
>> experimentation and b) because it needs some minor changes to the 
>> 'runserver' command to handle cosmetic details (logging). If the idea is 
>> accepted (read further below for reasons in favor of this) then maybe we 
>> can switch runserver to this code. Or if the idea isn't deemed appropate 
>> for Django core them I might implement it as an standalone django 
>> app/project.
>>
>&

Re: Django behavior on translatable URL patterns (i18n_patterns) when prefix_default_language=False is used.

[Mariusz Felisiak]

Anthony, please don't start the same discussion on multiple channels.

If anyone wants to add a comment, please do so in the forum 

.

-- 
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/e5ac7207-08c9-49e9-8045-404c28489cb7n%40googlegroups.com.

Re: Fellow Reports - April 2023

[Natalia Bidart]

Week ending 2023-04-23 (Week 17)

Triaged:
  https://code.djangoproject.com/ticket/34506 - Visual regressions in
admin's clearable file input. (accepted)
  https://code.djangoproject.com/ticket/34507 - AttributeError: Can't
pickle local object 'convert_exception_to_response..inner'
(needsinfo)

Reviewed:
  https://github.com/django/django/pull/16771 - Added
RemovedInDjangoXXWarning comments to the deprecating a feature docs.
  https://github.com/django/django/pull/16784 - Added meaningful titles to
..admonition:: directives.
  https://github.com/django/django/pull/16757 - Fixed #34481 -- Added
checks for reverse related fields in admin's list_display
  https://github.com/django/django/pull/16636/ - Fixed #34391 -- Added
async interface to auth (lots of interesting things to read around this!)
  https://github.com/django/django/pull/14257 - Made SimpleTestCase client
attributes cached properties.

PR Housekeeping:
  https://github.com/django/django/pull/7161 - Fixed #25594 -- Propagated
validators from model to form fields (closed)
  https://github.com/django/django/pull/8435 - Optimized
ModelAdmin.changelist_view if actions are not used (closed)
  https://github.com/django/django/pull/8848 - Allowed (partial) indexes
for text fields on MySQL (closed)
  https://github.com/django/django/pull/10708 - Form field label i18n
performances fixes (closed)
  https://github.com/django/django/pull/10349 - Fixed #29717 -- Allowed
tests to use an existing empty database. (closed)
  https://github.com/django/django/pull/10951 - WIP #30149 -- Empty value
selected check in Admin Filter prevents subclassing (closed)
  https://github.com/django/django/pull/11291 - Fixed #30416 -- Restore
terminal state when reloading. (asked for update)
  https://github.com/django/django/pull/11981 - Fixed #23051 -- Raise
exception on only() calls with reverse fields (asked for update)
  https://github.com/django/django/pull/12090 - Fixed #29058 -- return geom
type for GeoDjango fields when using Spatialite backend so that migrations
don't fail. (asked for update)
  https://github.com/django/django/pull/12274 - [WIP/RFC]
DateField/TimeField: allow for editable=True with auto_now/auto_now_add
(closed)
  https://github.com/django/django/pull/13853 - Refs #21429 -- Added
SimpleTestCase.assertLogRecords. (asked for update)
  https://github.com/django/django/pull/12285 - URLValidator: clarify
comment about maximum length of a host name. (resolved conflict and chasing
down who can further comment about the change)

Authored:
  https://github.com/django/django/pull/16791 - Refs #34462 -- Fixed query
anti-pattern when processing object deletion

Other/Misc:
  Google Summer of Code proposals review.

On Mon, Apr 17, 2023 at 5:54 PM Natalia Bidart 
wrote:

> Week ending 2023-04-16 (Week 16)
>
> Triaged:
>   https://code.djangoproject.com/ticket/34490 - Tests with mirror
> database not working as expected (invalid)
>   https://code.djangoproject.com/ticket/34489 - feature: Support for
> PostgreSQL table partitioning (needsinfo)
>
> Reviewed:
>   https://github.com/django/django/pull/16726 - Solved #10743: Support
> lookup separators
>   https://github.com/django/django/pull/16756 - Fixed #34484, Fixed
> #34482 -- Fixed cloning/deep cloning HttpRequest, HttpResponse, and their
> subclasses.
>   https://github.com/django/django/pull/16759 - Fixed #22569 -- Made
> ModelAdmin.lookup_allowed() respect get_list_filter().
>
> Authored:
>   https://github.com/django/djangoproject.com/pull/1346 - Fixed #1341 --
> Updated info about past and present Django Fellows.
>   https://github.com/django/django/pull/16756 - Fixed #34483 -- Fixed
> timesince()/timeuntil() with timezone-aware dates and interval less than 1
> day.
>
> Other/Misc:
>   Security mailing list monitoring and follow ups
>   More docs reading
>   Setup access to various services and projects
>   Investigated and commented on
> https://code.djangoproject.com/ticket/32847 - Adjust models.E025 system
> check for updated field descriptor setting.
>
> Cheers! Natalia.
>
> On Tue, Apr 11, 2023 at 10:52 AM Natalia Bidart 
> wrote:
>
>> Week ending April 9, 2023
>>
>> Hello! I'm Natalia (AKA nessita), the new Django Fellow. I officially
>> started on April 1st (really :-)) though I had a slow start since I had a
>> long-time planned vacation.
>>
>> So far I have held catch up calls with both current and former Django
>> Fellows (thanks Mariusz and Carlton for your patience and support!), and I
>> have been deep diving into documentation.
>>
>> I'm looking forward to working with you all!
>>
>> Thank you!
>> Natalia.
>>
>

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

Re: Fellow Reports - April 2023

[Mariusz Felisiak]

Week ending April 23, 2023

*Triaged:*
https://code.djangoproject.com/ticket/34488 - ClearableFileInput widget 
forgets "Clear" selection when form is not valid. (accepted)
https://code.djangoproject.com/ticket/34500 - use annotate return 
feild, Error capture does not work (duplicate)
https://code.djangoproject.com/ticket/34496 - 
ManifestStaticFilesStorage.patterns for sourceMappingURL does not retrieve 
matched for data URI (accepted)
https://code.djangoproject.com/ticket/34501 - Revert CICharField 
deprecation (wontfix)
https://code.djangoproject.com/ticket/34502 - Union giving wrong column 
ordering even when using .values/.values_list (duplicate)
https://code.djangoproject.com/ticket/34504 - SSLCertVerificationError 
on outgoing emails for some mailboxes (needsinfo)
https://code.djangoproject.com/ticket/34506 - Visual regressions in 
admin's clearable file input. (created)
https://code.djangoproject.com/ticket/34505 - Non-deterministic 
collations doesn't work with unique related fields on PostgreSQL (accepted)
https://code.djangoproject.com/ticket/34509 - Celery task throwing 
error (invalid)
https://code.djangoproject.com/ticket/34508 - Admin Checks Reversed 
FKs.( modified check_list_display function ) (needsinfo)
https://code.djangoproject.com/ticket/34507 - AttributeError: Can't 
pickle local object 'convert_exception_to_response..inner' 
(duplicate)

*Reviewed/committed:*
https://github.com/django/django/pull/16773 - Used extlinks for PyPI 
links.
https://github.com/django/django/pull/16759 - Fixed #22569 -- Made 
ModelAdmin.lookup_allowed() respect get_list_filter().
https://github.com/django/django/pull/16632 - Fixed #16055 -- Fixed 
crash when filtering against char/text GenericRelation relation on 
PostgreSQL.
https://github.com/django/django/pull/16641 - Added Irish locale 
formats.
https://github.com/django/django/pull/16783 - Fixed #34435 -- Doc'd 
that JSONField.default must be a callable.
https://github.com/django/django/pull/16781 - Corrected exception type 
in safe_join()'s docstring.
https://github.com/django/django/pull/16692 - Fixed #34440 -- Doc'd 
that & queryset operator works similar to chaining.
https://github.com/django/django/pull/16780 - Fixed #34496 -- Fixed 
handling source maps with data URI in ManifestStaticFilesStorage.
https://github.com/django/django/pull/16785 - Fixed #34488 -- Made 
ClearableFileInput preserve "Clear" checked attribute when form is invalid.
https://github.com/django/django/pull/16788 - Fixed #34505 -- Skipped 
varchar_pattern_ops/text_pattern_ops index creation when db_collation is 
set in related field.
https://github.com/django/django/pull/16791 - Refs #34462 -- Fixed 
queryset antipattern when processing object deletion.

*Reviewed:*
https://github.com/django/django/pull/16771 - Doc'd 
RemovedInDjangoXXWarning comments in deprecating a feature guide.

*Authored:*
https://github.com/django/django/pull/16784 - Added meaningful titles 
to ..admonition:: directives.
https://github.com/django/django/pull/16787 - Improved examples in docs 
about raw SQL queries.
https://github.com/django/django/pull/16789 - Fixed #34506 -- Fixed 
margin of ClearableFileInput in admin CSS.

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/6c502ffc-8acf-429a-82c0-e6d73f6235c2n%40googlegroups.com.

Re: Django 5.x Technical Board Candidate Registration

[Katie McLaughlin]

With apologies from the Secretary, the above information is incorrect 
regarding the candidacy requirements for this election. 

The new post with the updated details has been posted 
here: https://groups.google.com/g/django-developers/c/ZjkbmE5bIoE 

Regards, 

Katie McLaughlin
Secretary
Django Software Foundation


On Sunday, 23 April 2023 at 07:57:11 UTC+10 Katie McLaughlin wrote:

> With the completion of the Django 4.x major release cycle and in 
> accordance with DEP-0010 
> ,
>  
> it is now time to collect candidates for the Django Technical Board.
>
> Technical board candidates must demonstrate:
>
>- A history of technical contributions to Django or the Django 
>ecosystem. This history MUST begin at least 18 months prior to the 
>individual's candidacy for the Technical Board.
>- A history of participation in Django's development outside of 
>contributions merged to the https://github.com/django/django/ 
>repository. This may include, but is not restricted to:
>   - Participation in discussions on the django-developers mailing 
>   list or Django Forum.
>   - Reviewing and offering feedback on pull requests in the Django 
>   source-code repository
>   - Assisting in triage and management of the Django bug tracker.
>- A history of recent engagement with the direction and development of 
>Django. Such engagement MUST have occurred within a period of no more than 
>two years prior to the individual's candidacy for the Technical Board.
>
>
> To register your candidacy, we require you to enter your name, email, and 
> a bio/evidence of qualifications. The candidacy form has optional fields 
> for your GitHub, Twitter, and website which can be useful for evaluating 
> your qualifications.
>
> Your email address will only be used by the DSF to contact you related to 
> the election and process and will not be shared publicly.
>
> Registration for Candidates will end on April 28th, 2023 AoE.
>
> Please register using this form .
>
> If you have any questions about the election, please see the post on 
> djangoproject.com for contact details: 
> https://www.djangoproject.com/weblog/2023/apr/22/technical-board-candidate-registration/
>

-- 
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/1877360d-0542-4dbc-a759-55b56d279f3cn%40googlegroups.com.

Re: Oracle 23c released earlier this month

[David Sanders]

Looks like python-oracledb is making updates to be compatible with 
23c: 
https://python-oracledb.readthedocs.io/en/latest/release_notes.html#oracledb-1-3-1-tbd

1.3.1 isn't released yet but the fact that updates are being made so soon 
is encouraging 

On Monday, 17 April 2023 at 22:06:57 UTC+10 Mariusz Felisiak wrote:

> Hi,
>
>   Thanks! Also, they finally update VM: 
> https://www.oracle.com/database/technologies/databaseappdev-vm.html 
>   We still have to wait for a compatible driver, cx_Oracle and 
> python-oracledb don't support it yet.
>
> 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/7fe50d11-4b70-40b5-98b1-6964cd70edb9n%40googlegroups.com.

Re: Drop CSRF middleware from the settings template

[Florian Apolloner]

On Thursday, April 20, 2023 at 1:00:05 PM UTC+2 Jure Erznožnik wrote:

OK, I'll bite:

For the first issue, my problem revolved around this code:
@property def POST(self): # Ensure that request.POST uses our request 
parsing. if not _hasattr(self, '_data'): self._load_data_and_files() if 
is_form_media_type(self.content_type): return self._data 

return QueryDict('', encoding=self._request._encoding) 


That code looks correct. I cannot tell you why self._data would be lost, 
but the empty QueryDict for request.POST makes sense. Please note that my 
comments only apply to the Django codebase itself, I don't really know what 
DRF does aside from that

IIUC, this code tries to match the token received from the headers with one 
that's supposed to be in the form data payload. The code is allowed to fail 
just fine, but in this case it has the side-effect mentioned: the form 
payload will have been parsed and cannot be parsed again - while at the 
same time rejecting the parsed data because it is not form payload type. 


It compares the value from the cookie with either the value from the header 
or the form payload. There is no need to parse it again, 
_load_data_and_files from above does this and sets it: 
https://github.com/encode/django-rest-framework/blob/38a74b42da10576857d6bf8bd82a73b15d12a7ed/rest_framework/request.py#L283
 
If you use application/json you need to access request.data in DRF, 
request.POST will always be empty.
 

What I was trying to say with that paragraph was that I'd like to actually 
figure out a way to START doing token rotation because my observation is 
that it's currently NOT rotating and is therefore a lot less useful as a 
security measure.


Oh then I did misread you. It is not neccessary to rotate the token every 
request, reusing the token that you obtain once is just fine. 

Cheers,
Florian

-- 
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/263b4b04-f986-42fc-9e1d-1fc7a4e4b264n%40googlegroups.com.

Re: Drop CSRF middleware from the settings template

[Jure Erznožnik]

OK, I'll bite:

For the first issue, my problem revolved around this code:

@property def POST(self): # Ensure that request.POST uses our request 
parsing. if not _hasattr(self, '_data'): self._load_data_and_files() if 
is_form_media_type(self.content_type): return self._data return 
QueryDict('', encoding=self._request._encoding)


The second `if` asks whether the payload is form media type, and, if so, 
returns the parsed content, otherwise it returns a blank QueryDict. In 
my case, the content-type was set to application/json. It parsed 
successfully and self._data was still populated when the code reached 
the second if. However, the second if rejected the content and skipped 
to returning the empty QueryDict, which then resulted in payload 
consequently being served as the empty QueryDict also for DRF. I can't 
really say where the actual request._data got reset because of this, but 
I did (get reset). I'm guessing DRF tries to parse the data from 
scratch, but the stream was consumed already or some such. I didn't 
nearly debug this enough to KNOW what went wrong.


I was unable to find the actual culprit for this behaviour, so I 
ultimately just exempt the view. But the circumstances of the actual 
issue were very unclear: I have a commit where CSRF middleware chose 
this path and a commit where it did not. I was unable to find the 
culprit by being unable to find the condition that made the middleware 
go into the check at all - contrary to the commit before where it did 
not. Needless to say, the commits did not deal with anything I perceived 
as anything near CSRF or AJAX. They were super small too...


This is the actual section of the code that triggers the POST processing 
in the middleware:


if request.method == "POST": try: request_csrf_token = 
request.POST.get('csrfmiddlewaretoken', '') except OSError:


IIUC, this code tries to match the token received from the headers with 
one that's supposed to be in the form data payload. The code is allowed 
to fail just fine, but in this case it has the side-effect mentioned: 
the form payload will have been parsed and cannot be parsed again - 
while at the same time rejecting the parsed data because it is not form 
payload type.


As for the second issue, I must admit I don't understand your reply at 
all. I'm a pretty bad n00b while you're one of the Django đombas (tough 
big guys) and it's entirely possible I am misinterpreting what I'm 
seeing here. I just stated my observation that Django now only serves 
the index.html for me, generating a CSRF token along the way and then I 
use that CSRF token for all subsequent AJAX requests. I don't even 
understand the "visual representation changes" and "looks like it's 
different". So, sorry, I'm afraid I can't be of assistance here.


What I was trying to say with that paragraph was that I'd like to 
actually figure out a way to START doing token rotation because my 
observation is that it's currently NOT rotating and is therefore a lot 
less useful as a security measure.


Now I have bit my chunk off and I'm chewing. Hopefully no hooks in there ;)

LP,
Jure


On 20. 04. 23 11:51, Florian Apolloner wrote:

Hi,

On Tuesday, April 18, 2023 at 10:57:55 PM UTC+2 jure.er...@gmail.com 
wrote:


Well, TBH, I've just completed dealing with CSRF form in my
projects. I ended up exempting the particular view from CSRF
because I didn't know how to get the stuff to work. The problem
was that django parsed the body payload, which was JSON and thus
rejected its contents (because it wasn't form payload type – POST
method). As a result, DRF then had no payload to work with… I
shouldn't go into too much detail as it's irrelevant to the point.


I do not think this is true. Django only parses the POST data if the 
content-type is a form type, so if you are sending JSON properly 
Django will not parse the data and DRF can handle it just fine.


 But, I've been considering I need a modernised CSRF: currently it
works by generating a new token every page served. But we have
switched our front-end to SPA and that doesn't make much sense any
more since CSRF token itself doesn't change at all, since Django
template system only ever serves one page. AFAIK, DRF doesn't
ganerate new tokens in its pipelines.


That is not accurate either. The token does not change for every page 
served, only it's visual representation does. That means that you can 
keep using the same CSRF token even though it looks like it is 
different (note: This assume that you are not triggering a codepath 
that is rotating the token).


Cheers,
Florian
--
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 

Re: Django's automatic admin interface.

[Dipankar]

Thank you all or your comments .. I am happy to hear about wire or
htmx @Matthew.
I want to do it for myself if I get a little bit clue from you. Thanks a
lot.

On Wed, Apr 19, 2023 at 7:25 PM Matthew Pava  wrote:

> I agree with your sentiment, Tom. I would add that we could get a more
> “SPA-feel” by using HTML over the wire or htmx, which requires minimal
> JavaScript.
>
>
>
> *From:* django-developers@googlegroups.com <
> django-developers@googlegroups.com> *On Behalf Of *Tom Carrick
> *Sent:* Wednesday, April 19, 2023 5:07 AM
> *To:* django-developers@googlegroups.com
> *Subject:* Re: Django's automatic admin interface.
>
>
>
> IMO, if we were going to modernise the admin (which is laudable), it
> wouldn't be by using JS frameworks or Tailwind, but by simplifying things
> further, by removing the last bits of JQuery, simplifying the HTML and
> making it more semantic, and rewriting the CSS to use a grid based layout
> and cut down the amount of code that is needed to achieve the same result.
>
>
>
> I don't have anything against Tailwind or Vue per së, but forcing every
> Django project to have them in the backend seems too opinionated and too
> much of a maintenance burden.
>
>
>
> As you mentioned, there are already opinionated packages out there, I'm
> happy they exist, but in my opinion they belong in external packages, not
> in core.
>
>
>
> Tom
>
>
>
> On Wed, 19 Apr 2023 at 11:45, Dipankar  wrote:
>
> Sorry if my question is wrong.. .. Not exactly technology I wanted to know
> about the frontend framework like tailwindCSS,react or Vue.
>
>
>
> In nutshell I want admin interface with tailwindCSS/React/Vue. any
> suggestion ?
>
>
>
> On Wed, Apr 19, 2023 at 3:01 PM David Sanders <
> shang.xiao.sand...@gmail.com> wrote:
>
> Hi Dipankar,
>
>
>
> Not being rude but serious question: What's the latest front end
> technology? :)
>
>
>
> On Wed, 19 Apr 2023, 7:27 pm Dipankar,  wrote:
>
> Is there any plan to replace Django's automatic admin interface with the
> latest front end technology?
>
> There are several packages available but what if Django itself provides
> the same as core.
>
>
> --
>
> Warm Regards,
> Dipankar B.
>
> --
> 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/CAFdBwp_N0remvp8zAPFVda6iyFWVWR%3DZh0EtfE9fzYcPQVixkQ%40mail.gmail.com
> <https://us-east-2.protection.sophos.com?d=google.com=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9kL21zZ2lkL2RqYW5nby1kZXZlbG9wZXJzL0NBRmRCd3BfTjByZW12cDh6QVBGVmRhNml5RldWV1IlM0RaaDBFdGZFOWZ6WWNQUVZpeGtRJTQwbWFpbC5nbWFpbC5jb20_dXRtX21lZGl1bT1lbWFpbCZ1dG1fc291cmNlPWZvb3Rlcg===NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1=czlHb2JnZEVuTWtvbjlONHNaMXM3ZUVzd3JVaVRGOFFETW9FYm42QzUwTT0==8d68f43f4a154531b39ff6816b335a07=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilb93oKaJ4TlYUgerrF37mdcvEPc0PHtDv6-pbmEIiTZTgZnnRSA2CyqseLQ7HmqwUlWlZc02dv_ipQ2a8ofXYw6w>
> .
>
> --
> 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-61oX4oh3apDatm_MKCdoYCMLxkk8O4krKMZuPZF2LpNg%40mail.gmail.com
> <https://us-east-2.protection.sophos.com?d=google.com=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9kL21zZ2lkL2RqYW5nby1kZXZlbG9wZXJzL0NBRHlady02MW9YNG9oM2FwRGF0bV9NS0Nkb1lDTUx4a2s4TzRrcktNWnVQWkYyTHBOZyU0MG1haWwuZ21haWwuY29tP3V0bV9tZWRpdW09ZW1haWwmdXRtX3NvdXJjZT1mb290ZXI==NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1=Zkk3SEhGNVYvcTlwampuRlN1VGhTVG1yWlJPdE83OHJpRjdpSHVNd1JnVT0==8d68f43f4a154531b39ff6816b335a07=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilb93oKaJ4TlYUgerrF37mdcvEPc0PHtDv6-pbmEIiTZTgZnnRSA2CyqseLQ7HmqwUlWlZc02dv_ipQ2a8ofXYw6w>
> .
>
>
>
> --
>
> Warm Regards,
> Dipankar B.
>
> --
> 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/CAFdBwp-cO_g_JCTQhMQVEJe%2BN4FjJD5F-D%2B7LKugRK%2B1-Pq3R

Re: Drop CSRF middleware from the settings template

[Florian Apolloner]

Hi,

On Tuesday, April 18, 2023 at 10:57:55 PM UTC+2 jure.er...@gmail.com wrote:

Well, TBH, I've just completed dealing with CSRF form in my projects. I 
ended up exempting the particular view from CSRF because I didn't know how 
to get the stuff to work. The problem was that django parsed the body 
payload, which was JSON and thus rejected its contents (because it wasn't 
form payload type – POST method). As a result, DRF then had no payload to 
work with… I shouldn't go into too much detail as it's irrelevant to the 
point.


I do not think this is true. Django only parses the POST data if the 
content-type is a form type, so if you are sending JSON properly Django 
will not parse the data and DRF can handle it just fine. 
 

 But, I've been considering I need a modernised CSRF: currently it works by 
generating a new token every page served. But we have switched our 
front-end to SPA and that doesn't make much sense any more since CSRF token 
itself doesn't change at all, since Django template system only ever serves 
one page. AFAIK, DRF doesn't ganerate new tokens in its pipelines.


That is not accurate either. The token does not change for every page 
served, only it's visual representation does. That means that you can keep 
using the same CSRF token even though it looks like it is different (note: 
This assume that you are not triggering a codepath that is rotating the 
token).

Cheers,
Florian 

-- 
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/f64582bd-63ea-483a-aebc-2acc5dac6cdbn%40googlegroups.com.

Re: Production Django use and "real ip"

['Adam Johnson' via Django developers (Contributions to Django itself)]

> Are there any deployment scenarios where META.REMOTE_ADDR is ever even
correct?

Yes, when running a WSGI server that faces the internet, with no
intermediate proxies.

On Wed, Apr 19, 2023 at 3:51 PM Arthur Pemberton  wrote:

> At this point, I'm not even suggesting that Django handle this internally.
> I'm suggesting that the behaviour/expectation be documented, at least in
> the deployment guide.
>
> Are there any deployment scenarios where META.REMOTE_ADDR is ever even
> correct?
>
> Arthur Pemberton
>
> On Wed, Apr 19, 2023 at 3:37 AM 'st...@jigsawtech.co.uk' via Django
> developers (Contributions to Django itself) <
> django-developers@googlegroups.com> wrote:
>
>> As someone whose worked on various projects in different languages over
>> the last 15 years that heavily involved deciphering IP sent in headers to
>> try to determine the "real" IP address of a connection, I would urge
>> caution with anything around determining a "real IP". There is no standard
>> in terms of where to look and what to trust. The X-FORWARDED-FOR is not
>> always right, can easily be spoofed, it can include multiple IPs of which
>> the order is not consistent. Sometimes the left most element is the first
>> and "true IP", sometimes it's the right, sometimes its a value in the
>> middle. It all depends what's included, what appended to the request, what
>> the values are and what you want to trust/ignore. I've seen requests that
>> include internal network IPs, then router/gateway IPs, proxy IPs and load
>> balancers all within that head all in different orders.   It's especially
>> messy when dealing with requests on mobile network where the carrier uses
>> proxies, sometimes 3rd parties, and where your website is hosted behind
>> both load balancers and webserver as each may manipulate the header in
>> different ways.
>>
>> One of the best packages within the Django eco-system for trying to
>> identify a users actual external IP that I've come across is
>> django-ipware . It allows you to
>> choose the precedence order that matches your use case, yo have private IP
>> prefixes, to configure how many proxies you wish to ignore etc. They also
>> have a handy notice/disclaimer
>>  on
>> the subject.
>>
>> IMO Django core should leave this 3rd party packages and individual
>> deployments to decide and determine what they deem as being the source of
>> the "real IP" for their individual project.
>>
>>
>>
>> On Friday, 14 April 2023 at 10:13:22 UTC+1 Adam Johnson wrote:
>>
>>> It's surprisingly complex to interpret x-forwarded-for:
>>> https://www.brainonfire.net/blog/2022/03/04/understanding-using-xff/ .
>>> We will never be able to safely add automated handling.
>>>
>>> I *guess* we could add a note to the deployment guide like "check your
>>> HTTP_X_FORWARDED_FOR setting". I'm concerned it would be a step towards
>>> making the guide too long, and filled with irrelevant details. Most sites
>>> don't care about recording the user's IP. On those that do, it should be
>>> easy enough to discover the setting.
>>>
>>> On Sat, Apr 1, 2023 at 4:39 AM Arthur Pemberton 
>>> wrote:
>>>
 I have read previous discussions (most recent I could find was Dec 2013
  [1] ) on the inclusion of `HTTP_X_FORWARDED_FOR` based logic to get the
 "real" IP address of an HttpRequest. From what I can see, currently there
 is currently no automatic handling of `HTTP_X_FORWARDED_FOR` in Django.

 However, I do notice that Django acknowledges `X_FORWARDED_HOST`,
 `X_FORWARDED_PORT` and (indirectly) `X_FORWARDED_PROTO`
 (though SECURE_PROXY_SSL_HEADER).

 If there is still opposition to having some built-in handling for
 `HTTP_X_FORWARDED_FOR`, I think that the deployment guide [1] should at
 least mention the need for the developer to handle this explicitly.

 Regards,
 Arthur P.

 

 [1]
 https://groups.google.com/g/django-developers/c/J5O28jB5D3Q/m/KLLgllFS7v0J
 [2] https://docs.djangoproject.com/en/4.1/howto/deployment/

 --
 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-develop...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%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 

Re: Production Django use and "real ip"

[Arthur Pemberton]

At this point, I'm not even suggesting that Django handle this internally.
I'm suggesting that the behaviour/expectation be documented, at least in
the deployment guide.

Are there any deployment scenarios where META.REMOTE_ADDR is ever even
correct?

Arthur Pemberton

On Wed, Apr 19, 2023 at 3:37 AM 'st...@jigsawtech.co.uk' via Django
developers (Contributions to Django itself) <
django-developers@googlegroups.com> wrote:

> As someone whose worked on various projects in different languages over
> the last 15 years that heavily involved deciphering IP sent in headers to
> try to determine the "real" IP address of a connection, I would urge
> caution with anything around determining a "real IP". There is no standard
> in terms of where to look and what to trust. The X-FORWARDED-FOR is not
> always right, can easily be spoofed, it can include multiple IPs of which
> the order is not consistent. Sometimes the left most element is the first
> and "true IP", sometimes it's the right, sometimes its a value in the
> middle. It all depends what's included, what appended to the request, what
> the values are and what you want to trust/ignore. I've seen requests that
> include internal network IPs, then router/gateway IPs, proxy IPs and load
> balancers all within that head all in different orders.   It's especially
> messy when dealing with requests on mobile network where the carrier uses
> proxies, sometimes 3rd parties, and where your website is hosted behind
> both load balancers and webserver as each may manipulate the header in
> different ways.
>
> One of the best packages within the Django eco-system for trying to
> identify a users actual external IP that I've come across is django-ipware
> . It allows you to choose the
> precedence order that matches your use case, yo have private IP prefixes,
> to configure how many proxies you wish to ignore etc. They also have a
> handy notice/disclaimer
>  on
> the subject.
>
> IMO Django core should leave this 3rd party packages and individual
> deployments to decide and determine what they deem as being the source of
> the "real IP" for their individual project.
>
>
>
> On Friday, 14 April 2023 at 10:13:22 UTC+1 Adam Johnson wrote:
>
>> It's surprisingly complex to interpret x-forwarded-for:
>> https://www.brainonfire.net/blog/2022/03/04/understanding-using-xff/ .
>> We will never be able to safely add automated handling.
>>
>> I *guess* we could add a note to the deployment guide like "check your
>> HTTP_X_FORWARDED_FOR setting". I'm concerned it would be a step towards
>> making the guide too long, and filled with irrelevant details. Most sites
>> don't care about recording the user's IP. On those that do, it should be
>> easy enough to discover the setting.
>>
>> On Sat, Apr 1, 2023 at 4:39 AM Arthur Pemberton  wrote:
>>
>>> I have read previous discussions (most recent I could find was Dec 2013
>>>  [1] ) on the inclusion of `HTTP_X_FORWARDED_FOR` based logic to get the
>>> "real" IP address of an HttpRequest. From what I can see, currently there
>>> is currently no automatic handling of `HTTP_X_FORWARDED_FOR` in Django.
>>>
>>> However, I do notice that Django acknowledges `X_FORWARDED_HOST`,
>>> `X_FORWARDED_PORT` and (indirectly) `X_FORWARDED_PROTO`
>>> (though SECURE_PROXY_SSL_HEADER).
>>>
>>> If there is still opposition to having some built-in handling for
>>> `HTTP_X_FORWARDED_FOR`, I think that the deployment guide [1] should at
>>> least mention the need for the developer to handle this explicitly.
>>>
>>> Regards,
>>> Arthur P.
>>>
>>> 
>>>
>>> [1]
>>> https://groups.google.com/g/django-developers/c/J5O28jB5D3Q/m/KLLgllFS7v0J
>>> [2] https://docs.djangoproject.com/en/4.1/howto/deployment/
>>>
>>> --
>>> 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-develop...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%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/4f06664d-135e-4eb2-86ec-11eccf4cb495n%40googlegroups.com
> 
> 

RE: Django's automatic admin interface.

[Matthew Pava]

I agree with your sentiment, Tom. I would add that we could get a more 
“SPA-feel” by using HTML over the wire or htmx, which requires minimal 
JavaScript.

From: django-developers@googlegroups.com  
On Behalf Of Tom Carrick
Sent: Wednesday, April 19, 2023 5:07 AM
To: django-developers@googlegroups.com
Subject: Re: Django's automatic admin interface.

IMO, if we were going to modernise the admin (which is laudable), it wouldn't 
be by using JS frameworks or Tailwind, but by simplifying things further, by 
removing the last bits of JQuery, simplifying the HTML and making it more 
semantic, and rewriting the CSS to use a grid based layout and cut down the 
amount of code that is needed to achieve the same result.

I don't have anything against Tailwind or Vue per së, but forcing every Django 
project to have them in the backend seems too opinionated and too much of a 
maintenance burden.

As you mentioned, there are already opinionated packages out there, I'm happy 
they exist, but in my opinion they belong in external packages, not in core.

Tom

On Wed, 19 Apr 2023 at 11:45, Dipankar 
mailto:dipit2...@gmail.com>> wrote:
Sorry if my question is wrong.. .. Not exactly technology I wanted to know 
about the frontend framework like tailwindCSS,react or Vue.

In nutshell I want admin interface with tailwindCSS/React/Vue. any suggestion ?

On Wed, Apr 19, 2023 at 3:01 PM David Sanders 
mailto:shang.xiao.sand...@gmail.com>> wrote:
Hi Dipankar,

Not being rude but serious question: What's the latest front end technology? :)

On Wed, 19 Apr 2023, 7:27 pm Dipankar, 
mailto:dipit2...@gmail.com>> wrote:
Is there any plan to replace Django's automatic admin interface with the latest 
front end technology?
There are several packages available but what if Django itself provides the 
same as core.

--
Warm Regards,
Dipankar B.
--
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<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFdBwp_N0remvp8zAPFVda6iyFWVWR%3DZh0EtfE9fzYcPQVixkQ%40mail.gmail.com<https://us-east-2.protection.sophos.com?d=google.com=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9kL21zZ2lkL2RqYW5nby1kZXZlbG9wZXJzL0NBRmRCd3BfTjByZW12cDh6QVBGVmRhNml5RldWV1IlM0RaaDBFdGZFOWZ6WWNQUVZpeGtRJTQwbWFpbC5nbWFpbC5jb20_dXRtX21lZGl1bT1lbWFpbCZ1dG1fc291cmNlPWZvb3Rlcg===NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1=czlHb2JnZEVuTWtvbjlONHNaMXM3ZUVzd3JVaVRGOFFETW9FYm42QzUwTT0==8d68f43f4a154531b39ff6816b335a07=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilb93oKaJ4TlYUgerrF37mdcvEPc0PHtDv6-pbmEIiTZTgZnnRSA2CyqseLQ7HmqwUlWlZc02dv_ipQ2a8ofXYw6w>.
--
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<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADyZw-61oX4oh3apDatm_MKCdoYCMLxkk8O4krKMZuPZF2LpNg%40mail.gmail.com<https://us-east-2.protection.sophos.com?d=google.com=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9kL21zZ2lkL2RqYW5nby1kZXZlbG9wZXJzL0NBRHlady02MW9YNG9oM2FwRGF0bV9NS0Nkb1lDTUx4a2s4TzRrcktNWnVQWkYyTHBOZyU0MG1haWwuZ21haWwuY29tP3V0bV9tZWRpdW09ZW1haWwmdXRtX3NvdXJjZT1mb290ZXI==NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1=Zkk3SEhGNVYvcTlwampuRlN1VGhTVG1yWlJPdE83OHJpRjdpSHVNd1JnVT0==8d68f43f4a154531b39ff6816b335a07=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilb93oKaJ4TlYUgerrF37mdcvEPc0PHtDv6-pbmEIiTZTgZnnRSA2CyqseLQ7HmqwUlWlZc02dv_ipQ2a8ofXYw6w>.


--
Warm Regards,
Dipankar B.
--
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<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFdBwp-cO_g_JCTQhMQVEJe%2BN4FjJD5F-D%2B7LKugRK%2B1-Pq3Rg%40mail.gmail.com<https://us-east-2.protection.sophos.com?d=google.com=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9kL21zZ2lkL2RqYW5nby1kZXZlbG9wZXJzL0NBRmRCd3AtY09fZ19KQ1RRaE1RVkVKZSUyQk40RmpKRDVGLUQlMkI3TEt1Z1JLJTJCMS1QcTNSZyU0MG1haWwuZ21haWwuY29tP3V0bV9tZWRpdW09ZW1haWwmdXRtX3NvdXJjZT1mb290ZXI==NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1=MkhzRWVKR3MwQVlDOTBRTEdJc1dhT3ljQXRzaW1SMGV6Ryt3R3h3VDlsTT0==8d68f43f4a154531b39ff6816b335a07=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilb93oKaJ4TlYUgerrF37mdcvEPc0PHtDv6-pbmEIiTZTgZnnRSA2CyqseLQ7HmqwUlWlZc02dv_ipQ2

Re: Deprecate CICharField, CIEmailField, CITextField

[fly.a...@gmail.com]

Hey everyone!

Thanks for the discussion.
And special thanks @Adam, for the great article, helped us with the 
migration.

What I am struggling now with is whenever I specify 
`db_collation="case_insensitive"` on the field and this field is used in 
`ModelAdmin.search_fields` - Django simply breaks (as it by default uses 
`icontains` lookup).
That is quite unfortunate for the big projects, as I have to come up with 
some generic solution to something that was not broken before this feature 
deprecation (and the docs does not mention this case).
Good that Adam covered it in the article, but I feel that this could be 
handled on a lower level than right now. Currently, we'd need to write a 
manual annotation for admin queryset in almost every project that uses 
usernames or emails (which my guess is something you'd want to be 
case-insensitive on a database level).

I wonder how we could move forward (in case reverting this is not an 
option) and reduce overall aftermath stress.
For example, in terms of documentation, we could add a note on 
`db_collation` to `icontains` page:
https://docs.djangoproject.com/en/4.2/ref/models/querysets/#icontains

But I also feel that might not be enough.

Best,
Rust


On Tuesday, 18 April 2023 at 09:52:20 UTC+2 Johannes Maron wrote:

> Thanks Adam,
>
> of course I read your well-written article before diving into this topic, 
> thanks for sharing.
>
> However, I don't agree about the index. The best solution is using the 
> CITEXT db type, which is very much alive.
> Should Django to deprecate support for the db type, a 3rd party package 
> seems the bast choice for me.
> With the downside of me having to maintain yet another package. But I can 
> understand if the Django project has no interest in maintenance.
>
> In any event, I opened a ticket: 
> https://code.djangoproject.com/ticket/34501
>
> Best Joe
>
>
> On Fri, Apr 14, 2023 at 11:36 AM 'Adam Johnson' via Django developers 
> (Contributions to Django itself)  wrote:
>
>> Just to note, for anyone that finds it useful, that I wrote a blog post 
>> on migrating to collations: 
>> https://adamj.eu/tech/2023/02/23/migrate-django-postgresql-ci-fields-case-insensitive-collation/
>>
>> But yes, I have also been thinking like Tom that indexing UPPER("email") 
>> seems to be the path of least complexity...
>>
>> On Thu, Apr 13, 2023 at 8:12 AM Tom Carrick  wrote:
>>
>>> Hi,
>>>
>>> I wrote most of the code for collation support, and I also argued 
>>> (softly) against deprecating citext support for the reasons you stated.
>>>
>>> However, I've changed my mind on this now. As you can't index the citext 
>>> column for LIKE queries, doing these types of searches on any real amount 
>>> of data is going to be too slow in most cases. I actually think the best 
>>> practice right now for having searchable case-insensitive emails is to do 
>>> it old-school - have a regular EmailField with an index on UPPER("email") 
>>> and then make sure you always use iexact, istartswith etc. and this will 
>>> properly use the indexes and result in a faster search.
>>>
>>> So I see very few advantages now to keeping CITEXT at all, and they're 
>>> quite easy to add as a third party package as Mariusz suggested if anyone 
>>> is so inclined.
>>>
>>> Cheers,
>>> Tom
>>>
>>> On Wed, 12 Apr 2023 at 12:09, Mariusz Felisiak  
>>> wrote:
>>>
 Hi

 > Unless we want to drop support for the CITEXT extension, ...

 What do you mean by that? As far as I'm now, we don't do anything 
 special to support CITEXT extension 樂.

 > I'd caution to revert the deprecation and keep support ...

 I'm obviously biased as the author of this proposition and patch, 
 however, IMO, small differences between using CI fields and collations 
 don't justify maintaining 3 additional fields that were mostly untested. 
 Also, they are deprecated in a LTS so folks still have *3* more years 
 to update their code. In the worst case someone can create 3rd party 
 package with them.

 Unless something is fundamentally broken I'm against reverting.

 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-develop...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/5c11b704-68c4-490d-84bf-90c734cc02d1n%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 

Re: Django's automatic admin interface.

[Tom Carrick]

IMO, if we were going to modernise the admin (which is laudable), it
wouldn't be by using JS frameworks or Tailwind, but by simplifying things
further, by removing the last bits of JQuery, simplifying the HTML and
making it more semantic, and rewriting the CSS to use a grid based layout
and cut down the amount of code that is needed to achieve the same result.

I don't have anything against Tailwind or Vue per së, but forcing every
Django project to have them in the backend seems too opinionated and too
much of a maintenance burden.

As you mentioned, there are already opinionated packages out there, I'm
happy they exist, but in my opinion they belong in external packages, not
in core.

Tom

On Wed, 19 Apr 2023 at 11:45, Dipankar  wrote:

> Sorry if my question is wrong.. .. Not exactly technology I wanted to know
> about the frontend framework like tailwindCSS,react or Vue.
>
> In nutshell I want admin interface with tailwindCSS/React/Vue. any
> suggestion ?
>
> On Wed, Apr 19, 2023 at 3:01 PM David Sanders <
> shang.xiao.sand...@gmail.com> wrote:
>
>> Hi Dipankar,
>>
>> Not being rude but serious question: What's the latest front end
>> technology? :)
>>
>> On Wed, 19 Apr 2023, 7:27 pm Dipankar,  wrote:
>>
>>> Is there any plan to replace Django's automatic admin interface with the
>>> latest front end technology?
>>> There are several packages available but what if Django itself provides
>>> the same as core.
>>>
>>> --
>>> Warm Regards,
>>> Dipankar B.
>>>
>>> --
>>> 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/CAFdBwp_N0remvp8zAPFVda6iyFWVWR%3DZh0EtfE9fzYcPQVixkQ%40mail.gmail.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-61oX4oh3apDatm_MKCdoYCMLxkk8O4krKMZuPZF2LpNg%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Warm Regards,
> Dipankar B.
>
> --
> 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/CAFdBwp-cO_g_JCTQhMQVEJe%2BN4FjJD5F-D%2B7LKugRK%2B1-Pq3Rg%40mail.gmail.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/CAHoz%3DMY5g6fxw8DXCEhm%2BoQDW3isSCBGk7kYhdwB3Omdg4%3DjAQ%40mail.gmail.com.

Re: Django's automatic admin interface.

[Dipankar]

Sorry if my question is wrong.. .. Not exactly technology I wanted to know
about the frontend framework like tailwindCSS,react or Vue.

In nutshell I want admin interface with tailwindCSS/React/Vue. any
suggestion ?

On Wed, Apr 19, 2023 at 3:01 PM David Sanders 
wrote:

> Hi Dipankar,
>
> Not being rude but serious question: What's the latest front end
> technology? :)
>
> On Wed, 19 Apr 2023, 7:27 pm Dipankar,  wrote:
>
>> Is there any plan to replace Django's automatic admin interface with the
>> latest front end technology?
>> There are several packages available but what if Django itself provides
>> the same as core.
>>
>> --
>> Warm Regards,
>> Dipankar B.
>>
>> --
>> 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/CAFdBwp_N0remvp8zAPFVda6iyFWVWR%3DZh0EtfE9fzYcPQVixkQ%40mail.gmail.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-61oX4oh3apDatm_MKCdoYCMLxkk8O4krKMZuPZF2LpNg%40mail.gmail.com
> 
> .
>


-- 
Warm Regards,
Dipankar B.

-- 
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/CAFdBwp-cO_g_JCTQhMQVEJe%2BN4FjJD5F-D%2B7LKugRK%2B1-Pq3Rg%40mail.gmail.com.

Re: Django's automatic admin interface.

[David Sanders]

Hi Dipankar,

Not being rude but serious question: What's the latest front end
technology? :)

On Wed, 19 Apr 2023, 7:27 pm Dipankar,  wrote:

> Is there any plan to replace Django's automatic admin interface with the
> latest front end technology?
> There are several packages available but what if Django itself provides
> the same as core.
>
> --
> Warm Regards,
> Dipankar B.
>
> --
> 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/CAFdBwp_N0remvp8zAPFVda6iyFWVWR%3DZh0EtfE9fzYcPQVixkQ%40mail.gmail.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-61oX4oh3apDatm_MKCdoYCMLxkk8O4krKMZuPZF2LpNg%40mail.gmail.com.

Re: Production Django use and "real ip"

['st...@jigsawtech.co.uk' via Django developers (Contributions to Django itself)]

As someone whose worked on various projects in different languages over the 
last 15 years that heavily involved deciphering IP sent in headers to try 
to determine the "real" IP address of a connection, I would urge caution 
with anything around determining a "real IP". There is no standard in terms 
of where to look and what to trust. The X-FORWARDED-FOR is not always 
right, can easily be spoofed, it can include multiple IPs of which the 
order is not consistent. Sometimes the left most element is the first and 
"true IP", sometimes it's the right, sometimes its a value in the middle. 
It all depends what's included, what appended to the request, what the 
values are and what you want to trust/ignore. I've seen requests that 
include internal network IPs, then router/gateway IPs, proxy IPs and load 
balancers all within that head all in different orders.   It's especially 
messy when dealing with requests on mobile network where the carrier uses 
proxies, sometimes 3rd parties, and where your website is hosted behind 
both load balancers and webserver as each may manipulate the header in 
different ways.

One of the best packages within the Django eco-system for trying to 
identify a users actual external IP that I've come across is django-ipware 
. It allows you to choose the 
precedence order that matches your use case, yo have private IP prefixes, 
to configure how many proxies you wish to ignore etc. They also have a 
handy notice/disclaimer 
 on 
the subject.

IMO Django core should leave this 3rd party packages and individual 
deployments to decide and determine what they deem as being the source of 
the "real IP" for their individual project.



On Friday, 14 April 2023 at 10:13:22 UTC+1 Adam Johnson wrote:

> It's surprisingly complex to interpret x-forwarded-for: 
> https://www.brainonfire.net/blog/2022/03/04/understanding-using-xff/ . We 
> will never be able to safely add automated handling.
>
> I *guess* we could add a note to the deployment guide like "check your 
> HTTP_X_FORWARDED_FOR setting". I'm concerned it would be a step towards 
> making the guide too long, and filled with irrelevant details. Most sites 
> don't care about recording the user's IP. On those that do, it should be 
> easy enough to discover the setting.
>
> On Sat, Apr 1, 2023 at 4:39 AM Arthur Pemberton  wrote:
>
>> I have read previous discussions (most recent I could find was Dec 2013 
>>  [1] ) on the inclusion of `HTTP_X_FORWARDED_FOR` based logic to get the 
>> "real" IP address of an HttpRequest. From what I can see, currently there 
>> is currently no automatic handling of `HTTP_X_FORWARDED_FOR` in Django.
>>
>> However, I do notice that Django acknowledges `X_FORWARDED_HOST`, 
>> `X_FORWARDED_PORT` and (indirectly) `X_FORWARDED_PROTO`  
>> (though SECURE_PROXY_SSL_HEADER).
>>
>> If there is still opposition to having some built-in handling for 
>> `HTTP_X_FORWARDED_FOR`, I think that the deployment guide [1] should at 
>> least mention the need for the developer to handle this explicitly.
>>
>> Regards,
>> Arthur P.
>>
>> 
>>
>> [1] 
>> https://groups.google.com/g/django-developers/c/J5O28jB5D3Q/m/KLLgllFS7v0J
>> [2] https://docs.djangoproject.com/en/4.1/howto/deployment/
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%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/4f06664d-135e-4eb2-86ec-11eccf4cb495n%40googlegroups.com.

RE: Drop CSRF middleware from the settings template

[jure.erznoznik]

Well, TBH, I've just completed dealing with CSRF form in my projects. I ended 
up exempting the particular view from CSRF because I didn't know how to get the 
stuff to work. The problem was that django parsed the body payload, which was 
JSON and thus rejected its contents (because it wasn't form payload type – POST 
method). As a result, DRF then had no payload to work with… I shouldn't go into 
too much detail as it's irrelevant to the point.

 

But, I've been considering I need a modernised CSRF: currently it works by 
generating a new token every page served. But we have switched our front-end to 
SPA and that doesn't make much sense any more since CSRF token itself doesn't 
change at all, since Django template system only ever serves one page. AFAIK, 
DRF doesn't ganerate new tokens in its pipelines.

 

Takeaway: I don't think having CSRF enabled causes any significant downsides, 
even with a simpler, more modern handling. It does its thing regardless and 
doesn't interfere if it thinks everything is ok. Otherwise, it just saved your 
a** 

 

LP,

Jure

 

From: django-developers@googlegroups.com  
On Behalf Of Stratos Moros
Sent: torek, 18. april 2023 19:53
To: Django developers (Contributions to Django itself) 

Subject: Re: Drop CSRF middleware from the settings template

 

In my experience, even SameSite None is not sufficient to use cookies in 
cross-site iframes. Safari doesn't allow those cookies to be sent unless you 
visit the site directly first. I've heard movements for Firefox and/or Chrome 
having similar behavior, but I haven't been working with iframes recently 
enough to know the current state of that.

You are correct about this and I've been bitten by this in the past. 
(Un)fortunately, I am currently involved with enterprise™ projects where Safari 
is a distant afterthought.

There certainly are legitimate use-cases. I like Jacob's following suggestion 
for a check that might help alleviate a misconfiguration concern, if they did 
change SameSite to none without activating CSRF protection. If it were possible 
to identify other places where there might be a sharp-edge misconfiguration 
because of the cross-domain difference of meaning between samesite and what 
CSRF needs, that could be good as well. And those checks would, I think, be 
worthwhile even without changing the default, since they are currently possible 
configurations.

If CSRF is turned off by default, adding such a check would be a good idea. It 
should definitely check for SESSION_COOKIE_SAMESITE's value, since the session 
cookie is usually the one that needs protection from CSRF, but I haven't 
thought deeply about theotherthe cookies. This could have implications 
regarding HttpResponse.set_cookie, since it can't be checked by a system check.

I think what we want to weigh is whether the footgun of *not* having CSRF by 
default is bigger than the significant complexity overhead of managing the CSRF 
projection in a new project. It's marking all views, adding tags to all form 
templates, and I think it can be easy to underestimate the attention it 
requires. If we can eliminate this overhead, especially for beginners starting 
out with Django and web development, that sounds like a great benefit. Lowering 
the barrier to entry is worth a lot.

I mostly wanted to argue against the removal of the current CSRF machinery 
altogether, since it is still necessary for certain use cases.

Removing it from the default template is a harder question. I completely 
understand the complexity point, since I've lost track of how many times I've 
had to explain what a CSRF error is and why you should care. Still, I'm not 
sure if removing it from the default template would be OK, since it would trade 
off security for convenience (even if only for marginal cases).

Best,
Stratos

-- 
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 
<mailto:django-developers+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/A1CC86D7-24E6-457F-9B62-3FD4C82A775C%40gmail.com
 
<https://groups.google.com/d/msgid/django-developers/A1CC86D7-24E6-457F-9B62-3FD4C82A775C%40gmail.com?utm_medium=email_source=footer>
 .

-- 
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/009201d97238%2467e0a190%2437a1e4b0%24%40gmail.com.

Re: Drop CSRF middleware from the settings template

[Stratos Moros]

In my experience, even SameSite None is not sufficient to use cookies 
in cross-site iframes. Safari doesn't allow those cookies to be sent 
unless you visit the site directly first. I've heard movements for 
Firefox and/or Chrome having similar behavior, but I haven't been 
working with iframes recently enough to know the current state of 
that.


You are correct about this and I've been bitten by this in the past. 
(Un)fortunately, I am currently involved with enterprise™ projects 
where Safari is a distant afterthought.


There certainly are legitimate use-cases. I like Jacob's following 
suggestion for a check that might help alleviate a misconfiguration 
concern, if they did change SameSite to none without activating CSRF 
protection. If it were possible to identify other places where there 
might be a sharp-edge misconfiguration because of the cross-domain 
difference of meaning between samesite and what CSRF needs, that could 
be good as well. And those checks would, I think, be worthwhile even 
without changing the default, since they are currently possible 
configurations.


If CSRF is turned off by default, adding such a check would be a good 
idea. It should definitely check for `SESSION_COOKIE_SAMESITE`'s value, 
since the session cookie is usually the one that needs protection from 
CSRF, but I haven't thought deeply about theotherthe cookies. This could 
have implications regarding `HttpResponse.set_cookie`, since it can't be 
checked by a system check.


I think what we want to weigh is whether the footgun of *not* having 
CSRF by default is bigger than the significant complexity overhead of 
managing the CSRF projection in a new project. It's marking all views, 
adding tags to all form templates, and I think it can be easy to 
underestimate the attention it requires. If we can eliminate this 
overhead, especially for beginners starting out with Django and web 
development, that sounds like a great benefit. Lowering the barrier to 
entry is worth a lot.


I mostly wanted to argue against the removal of the current CSRF 
machinery altogether, since it is still necessary for certain use cases.


Removing it from the default template is a harder question. I completely 
understand the complexity point, since I've lost track of how many times 
I've had to explain what a CSRF error is and why you should care. Still, 
I'm not sure if removing it from the default template would be OK, since 
it would trade off security for convenience (even if only for marginal 
cases).


Best,
Stratos

--
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/A1CC86D7-24E6-457F-9B62-3FD4C82A775C%40gmail.com.

Re: Drop CSRF middleware from the settings template

['Ryan Hiebert' via Django developers (Contributions to Django itself)]

On Tuesday, April 18, 2023 at 8:34:14 AM UTC-5 Stratos Moros wrote:

[...] In my experience there are legitimate cases for setting 
SameSite=None, especially concerning iframes.

Specifically, when developing a web app intended to be embedded as an 
iframe by a different top-level origin, you can't really use cookies unless 
their SameSite attribute is None. This is the case even if you manage the 
cookies entirely inside the iframe and its origin.

In my experience, even SameSite None is not sufficient to use cookies in 
cross-site iframes. Safari doesn't allow those cookies to be sent unless 
you visit the site directly first. I've heard movements for Firefox and/or 
Chrome having similar behavior, but I haven't been working with iframes 
recently enough to know the current state of that.

In such cases, you really do need Django's current CSRF protection. 
Personally I wouldn't mind it being off by default, since SameSite=Lax 
seems to be enough for most cases, but this could be a footgun for some 
people.

There certainly are legitimate use-cases. I like Jacob's following 
suggestion for a check that might help alleviate a misconfiguration 
concern, if they did change SameSite to none without activating CSRF 
protection. If it were possible to identify other places where there might 
be a sharp-edge misconfiguration because of the cross-domain difference of 
meaning between samesite and what CSRF needs, that could be good as well. 
And those checks would, I think, be worthwhile even without changing the 
default, since they are currently possible configurations.

I think what we want to weigh is whether the footgun of *not* having CSRF 
by default is bigger than the significant complexity overhead of managing 
the CSRF projection in a new project. It's marking all views, adding tags 
to all form templates, and I think it can be easy to underestimate the 
attention it requires. If we can eliminate this overhead, especially for 
beginners starting out with Django and web development, that sounds like a 
great benefit. Lowering the barrier to entry is worth a lot.

-- 
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/553aea07-90de-41ce-a71c-6529ebc97eb3n%40googlegroups.com.

Re: Drop CSRF middleware from the settings template

[Jacob Rief]

In such cases, you really do need Django's current CSRF protection. 
Personally I wouldn't mind it being off by default, since SameSite=Lax 
seems to be enough for most cases, but this could be a footgun for some 
people.


This could be handled by the configuration checker, which runs after 
reading the setup. Whenever CSRF_COOKIE_SAMESITE=None but 
'django.middleware.csrf.CsrfViewMiddleware' is missing in the MIDDLEWARE 
 
setting, a warning shall be issued.

– Jacob
 

-- 
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/4e9c5627-3f29-48aa-bf4d-65ec4df179e8n%40googlegroups.com.

Re: Drop CSRF middleware from the settings template

[Stratos Moros]

Hello Everyone,

Looks like lax will do the trick, but it's not like there aren't legit 
cases for same-site policy to be set to something less restrictive.


I agree. In my experience there are legitimate cases for setting 
SameSite=None, especially concerning iframes.


Specifically, when developing a web app intended to be embedded as an 
iframe by a different top-level origin, you can't really use cookies 
unless their SameSite attribute is None. This is the case even if you 
manage the cookies entirely inside the iframe and its origin.


In such cases, you really do need Django's current CSRF protection. 
Personally I wouldn't mind it being off by default, since SameSite=Lax 
seems to be enough for most cases, but this could be a footgun for some 
people.


Best,
Stratos


On 17 Apr 2023, at 10:55, Jure Erznožnik wrote:


https://security.stackexchange.com/questions/262245/are-csrf-attacks-a-thing-of-the-past

Looks like lax will do the trick, but it's not like there aren't legit 
cases for same-site policy to be set to something less restrictive.


LP,
Jure

On 17. 04. 23 09:24, Jacob Rief wrote:

On Monday, April 17, 2023 at 8:45:16 AM UTC+2 Curtis Maloney wrote:

Are you implying that all CSRF attacks protected by Django's
current machinery are entirely mitigated by SameSite=Lax on the
_session_ cookiue?

Yes. Therefore imho, the CSRF protection is just some nasty legacy, 
developers have to fiddle with. It doesn't add any security benefit 
anymore.
That said, maybe there is still a possible attack vector on cross 
site request forgeries, but I was unable to exploit them with 
disabled CSRF protection.
Therefore it would be great, if someone with more hacking experience 
than myself, could try this.


– Jacob
--
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/18aaa4cf-4612-4373-bd91-90cfb3fd07b8n%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/86ced442-e7f9-aab8-9a03-d9c2362b60f9%40gmail.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/CA2FC1A6-4307-4076-B158-197D8A9481B6%40gmail.com.

Re: Deprecate CICharField, CIEmailField, CITextField

['Johannes Maron' via Django developers (Contributions to Django itself)]

Thanks Adam,

of course I read your well-written article before diving into this topic,
thanks for sharing.

However, I don't agree about the index. The best solution is using the
CITEXT db type, which is very much alive.
Should Django to deprecate support for the db type, a 3rd party package
seems the bast choice for me.
With the downside of me having to maintain yet another package. But I can
understand if the Django project has no interest in maintenance.

In any event, I opened a ticket: https://code.djangoproject.com/ticket/34501

Best Joe


On Fri, Apr 14, 2023 at 11:36 AM 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> Just to note, for anyone that finds it useful, that I wrote a blog post on
> migrating to collations:
> https://adamj.eu/tech/2023/02/23/migrate-django-postgresql-ci-fields-case-insensitive-collation/
>
> But yes, I have also been thinking like Tom that indexing UPPER("email")
> seems to be the path of least complexity...
>
> On Thu, Apr 13, 2023 at 8:12 AM Tom Carrick  wrote:
>
>> Hi,
>>
>> I wrote most of the code for collation support, and I also argued
>> (softly) against deprecating citext support for the reasons you stated.
>>
>> However, I've changed my mind on this now. As you can't index the citext
>> column for LIKE queries, doing these types of searches on any real amount
>> of data is going to be too slow in most cases. I actually think the best
>> practice right now for having searchable case-insensitive emails is to do
>> it old-school - have a regular EmailField with an index on UPPER("email")
>> and then make sure you always use iexact, istartswith etc. and this will
>> properly use the indexes and result in a faster search.
>>
>> So I see very few advantages now to keeping CITEXT at all, and they're
>> quite easy to add as a third party package as Mariusz suggested if anyone
>> is so inclined.
>>
>> Cheers,
>> Tom
>>
>> On Wed, 12 Apr 2023 at 12:09, Mariusz Felisiak <
>> felisiak.mari...@gmail.com> wrote:
>>
>>> Hi
>>>
>>> > Unless we want to drop support for the CITEXT extension, ...
>>>
>>> What do you mean by that? As far as I'm now, we don't do anything
>>> special to support CITEXT extension 樂.
>>>
>>> > I'd caution to revert the deprecation and keep support ...
>>>
>>> I'm obviously biased as the author of this proposition and patch,
>>> however, IMO, small differences between using CI fields and collations
>>> don't justify maintaining 3 additional fields that were mostly untested.
>>> Also, they are deprecated in a LTS so folks still have *3* more years
>>> to update their code. In the worst case someone can create 3rd party
>>> package with them.
>>>
>>> Unless something is fundamentally broken I'm against reverting.
>>>
>>> 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/5c11b704-68c4-490d-84bf-90c734cc02d1n%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/CAHoz%3DMb25iGN%2BHodxgE6Y%2B5d%2B5qoHERvkMiuiHrs%3DXnpeC%3D-xg%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/nDMnO98nexY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAMyDDM3PuF92jEdTocGPtG%2Bq0n%2B%3DfRfZ05gTw8w3T6kZ5p6xBQ%40mail.gmail.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 

Re: Oracle 23c released earlier this month

[charettes]

Thanks for sharing the news David!

Support for true BOOLEAN type and GROUP BY position are effectively very 
welcome changes as they account for a few hacks. I do wonder if that's 
paving the way for grouping by subquery in future versions.

Best,
Simon

Le lundi 17 avril 2023 à 08:06:57 UTC-4, Mariusz Felisiak a écrit :

> Hi,
>
>   Thanks! Also, they finally update VM: 
> https://www.oracle.com/database/technologies/databaseappdev-vm.html 
>   We still have to wait for a compatible driver, cx_Oracle and 
> python-oracledb don't support it yet.
>
> 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/22e7a2d5-7bed-4938-81fd-d6074b13f300n%40googlegroups.com.

Re: Fellow Reports - April 2023

[Natalia Bidart]

Week ending 2023-04-16 (Week 16)

Triaged:
  https://code.djangoproject.com/ticket/34490 - Tests with mirror database
not working as expected (invalid)
  https://code.djangoproject.com/ticket/34489 - feature: Support for
PostgreSQL table partitioning (needsinfo)

Reviewed:
  https://github.com/django/django/pull/16726 - Solved #10743: Support
lookup separators
  https://github.com/django/django/pull/16756 - Fixed #34484, Fixed #34482
-- Fixed cloning/deep cloning HttpRequest, HttpResponse, and their
subclasses.
  https://github.com/django/django/pull/16759 - Fixed #22569 -- Made
ModelAdmin.lookup_allowed() respect get_list_filter().

Authored:
  https://github.com/django/djangoproject.com/pull/1346 - Fixed #1341 --
Updated info about past and present Django Fellows.
  https://github.com/django/django/pull/16756 - Fixed #34483 -- Fixed
timesince()/timeuntil() with timezone-aware dates and interval less than 1
day.

Other/Misc:
  Security mailing list monitoring and follow ups
  More docs reading
  Setup access to various services and projects
  Investigated and commented on https://code.djangoproject.com/ticket/32847
- Adjust models.E025 system check for updated field descriptor setting.

Cheers! Natalia.

On Tue, Apr 11, 2023 at 10:52 AM Natalia Bidart 
wrote:

> Week ending April 9, 2023
>
> Hello! I'm Natalia (AKA nessita), the new Django Fellow. I officially
> started on April 1st (really :-)) though I had a slow start since I had a
> long-time planned vacation.
>
> So far I have held catch up calls with both current and former Django
> Fellows (thanks Mariusz and Carlton for your patience and support!), and I
> have been deep diving into documentation.
>
> I'm looking forward to working with you all!
>
> Thank you!
> Natalia.
>

-- 
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/CA%2BfOnFbfvPxU7fPr5gVhcgzm7sTm%3Dj0NYqY7rZLvHy9aFSWbvQ%40mail.gmail.com.

Re: Oracle 23c released earlier this month

[Mariusz Felisiak]

Hi,

  Thanks! Also, they finally update VM: 
https://www.oracle.com/database/technologies/databaseappdev-vm.html 
  We still have to wait for a compatible driver, cx_Oracle and 
python-oracledb don't support it yet.

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/325ce2ee-fbeb-48b5-84c7-5b70cb6c8d99n%40googlegroups.com.

Re: Select API choice when starting new project.

[Daniel Azubuine]

thank you i didn't know.


On Mon, Apr 17, 2023 at 8:26 AM Florian Apolloner 
wrote:

> Hi, this is something which is already supported via the template argument
> to startproject/startapp.
>
> Cheers,
> florian
>
> On Sunday, April 16, 2023 at 11:47:44 PM UTC+2 Daniel Azubuine wrote:
>
>> When starting a new Django project, the user can select if he wants to
>> build an API or use the Django template.
>> If he chooses API, then Django-rest framework will be installed, and then
>> serializers.py will be added to the folders.
>>
>>
>> --
> 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/e6df6bae-b417-4a0c-97bd-c2de927728dcn%40googlegroups.com
> 
> .
>


-- 

Best regards,
[image: Daniel Azubuine]
[image: photo]
Daniel Azubuine
He/Him
Music Composer and Software Engineer, Dflat

+2349071177001  |  azubuinedanie...@gmail.com
[image: github]  [image: facebook]
 [image: linkedin]
 [image: twitter]


"Love, Trust, Few A fool thinks himself to be wise, but a wise man knows
himself to be a fool." - William Shakespeare
Create your own email signature


-- 
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/CAHRz_NZN4%3D8g7zbUPUbrQicyUH17eAyXbeWQfUsfPvax1ix5eQ%40mail.gmail.com.

Re: Fellow Reports - April 2023

[Mariusz Felisiak]

Week ending April 16, 2023

*Triaged:*
https://code.djangoproject.com/ticket/34480 - Annotating with Chr 
raises ValueError (accepted)
https://code.djangoproject.com/ticket/34481 - Admin check for reversed 
foreign key used in "list_display" (accepted)
https://code.djangoproject.com/ticket/34482 - Unable to access 
"non-picklable" attributes of empty HttpRequest and HttpResponse objects 
after shallow copy. (accepted)
https://code.djangoproject.com/ticket/34483 - Negative result of 
django.utils.timesince.timesince (accepted)
https://code.djangoproject.com/ticket/34486 - SearchHeadline crashes 
without an active connection. (accepted)
https://code.djangoproject.com/ticket/34484 - HttpRequest.__deepcopy__ 
doesn't deepcopy attributes (accepted)
https://code.djangoproject.com/ticket/34487 - Django crashes due to 
ManifestStaticFilesStorage plugin in 4.2 (needsinfo)
https://code.djangoproject.com/ticket/34488 - ClearableFileInput widget 
forgets "Clear" selection when form is not valid (duplicate)
https://code.djangoproject.com/ticket/34492 - I get an error when using 
BinaryField in sqllite3. (invalid)
https://code.djangoproject.com/ticket/34491 - Unable to have 
constraints with same name on different models (wontfix)
https://code.djangoproject.com/ticket/34493 - wrong translation 
(invalid)
https://code.djangoproject.com/ticket/34494 - This is suggestion about 
customizing AdminSite documents (invalid)
https://code.djangoproject.com/ticket/34496 - 
ManifestStaticFilesStorage.patterns for sourceMappingURL does not retrieve 
matched line to return for for example data URI (needsinfo)
https://code.djangoproject.com/ticket/34498 - error 403 in login in 
django (invalid)
https://code.djangoproject.com/ticket/34495 - Queryset update fails 
when updating parent model field with default ordering on MySQL backend 
(worksforme)
https://code.djangoproject.com/ticket/34499 - In tutorial part08, 
Django debug toolbar shows up in admin site but not in public site (wontfix)

*Reviewed/committed:*
https://github.com/django/django/pull/16735 - Fixed #34455 -- Restored 
i18n_patterns() respect of prefix_default_language argument when fallback 
language is used.
https://github.com/django/django/pull/16750 - Fixed #34480 -- Fixed 
crash of annotations with Chr().
https://github.com/django/djangoproject.com/pull/1346 - Fixed #1341 -- 
Updated info about past and present Django Fellows.
https://github.com/django/django/pull/16749 - Fixed #34394 -- Made 
ASGIRequest respect FORCE_SCRIPT_NAME.
https://github.com/django/django/pull/16746 - Fixed #27505 -- Allowed 
customizing Paginator's error messages.
https://github.com/django/django/pull/16760 - Fixed #34486 -- Fixed 
DatabaseOperations.compose_sql() crash with no existing database connection 
on PostgreSQL.
https://github.com/django/django/pull/16712 - Fixed #34419 -- Doc'd 
django.contrib.admin.sites.all_sites.

*Reviewed:*
https://github.com/django/django/pull/16756 - Fixed #34483 -- Fixed 
timesince()/timeuntil() with timezone-aware dates and interval less than 1 
day.

*Authored:*
https://github.com/django/django/pull/16755 - Fixed #34484, Fixed 
#34482 -- Fixed cloning/deep cloning HttpRequest, HttpResponse, and their 
subclasses.
https://github.com/django/django/pull/16763 - [4.2.x] Refs #34483 -- 
Fixed utils_tests.test_timesince crash on Python 3.8.
https://github.com/django/django/pull/16764 - Refs #34483 -- Fixed 
timesince()/timeuntil() with timezone-aware dates on different days and 
interval less than 1 day.

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/c9d37891-9499-46bb-9660-34e40a054a39n%40googlegroups.com.

Re: Drop CSRF middleware from the settings template

[Jure Erznožnik]

https://security.stackexchange.com/questions/262245/are-csrf-attacks-a-thing-of-the-past

Looks like lax will do the trick, but it's not like there aren't legit 
cases for same-site policy to be set to something less restrictive.


LP,
Jure

On 17. 04. 23 09:24, Jacob Rief wrote:

On Monday, April 17, 2023 at 8:45:16 AM UTC+2 Curtis Maloney wrote:

Are you implying that all CSRF attacks protected by Django's
current machinery are entirely mitigated by SameSite=Lax on the
_session_ cookiue?

Yes. Therefore imho, the CSRF protection is just some nasty legacy, 
developers have to fiddle with. It doesn't add any security benefit 
anymore.
That said, maybe there is still a possible attack vector on cross site 
request forgeries, but I was unable to exploit them with disabled CSRF 
protection.
Therefore it would be great, if someone with more hacking experience 
than myself, could try this.


– Jacob
--
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/18aaa4cf-4612-4373-bd91-90cfb3fd07b8n%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/86ced442-e7f9-aab8-9a03-d9c2362b60f9%40gmail.com.

Re: Select API choice when starting new project.

[Florian Apolloner]

Hi, this is something which is already supported via the template argument 
to startproject/startapp.

Cheers,
florian

On Sunday, April 16, 2023 at 11:47:44 PM UTC+2 Daniel Azubuine wrote:

> When starting a new Django project, the user can select if he wants to 
> build an API or use the Django template. 
> If he chooses API, then Django-rest framework will be installed, and then 
> serializers.py will be added to the folders.
>
>
>

-- 
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/e6df6bae-b417-4a0c-97bd-c2de927728dcn%40googlegroups.com.

Re: Proposal: Constructing urls outside the request cycle

[Florian Apolloner]

On Sunday, April 16, 2023 at 10:21:20 AM UTC+2 Adam Johnson wrote:

One question though, how will we support projects that are served at 
multiple domains? Would Django only support the "main" site through 
BASE_URL and require you to perform URL construction for other domains as 
required?


As usual it depends (tm) :D As long as `reverse` keeps generating URLs 
without a host then we'd only use BASE_URL as a fallback in certain cases 
where no request is available. In the longrun I'd love to support something 
along the lines of 
https://werkzeug.palletsprojects.com/en/2.2.x/routing/#werkzeug.routing.Subdomain
 and 
then `reverse` would probably be able to generate the proper URLs. But yes, 
there are certainly many things to think about.

-- 
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/bd70d579-9ad9-4102-bcb2-20bab28f1783n%40googlegroups.com.

Re: Drop CSRF middleware from the settings template

[Jacob Rief]

On Monday, April 17, 2023 at 8:45:16 AM UTC+2 Curtis Maloney wrote:

Are you implying that all CSRF attacks protected by Django's current 
machinery are entirely mitigated by SameSite=Lax on the _session_ cookiue?

Yes. Therefore imho, the CSRF protection is just some nasty legacy, 
developers have to fiddle with. It doesn't add any security benefit anymore.
That said, maybe there is still a possible attack vector on cross site 
request forgeries, but I was unable to exploit them with disabled CSRF 
protection.
Therefore it would be great, if someone with more hacking experience than 
myself, could try this.

– Jacob

-- 
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/18aaa4cf-4612-4373-bd91-90cfb3fd07b8n%40googlegroups.com.

Re: Drop CSRF middleware from the settings template

[Curtis Maloney]

On Mon, 17 Apr 2023, at 04:25, 'Ryan Hiebert' via Django developers  
(Contributions to Django itself) wrote:
> I've recently been working with other new frameworks, particularly Remix. 
> Coming from Django, which has had excellent CSRF for many years, one of my 
> first questions was how to handle CSRF protection. And the response I got 
> lead me to the "Lax" SameSite cookie parameter, and that I really wouldn't 
> need more than that for the session cookie.

I think I missed a detail here.

What problem are you having with using CSRF?

What response did you get?

Was it different to what's in the Django docs here ?
https://docs.djangoproject.com/en/4.2/howto/csrf/#using-csrf-protection-with-ajax

> 
> It appears that Django has defaulted the session cookie to `Lax` since the 
> SESSION_COOKIE_SAMESITE parameter was added in Django 2.1. All current 
> browsers seem to have supported it since 2019. Is it time for us to remove 
> the CSRF Middleware from the default settings template file?

Are you implying that all CSRF attacks protected by Django's current machinery 
are entirely mitigated by SameSite=Lax on the _session_ cookiue?

--
Curtis

-- 
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/2398009a-928d-444e-888e-ed901f2b55de%40app.fastmail.com.

Re: Drop CSRF middleware from the settings template

[Jacob Rief]

Actually, I attempted to forge POST requests on Django with disabled CSRF 
protection – and failed.
Maybe I wasn't creative enough, but modern browsers do indeed have a good 
protection against this attack vector.
I therefore welcome this proposal, unless someone can show how to bypass 
this protection.
– Jacob

-- 
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/2b349cdb-7502-4d6d-b299-cf62e1edc265n%40googlegroups.com.

Re: Proposal: Check constraints at the model field level

[David Sanders]

Hi Adam, Mariusz & Simon,

> The only thing I'm not a fan of in your proposal is repeating the field
name within the check expression, like "price" in
> ... 8< ...
> Perhaps we could support only a special name instead, like “self” or the
shorter “f”?

I was thinking the same thing +1  I wanted to throw up the proposal to
elicit ideas on this because I wasn't sure whether reserving a field name
like this might've been the way to go 樂


> but it should be noted that SQL has both CHECK on the field and table
level
and from Simon:
> CREATE TABLE / ADD COLUMN checks on the field level are really just
syntactic sugar for checks at the table level

Simon is correct here in that checks at column & table level are both
declarations for the same underlying mechanism (at least from what I've
seen with Postgres & MySQL).


> This proposal is not really nice from a maintenance point of view

Felix if there was no maintenance headache would it sound like a good idea
though? What if there was some way to make it work nicely? I was wondering
what ways that could be achieved:
 - if you use db_check() then there's no migration state conflict; only
potential conflict in the database which would be resolved with unique
constraint naming.
 - as an alternative could it somehow then be syntactic sugar to add to
meta.constraints? this would then have the benefit of automatically being
added to validation. The catch is migrations would need to take the fact
that fields could add to meta into consideration because from what I've
seen it keeps track of the "original" user-defined meta options.


On Fri, 7 Apr 2023 at 04:55, charettes  wrote:

> Small clarification here.
>
> > it should be noted that SQL has both CHECK on the field and table level,
>
> From my understanding CREATE TABLE / ADD COLUMN checks on the field level
> are really just syntactic sugar for checks at the table level like just
> like `REFERENCES` usage is syntactic sugar for foreign key constraints.
>
> > This is not true for unique constraints or indices.
>
> Unique constraints can be defined using the UNIQUE keyword just like CHECK
> is used to define a check per field, it's really just a different way of
> defining that a unique constraint on a field must be created.
>
> The question of whether or not we want to provide some Django syntactic
> sugar in the form of `Field.check` and the benefits it might provide to
> third-parties (and even ourselves for dog fooding PositiveIntegerField)
> remains but I think that it's important to point out that there's no
> distinction between field and table level constraints at the database level
> AFAIK (for Postgres and SQLite at least).
>
> Simon
> Le jeudi 6 avril 2023 à 01:47:48 UTC-4, Adam Johnson a écrit :
>
>> Mariusz, I agree with the burden, but it should be noted that SQL has
>> both CHECK on the field and table level, and CheckConstraint only defines
>> table-level constraints. This is not true for unique constraints or indices.
>>
>> Also, what do you think of a way for custom field classes to add
>> constraints, at least? db_check() is somewhat limiting given it must return
>> raw SQL, plus it's undocumented.
>>
>> On Thu, Apr 6, 2023 at 5:11 AM Mariusz Felisiak 
>> wrote:
>>
>>> Hi,
>>>
>>> This proposal is not really nice from a maintenance point of view as we
>>> will end with the same complicated situation we currently have with
>>> uniqueness checks or indexes i.e. many ways to define the same:
>>>
>>> - Field.unique/index
>>> - Meta.unique_together/index_together
>>> - Meta.constraints/indexes
>>>
>>> It's especially error-prone in migrations and different database
>>> behavior on fields already covered by the same constraints/indexes. I'm
>>> pretty sure that we've introduced Meta.contraints/indexes to avoid this
>>> happening in the future, and we are rather leaning to leave only
>>> Meta.constraints/indexes and remove other options in the future. Not
>>> creating a new one.
>>>
>>> Initial -1 from me.
>>>
>>> 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-develop...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/954af838-2176-4877-b4ac-70525cddcbf5n%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
> 

Re: Proposal: Constructing urls outside the request cycle

['Adam Johnson' via Django developers (Contributions to Django itself)]

A setting isn't so mad. Many Django projects I've seen use a similar custom
setting for constructing URLs outside of requests.

One question though, how will we support projects that are served at
multiple domains? Would Django only support the "main" site through
BASE_URL and require you to perform URL construction for other domains as
required?

On Thu, Apr 6, 2023 at 8:11 AM Sarah Boyce  wrote:

> Hello 
>
> This is a summary of some previous discussions which need opening up to
> the group 
>
> There is a need to have some kind of URL outside the request cycle (such
> as sending emails which need to create a link).
> For constructing a correct MEDIA_URL / STATIC_URL we wanted to use the
> script prefix to allow for more dynamic changes (ie allow a user to move to
> a subpath without having to change multiple variables). In the request
> cycle you can use get_script_prefix() for this but outside the request
> cycle this isn't currently very achievable (see related tickets #34028
>  #16734
> ).
>
> There is a current proposal from @Florian Apolloner:
> "I am really starting to lean towards introducing a setting (yes!) called
> BASE_URL that can be set to https://mysite.com/subpath. This would allow
> for a) generating URLs outside a request context and b) allow us to mostly
> ignore script prefix. We could also use a relative STATIC_URL and append it
> to BASE_URL. This way there would be just one setting that requires
> changing and many projects hopefully would make that configurable via env
> vars etc."
>
> New settings are a little controversial, so what do you think about this
> approach? Are there any other ideas or concerns?
>
> --
> 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/df82f370-e96a-498c-ac08-89d34d5cadd5n%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/CAMyDDM1Hwy5rd1j36BLt%3DeHzqaae6ypNqh_DYYZwfFAqg0f%2B7A%40mail.gmail.com.

Re: Deprecate CICharField, CIEmailField, CITextField

['Adam Johnson' via Django developers (Contributions to Django itself)]

Just to note, for anyone that finds it useful, that I wrote a blog post on
migrating to collations:
https://adamj.eu/tech/2023/02/23/migrate-django-postgresql-ci-fields-case-insensitive-collation/

But yes, I have also been thinking like Tom that indexing UPPER("email")
seems to be the path of least complexity...

On Thu, Apr 13, 2023 at 8:12 AM Tom Carrick  wrote:

> Hi,
>
> I wrote most of the code for collation support, and I also argued (softly)
> against deprecating citext support for the reasons you stated.
>
> However, I've changed my mind on this now. As you can't index the citext
> column for LIKE queries, doing these types of searches on any real amount
> of data is going to be too slow in most cases. I actually think the best
> practice right now for having searchable case-insensitive emails is to do
> it old-school - have a regular EmailField with an index on UPPER("email")
> and then make sure you always use iexact, istartswith etc. and this will
> properly use the indexes and result in a faster search.
>
> So I see very few advantages now to keeping CITEXT at all, and they're
> quite easy to add as a third party package as Mariusz suggested if anyone
> is so inclined.
>
> Cheers,
> Tom
>
> On Wed, 12 Apr 2023 at 12:09, Mariusz Felisiak 
> wrote:
>
>> Hi
>>
>> > Unless we want to drop support for the CITEXT extension, ...
>>
>> What do you mean by that? As far as I'm now, we don't do anything special
>> to support CITEXT extension 樂.
>>
>> > I'd caution to revert the deprecation and keep support ...
>>
>> I'm obviously biased as the author of this proposition and patch,
>> however, IMO, small differences between using CI fields and collations
>> don't justify maintaining 3 additional fields that were mostly untested.
>> Also, they are deprecated in a LTS so folks still have *3* more years to
>> update their code. In the worst case someone can create 3rd party package
>> with them.
>>
>> Unless something is fundamentally broken I'm against reverting.
>>
>> 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/5c11b704-68c4-490d-84bf-90c734cc02d1n%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/CAHoz%3DMb25iGN%2BHodxgE6Y%2B5d%2B5qoHERvkMiuiHrs%3DXnpeC%3D-xg%40mail.gmail.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/CAMyDDM3PuF92jEdTocGPtG%2Bq0n%2B%3DfRfZ05gTw8w3T6kZ5p6xBQ%40mail.gmail.com.

Re: Production Django use and "real ip"

['Adam Johnson' via Django developers (Contributions to Django itself)]

It's surprisingly complex to interpret x-forwarded-for:
https://www.brainonfire.net/blog/2022/03/04/understanding-using-xff/ . We
will never be able to safely add automated handling.

I *guess* we could add a note to the deployment guide like "check your
HTTP_X_FORWARDED_FOR setting". I'm concerned it would be a step towards
making the guide too long, and filled with irrelevant details. Most sites
don't care about recording the user's IP. On those that do, it should be
easy enough to discover the setting.

On Sat, Apr 1, 2023 at 4:39 AM Arthur Pemberton  wrote:

> I have read previous discussions (most recent I could find was Dec 2013
>  [1] ) on the inclusion of `HTTP_X_FORWARDED_FOR` based logic to get the
> "real" IP address of an HttpRequest. From what I can see, currently there
> is currently no automatic handling of `HTTP_X_FORWARDED_FOR` in Django.
>
> However, I do notice that Django acknowledges `X_FORWARDED_HOST`,
> `X_FORWARDED_PORT` and (indirectly) `X_FORWARDED_PROTO`
> (though SECURE_PROXY_SSL_HEADER).
>
> If there is still opposition to having some built-in handling for
> `HTTP_X_FORWARDED_FOR`, I think that the deployment guide [1] should at
> least mention the need for the developer to handle this explicitly.
>
> Regards,
> Arthur P.
>
> 
>
> [1]
> https://groups.google.com/g/django-developers/c/J5O28jB5D3Q/m/KLLgllFS7v0J
> [2] https://docs.djangoproject.com/en/4.1/howto/deployment/
>
> --
> 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/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%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/CAMyDDM2zStXs8eHk5icicfdfGJtYT%3DeQaQK%3DHST0cmL4Yd1WCg%40mail.gmail.com.

Re: Deprecate CICharField, CIEmailField, CITextField

[Tom Carrick]

Hi,

I wrote most of the code for collation support, and I also argued (softly)
against deprecating citext support for the reasons you stated.

However, I've changed my mind on this now. As you can't index the citext
column for LIKE queries, doing these types of searches on any real amount
of data is going to be too slow in most cases. I actually think the best
practice right now for having searchable case-insensitive emails is to do
it old-school - have a regular EmailField with an index on UPPER("email")
and then make sure you always use iexact, istartswith etc. and this will
properly use the indexes and result in a faster search.

So I see very few advantages now to keeping CITEXT at all, and they're
quite easy to add as a third party package as Mariusz suggested if anyone
is so inclined.

Cheers,
Tom

On Wed, 12 Apr 2023 at 12:09, Mariusz Felisiak 
wrote:

> Hi
>
> > Unless we want to drop support for the CITEXT extension, ...
>
> What do you mean by that? As far as I'm now, we don't do anything special
> to support CITEXT extension 樂.
>
> > I'd caution to revert the deprecation and keep support ...
>
> I'm obviously biased as the author of this proposition and patch, however,
> IMO, small differences between using CI fields and collations don't justify
> maintaining 3 additional fields that were mostly untested. Also, they are
> deprecated in a LTS so folks still have *3* more years to update their
> code. In the worst case someone can create 3rd party package with them.
>
> Unless something is fundamentally broken I'm against reverting.
>
> 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/5c11b704-68c4-490d-84bf-90c734cc02d1n%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/CAHoz%3DMb25iGN%2BHodxgE6Y%2B5d%2B5qoHERvkMiuiHrs%3DXnpeC%3D-xg%40mail.gmail.com.

Re: Deprecate CICharField, CIEmailField, CITextField

[Mariusz Felisiak]

Hi

> Unless we want to drop support for the CITEXT extension, ...

What do you mean by that? As far as I'm now, we don't do anything special 
to support CITEXT extension 樂.

> I'd caution to revert the deprecation and keep support ...

I'm obviously biased as the author of this proposition and patch, however, 
IMO, small differences between using CI fields and collations don't justify 
maintaining 3 additional fields that were mostly untested. Also, they are 
deprecated in a LTS so folks still have *3* more years to update their 
code. In the worst case someone can create 3rd party package with them.

Unless something is fundamentally broken I'm against reverting.

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/5c11b704-68c4-490d-84bf-90c734cc02d1n%40googlegroups.com.

Re: Deprecate CICharField, CIEmailField, CITextField

['Johannes Maron' via Django developers (Contributions to Django itself)]

Hi there,

I am sorry that I missed this in the alpha. But to the best of my 
knowledge, CITEXT and non-deterministic collations are not the same. They 
don't support the same operations and their string comparison operations 
are similar, yet not identical.
Furthermore, PostgreSQL doesn't discourage the use of CITEXT, but hints 
towards a native alternative. That's maybe more than just a subtle 
difference.

99% of all use-cases might be email, but even email LIKE-queries would be 
affected (good for +-searches).

Unless we want to drop support for the CITEXT extension, collations might 
not be a sufficient replacement.

I'd caution to revert the deprecation and keep support unless we make an 
informed decision to drop CITEXT for a 3rd party integration.

Best
Joe!




On Monday, August 8, 2022 at 11:49:25 AM UTC+2 Mariusz Felisiak wrote:

> As far as I'm aware you can use:
>
>  CreateCollation("case_insensitive", "und-u-ks-level2", 
> provider="icu", deterministic=False)
>
> to create a case insensitive collation on PostgreSQL. 
>
>

-- 
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/20278136-dbbe-4bc1-9f86-3b6f671c83d9n%40googlegroups.com.

Re: Fellow Reports - April 2023

[Paolo Melchiorre]

Welcome Natalia 珞

On Tue, Apr 11, 2023, 17:04 Natalia Bidart  wrote:

> Week ending April 9, 2023
>
> Hello! I'm Natalia (AKA nessita), the new Django Fellow. I officially
> started on April 1st (really :-)) though I had a slow start since I had a
> long-time planned vacation.
>
> So far I have held catch up calls with both current and former Django
> Fellows (thanks Mariusz and Carlton for your patience and support!), and I
> have been deep diving into documentation.
>
> I'm looking forward to working with you all!
>
> Thank you!
> Natalia.
>
> --
> 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/CA%2BfOnFbRDqYGpBGPTB28EknOuP8PQcAJTvYwNGuqNKmL0zeHtQ%40mail.gmail.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/CAKFO%2Bx5wD9E8uiMFPMhSkQwotwAC4CKFMH_CQR6gkVW3U65P1A%40mail.gmail.com.

Re: Django "makemigrations -- update" donot working

['Adam Johnson' via Django developers (Contributions to Django itself)]

Indeed, David is right. The --update flag is intended for developing a
feature branch and adding extra changes to a work-in-progress migration.
This is why it requires the migration to not be applied.

On Sun, Apr 9, 2023 at 9:20 PM David Wobrock 
wrote:

> Hi,
>
> As you can see, the error message seems quite clear:
> > Cannot update applied migration 'authentication.0001_initial'.
> One cannot edit a migration that has already been applied.
> To update it, you can undo it by running "migrate authentication zero" and
> then run "makemigrations --update" again.
>
> I do not think it's a bug in Django.
>
> Cheers,
> David
>
> Le sam. 8 avr. 2023 à 16:50, Muhammad Juwaini Abdul Rahman <
> juwa...@gmail.com> a écrit :
>
>> Do you need that '--update' parameter?
>>
>> On Fri, 7 Apr 2023 at 05:57, Saifullah Shahen 
>> wrote:
>>
>>> in my custom user model, initially, my model looks like this
>>>
>>> class User(AbstractUser, BaseModelWithUUID):
>>> phone = models.CharField(max_length=11,
>>> validators=[validate_phone_number])
>>> I do command "makemigrations" which create a initial migration file
>>>
>>> but after updating my model like this
>>>
>>> class User(AbstractUser, BaseModelWithUUID):
>>> phone = models.CharField(max_length=11,
>>> validators=[validate_phone_number])
>>> name = models.CharField(max_length=255)
>>>
>>> after adding a field "name" when i run "makemigrations --update" it
>>> shows a error:
>>>
>>> CommandError: Cannot update applied migration
>>> 'authentication.0001_initial'.
>>>
>>> --
>>> 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/793fee18-1231-456b-8d91-f976bebad5e2n%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/CAFKhtoS4wer5PRzA-G%3D1MvOMV8S2oGnMRZ83PTQ6fy3DukWzdQ%40mail.gmail.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/CAHS_w9bXLJ0Cj30yU%2BLw%2BATofw%2B-kkeH2NYF8YCcv6ax303xeg%40mail.gmail.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/CAMyDDM0dVF5qgiPGHTo-MND86PAPVKwhmm4ROw_pCnStJbgqTw%40mail.gmail.com.

Re: Fellow Reports - April 2023

['Adam Johnson' via Django developers (Contributions to Django itself)]

Welcome Natalia 

On Tue, Apr 11, 2023 at 2:52 PM Natalia Bidart 
wrote:

> Week ending April 9, 2023
>
> Hello! I'm Natalia (AKA nessita), the new Django Fellow. I officially
> started on April 1st (really :-)) though I had a slow start since I had a
> long-time planned vacation.
>
> So far I have held catch up calls with both current and former Django
> Fellows (thanks Mariusz and Carlton for your patience and support!), and I
> have been deep diving into documentation.
>
> I'm looking forward to working with you all!
>
> Thank you!
> Natalia.
>
> --
> 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/CA%2BfOnFbRDqYGpBGPTB28EknOuP8PQcAJTvYwNGuqNKmL0zeHtQ%40mail.gmail.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/CAMyDDM32E%3Di7RMdOrSKyG7EXZUf-dfCv_6ubAtpqRGKANvNzjA%40mail.gmail.com.

Re: Doc make error: make: *** [Makefile:59: html] Error 127

[Ezekiel Adetoro]

I have installed the requirement.txt but didn't work.
I was able to get by with

apt-get install python3-sphinx


On Mon, Apr 10, 2023 at 11:27 AM Tim Graham  wrote:

> It looks like Sphinx isn't installed. Did you `pip install
> docs/requirements.txt`?
> On Monday, April 10, 2023 at 9:12:48 AM UTC-4 Ezekiel Adetoro wrote:
>
>> I want to generate the documentation for Django, I have the folloe error
>>
>> sphinx-build -b djangohtml -n -d _build/doctrees -D language=en   .
>> _build/html
>> make: sphinx-build: No such file or directory
>> make: *** [Makefile:59: html] Error 127
>>
>> I have install all requirement and no error.
>> Any help on how to go about this?
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/4E1Iiyqmxz4/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/34976b65-dbcc-49d8-820c-abee7de9ba28n%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/CALKSmMMmh9cQTyh%3DTC3W_UEOxCVEQzZSnj4mTwgqafjQkb%2BeDQ%40mail.gmail.com.

Re: Doc make error: make: *** [Makefile:59: html] Error 127

[Tim Graham]

It looks like Sphinx isn't installed. Did you `pip install 
docs/requirements.txt`?
On Monday, April 10, 2023 at 9:12:48 AM UTC-4 Ezekiel Adetoro wrote:

> I want to generate the documentation for Django, I have the folloe error
>
> sphinx-build -b djangohtml -n -d _build/doctrees -D language=en   . 
> _build/html
> make: sphinx-build: No such file or directory
> make: *** [Makefile:59: html] Error 127
>
> I have install all requirement and no error.
> Any help on how to go about this?
>

-- 
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/34976b65-dbcc-49d8-820c-abee7de9ba28n%40googlegroups.com.

Re: Django "makemigrations -- update" donot working

[David Wobrock]

Hi,

As you can see, the error message seems quite clear:
> Cannot update applied migration 'authentication.0001_initial'.
One cannot edit a migration that has already been applied.
To update it, you can undo it by running "migrate authentication zero" and
then run "makemigrations --update" again.

I do not think it's a bug in Django.

Cheers,
David

Le sam. 8 avr. 2023 à 16:50, Muhammad Juwaini Abdul Rahman <
juwa...@gmail.com> a écrit :

> Do you need that '--update' parameter?
>
> On Fri, 7 Apr 2023 at 05:57, Saifullah Shahen 
> wrote:
>
>> in my custom user model, initially, my model looks like this
>>
>> class User(AbstractUser, BaseModelWithUUID):
>> phone = models.CharField(max_length=11,
>> validators=[validate_phone_number])
>> I do command "makemigrations" which create a initial migration file
>>
>> but after updating my model like this
>>
>> class User(AbstractUser, BaseModelWithUUID):
>> phone = models.CharField(max_length=11,
>> validators=[validate_phone_number])
>> name = models.CharField(max_length=255)
>>
>> after adding a field "name" when i run "makemigrations --update" it shows
>> a error:
>>
>> CommandError: Cannot update applied migration
>> 'authentication.0001_initial'.
>>
>> --
>> 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/793fee18-1231-456b-8d91-f976bebad5e2n%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/CAFKhtoS4wer5PRzA-G%3D1MvOMV8S2oGnMRZ83PTQ6fy3DukWzdQ%40mail.gmail.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/CAHS_w9bXLJ0Cj30yU%2BLw%2BATofw%2B-kkeH2NYF8YCcv6ax303xeg%40mail.gmail.com.

Re: Opensource Django Project

[Tim Graham]

Yes. See 
https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/

On Saturday, April 8, 2023 at 10:50:17 AM UTC-4 Naresh Pahariya wrote:

> Me too...
>
> I think there is a documentation for django contribution. 
>
> Thanks,
> Naresh
>
> On Sat, 8 Apr, 2023, 3:51 pm Dipankar,  wrote:
>
>> Hi All,
>>
>> I want to contribute  to the Open Source Django Project as a developer.
>> Can anybody help me please?
>>
>> -- 
>> Warm Regards,
>> Dipankar B.
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAFdBwp-m8nUVrP0Jd4o16XwBEOOOkE9ys42yYXRze58aUQZ4qQ%40mail.gmail.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/bb49f44b-056f-4e9d-95b2-c7f0462ddcd0n%40googlegroups.com.

Re: The problem of versioning a large project.

[Christian González]

I think that's not possible with Django without some quirks. You need to 
add apps to your settings.py anyway, so, if these apps are not present 
in your repo, it's not working, as there are imports that lead into 
nowhere.


Django provides really good support for creating reusable "apps" that 
can be used in different Django applications, if correctly done. But you 
have to include them hard-coded, it's not possible to create more apps 
that "plug" into ONE Django application and extend its functionality 
dynamically. And it seems you need that in your case.


So you need either a mono repo, or git submodules that need to be 
fetched. I solved a similar problem by building a library that adds such 
a plugin support to Django: https://gdaps.readthedocs.io


You can use a Django main application, and install app "plugins" that 
add funcationality to your app without touching the settings.py. Just 
install the Django/GDAPS app per pip, restart the Django server / manage 
migrate, and it should work.


It's not perfect ans still lacks some features, but should solve your 
problem.


Yours, Christian

Am 03.04.23 um 16:04 schrieb Piyush Prasad:

Why not use a mono repo?

*From:* django-developers@googlegroups.com 
 on behalf of Alex Sonar 


*Sent:* Sunday, April 2, 2023 10:21:33 PM
*To:* Django developers (Contributions to Django itself) 


*Subject:* Re: The problem of versioning a large project.
It is about one project that includes many applications.

We would like to separate the repository specifically for front-end 
guest groups.


With access to parts like: views_groups, templates, dummy_data, 
forms_group, helpers_group, static_blob and media_blob as an example.


Now our application tier and the file structure of the project looks 
something like in the picture below.


 .

├── apps

 .     ├── .DS_Store

   ├── app_alpha

   │ ├── .git              <<<<<<<<<<<<<<<<<<<<<<<<<   git alpha

   │ └── alpha

   │       ├── __init__.py

   │       ├── admin_alpha.py

   │       ├── api_connectors

   │       ├── apps_alpha.py

   │       ├── conf_parser_alpha.py

   │       ├── controllers_groups

   │       ├── dummy_data_alpha

   │       ├── db_router_alpha.py

   │       ├── forms_group

   │       ├── helpers_group

   │       ├── media_blob_alpha

   │       ├── metadata

   │       ├── migrations

   │       ├── models_groups

   │       ├── signals_alpha.py

   │       ├── static_blob__alpha

   │       ├── templates

   │       ├── urls_alpha.py

   │       └── views_groups

   ├── app_beta

   │ ├── .git              <<<<<<<<<<<<<<<<<<<<<<<<<    git beta

   │ └──  beta

   │       ├── __init__.py

   │         …….

   ├── app_gamma

   │ ├── .git              <<<<<<<<<<<<<<<<<<<<<<<<<    git gamma

   │ └──  gamma

   │       ├── __init__.py

   │         …….

   ├── app_delta

   │ ├── .git              <<<<<<<<<<<<<<<<<<<<<<<<<    git delta

   │ └──  delta

   │       ├── __init__.py

   …..     …….

On Saturday, April 1, 2023 at 2:56:33 PM UTC+3 Jason Johns wrote:

>Now we have organized versioning, where our project is divided
into separate GIT repositories which are created for each application.



why? what's the reasoning for this? django already has apps, so
why do you need to make multiple projects for single components?
On Friday, March 31, 2023 at 10:15:06 AM UTC-4 cha...@gmail.com wrote:


Like Aharon, I'm not entirely certain what you mean but this line:
> The task looks like bad practice, where we have to create a
repository within another one.
reminded me of git submodules, which I don't think are
considered bad practice. Is that what you mean?
On Thursday, March 30, 2023 at 5:17:41 AM UTC+9 Alex Sonar wrote:

The problem of versioning a large project.

Hi guys, I really got stuck with the challenge, with the
design of versioning for a large project.

Now we have organized versioning, where our project is
divided into separate GIT repositories which are created
for each application.

The new necessity point is to split some of them for
front-end and back-and developers.

The task looks like bad pract

Re: Django "makemigrations -- update" donot working

[Muhammad Juwaini Abdul Rahman]

Do you need that '--update' parameter?

On Fri, 7 Apr 2023 at 05:57, Saifullah Shahen  wrote:

> in my custom user model, initially, my model looks like this
>
> class User(AbstractUser, BaseModelWithUUID):
> phone = models.CharField(max_length=11,
> validators=[validate_phone_number])
> I do command "makemigrations" which create a initial migration file
>
> but after updating my model like this
>
> class User(AbstractUser, BaseModelWithUUID):
> phone = models.CharField(max_length=11,
> validators=[validate_phone_number])
> name = models.CharField(max_length=255)
>
> after adding a field "name" when i run "makemigrations --update" it shows
> a error:
>
> CommandError: Cannot update applied migration
> 'authentication.0001_initial'.
>
> --
> 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/793fee18-1231-456b-8d91-f976bebad5e2n%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/CAFKhtoS4wer5PRzA-G%3D1MvOMV8S2oGnMRZ83PTQ6fy3DukWzdQ%40mail.gmail.com.

Re: Opensource Django Project

[Naresh Pahariya]

Me too...

I think there is a documentation for django contribution.

Thanks,
Naresh

On Sat, 8 Apr, 2023, 3:51 pm Dipankar,  wrote:

> Hi All,
>
> I want to contribute  to the Open Source Django Project as a developer.
> Can anybody help me please?
>
> --
> Warm Regards,
> Dipankar B.
>
> --
> 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/CAFdBwp-m8nUVrP0Jd4o16XwBEOOOkE9ys42yYXRze58aUQZ4qQ%40mail.gmail.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/CAMpxr5pPUqAtGdLe3dfErf_wDp7Bqu9YoeHcvh%3DN3sQWahEsfg%40mail.gmail.com.

Re: Django "makemigrations -- update" donot working

[Dipankar]

Please follow https://docs.djangoproject.com/en/4.1/topics/auth/customizing/

On Fri, Apr 7, 2023 at 3:27 AM Saifullah Shahen 
wrote:

> in my custom user model, initially, my model looks like this
>
> class User(AbstractUser, BaseModelWithUUID):
> phone = models.CharField(max_length=11,
> validators=[validate_phone_number])
> I do command "makemigrations" which create a initial migration file
>
> but after updating my model like this
>
> class User(AbstractUser, BaseModelWithUUID):
> phone = models.CharField(max_length=11,
> validators=[validate_phone_number])
> name = models.CharField(max_length=255)
>
> after adding a field "name" when i run "makemigrations --update" it shows
> a error:
>
> CommandError: Cannot update applied migration
> 'authentication.0001_initial'.
>
> --
> 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/793fee18-1231-456b-8d91-f976bebad5e2n%40googlegroups.com
> 
> .
>


-- 
Warm Regards,
Dipankar B.

-- 
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/CAFdBwp8DK5SgXgzQde9bS_Uf8tMvAFdfKQR%2BTgecyptYvqeA%3Dg%40mail.gmail.com.

Re: Implement Ruff Linter

[charettes]

Strong agree with Adam here.

If Ruff current offer is enhanced speed at the cost of a less mature 
ecosystem I don't think that it's a tradeoff Django should make at the time 
being.

Simon

Le jeudi 6 avril 2023 à 08:16:00 UTC-4, Adam Johnson a écrit :

> I don't think we should adopt Ruff. It's a new, somewhat experimental 
> project. It wouldn't provide any gains except speed, but that is not really 
> a concern since it still takes a handful of seconds to lint Django with 
> Flake8 and co.
>
> On Mon, Apr 3, 2023 at 1:59 PM Jerome Obi  wrote:
>
>> Hi !
>> I use Ruff as my primary Linter for all my Python Projects.
>> https://github.com/charliermarsh/ruff
>>
>> It's very fast and powerful, so I thought I could try it on Django Code.
>> With all options activated, Django is scanned in less than 1 second.
>> Here's the Configuration with all detected errors types ignored.
>> https://github.com/django/django/compare/main...obi-jerome:django:Ruff
>>
>> What do you think ?
>> Is it done the proper way ?
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/c3201044-4d25-49d3-b0ce-06de4c7624efn%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/6758f3a6-8b89-4a5b-8186-1935ea00f92en%40googlegroups.com.

Re: Proposal: Check constraints at the model field level

[charettes]

Small clarification here.

> it should be noted that SQL has both CHECK on the field and table level,

>From my understanding CREATE TABLE / ADD COLUMN checks on the field level 
are really just syntactic sugar for checks at the table level like just 
like `REFERENCES` usage is syntactic sugar for foreign key constraints.

> This is not true for unique constraints or indices.

Unique constraints can be defined using the UNIQUE keyword just like CHECK 
is used to define a check per field, it's really just a different way of 
defining that a unique constraint on a field must be created.

The question of whether or not we want to provide some Django syntactic 
sugar in the form of `Field.check` and the benefits it might provide to 
third-parties (and even ourselves for dog fooding PositiveIntegerField) 
remains but I think that it's important to point out that there's no 
distinction between field and table level constraints at the database level 
AFAIK (for Postgres and SQLite at least).

Simon
Le jeudi 6 avril 2023 à 01:47:48 UTC-4, Adam Johnson a écrit :

> Mariusz, I agree with the burden, but it should be noted that SQL has both 
> CHECK on the field and table level, and CheckConstraint only defines 
> table-level constraints. This is not true for unique constraints or indices.
>
> Also, what do you think of a way for custom field classes to add 
> constraints, at least? db_check() is somewhat limiting given it must return 
> raw SQL, plus it's undocumented.
>
> On Thu, Apr 6, 2023 at 5:11 AM Mariusz Felisiak  
> wrote:
>
>> Hi,
>>
>> This proposal is not really nice from a maintenance point of view as we 
>> will end with the same complicated situation we currently have with 
>> uniqueness checks or indexes i.e. many ways to define the same:
>>
>> - Field.unique/index
>> - Meta.unique_together/index_together
>> - Meta.constraints/indexes
>>
>> It's especially error-prone in migrations and different database behavior 
>> on fields already covered by the same constraints/indexes. I'm pretty sure 
>> that we've introduced Meta.contraints/indexes to avoid this happening in 
>> the future, and we are rather leaning to leave only 
>> Meta.constraints/indexes and remove other options in the future. Not 
>> creating a new one.
>>
>> Initial -1 from me.
>>
>> 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-develop...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/954af838-2176-4877-b4ac-70525cddcbf5n%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/58ab388c-2852-4e23-94b9-c4f7d9fa61bfn%40googlegroups.com.

Re: Implement Ruff Linter

['Adam Johnson' via Django developers (Contributions to Django itself)]

I don't think we should adopt Ruff. It's a new, somewhat experimental
project. It wouldn't provide any gains except speed, but that is not really
a concern since it still takes a handful of seconds to lint Django with
Flake8 and co.

On Mon, Apr 3, 2023 at 1:59 PM Jerome Obi  wrote:

> Hi !
> I use Ruff as my primary Linter for all my Python Projects.
> https://github.com/charliermarsh/ruff
>
> It's very fast and powerful, so I thought I could try it on Django Code.
> With all options activated, Django is scanned in less than 1 second.
> Here's the Configuration with all detected errors types ignored.
> https://github.com/django/django/compare/main...obi-jerome:django:Ruff
>
> What do you think ?
> Is it done the proper way ?
>
> --
> 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/c3201044-4d25-49d3-b0ce-06de4c7624efn%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/CAMyDDM0RyJPoZKz5o4LCYwe4FabcR197%2BiC19NZPoHBU3SAw2Q%40mail.gmail.com.

Re: Stalebot on djangoproject.com issues

['Adam Johnson' via Django developers (Contributions to Django itself)]

I agree that we should remove Stalebot. Closing old issues doesn't fix them
or provide a reason why they aren’t going to be worked on.

On Thu, Apr 6, 2023 at 8:02 AM Sarah Boyce  wrote:

> From what it sounds, I guess the main value was prompting a one time
> spring clean. As there are not that many issues open in djangoproject.com
> and all issues will have been re-validated, I think it makes sense to
> remove it to reduce this additional burden/frustration.
>
> There are configurations around stale PR closing which I think makes more
> sense in general (maybe not for djangoproject.com as there are not many
> PRs), as other people might be reluctant to work on something if there is
> an open PR and it prompts someone to decide if they want to come back to
> this if they have just forgotten for example.
>
> On Wednesday, 5 April 2023 at 23:30:54 UTC+2 Tim Graham wrote:
>
>> Hello,
>>
>> In October 2022, a stalebot was activated for djangoproject.com issues:
>>
>> https://github.com/django/djangoproject.com/issues/1219
>> https://github.com/django/djangoproject.com/pull/1220
>>
>> It comments on an issue if there's no activity in the last six months: "This
>> issue has been automatically marked as stale because it has not had recent
>> activity. It will be closed if no further activity occurs. Thank you for
>> your contributions."
>>
>> The bot closes the issue if there's no activity in the next seven days.
>>
>> I didn't see much discussion among the djangproject.com team outside of
>> the issue and PR,  but the rationale from the issue is this: "Idea
>> copied from DRF PR #8423
>> <https://github.com/encode/django-rest-framework/pull/8423> - Add a
>> StaleBot, configured with the lowest possible run limit. The intent here
>> is to help us sweep through the issue and pull request backlog, and review
>> what does and does not need to remain open at this point in time."
>>
>> Here is what I said at the time: "I think this is a lame way to handle
>> old issues. The result seems to be Carlton triaging all issues that the bot
>> comments on. You could have asked him to do that without a bot adding
>> noise. Should a useless "issue still valid" comment be required every 180
>> days? Why not have a human triage each issue now that more people are
>> maintaining this site? Using a bot comes off to me as passive aggressive.
>> Why try to automatically discard years of issues (even if minor)? It's not
>> like the passage of time or lack of activity means the problem went away. A
>> responsible reporter will look through existing issues so they don't report
>> a duplicate and not necessarily leave a comment like "issue still valid."
>> If we close the issue automatically, what did that accomplish? I would
>> think triaging issues would be a good way for new team members to develop
>> their understanding of the site. If you're feeling unknowledgable about an
>> old issue, feel free to ping me for advice. I hope you might reconsider the
>> usefulness of the bot."
>>
>> It's six months later, and I'm now having to again comment on inactive
>> issues "stalebot, please don't close." to keep valid issues open.
>>
>> Paolo Melchiorre (author of this initiative) says, "activating the
>> stalebot last year allowed us to close many old issues. I think an issue
>> opened 7 years ago should be closed if no one takes care of it despite two
>> reminders in the last year. As the removal of the stalebot is not only up
>> to me, I think it is worth discussing it in a separate issue or on the
>> developer mailing list."
>>
>> I remain of the opinion that continued attempts to automatically abandon
>> valid issues are not helpful and do not reflect project maintenance best
>> practices. I would like to hear your thoughts on the matter. Thanks!
>>
> --
> 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/0fbe194d-2626-49c6-a91e-b8538b0ae1a6n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/0fbe194d-2626-49c6-a91e-b8538b0ae1a6n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAMyDDM0%2Bv4-d0-bvTQNZE0HAUONRoE0U4Qcyt2zFAhxBXMAidw%40mail.gmail.com.

Re: Stalebot on djangoproject.com issues

[Sarah Boyce]

>From what it sounds, I guess the main value was prompting a one time spring 
clean. As there are not that many issues open in djangoproject.com and all 
issues will have been re-validated, I think it makes sense to remove it to 
reduce this additional burden/frustration.

There are configurations around stale PR closing which I think makes more 
sense in general (maybe not for djangoproject.com as there are not many 
PRs), as other people might be reluctant to work on something if there is 
an open PR and it prompts someone to decide if they want to come back to 
this if they have just forgotten for example.

On Wednesday, 5 April 2023 at 23:30:54 UTC+2 Tim Graham wrote:

> Hello,
>
> In October 2022, a stalebot was activated for djangoproject.com issues:
>
> https://github.com/django/djangoproject.com/issues/1219
> https://github.com/django/djangoproject.com/pull/1220
>
> It comments on an issue if there's no activity in the last six months: "This 
> issue has been automatically marked as stale because it has not had recent 
> activity. It will be closed if no further activity occurs. Thank you for 
> your contributions."
>
> The bot closes the issue if there's no activity in the next seven days.
>
> I didn't see much discussion among the djangproject.com team outside of 
> the issue and PR,  but the rationale from the issue is this: "Idea copied 
> from DRF PR #8423 
> <https://github.com/encode/django-rest-framework/pull/8423> - Add a 
> StaleBot, configured with the lowest possible run limit. The intent here 
> is to help us sweep through the issue and pull request backlog, and review 
> what does and does not need to remain open at this point in time."
>
> Here is what I said at the time: "I think this is a lame way to handle 
> old issues. The result seems to be Carlton triaging all issues that the bot 
> comments on. You could have asked him to do that without a bot adding 
> noise. Should a useless "issue still valid" comment be required every 180 
> days? Why not have a human triage each issue now that more people are 
> maintaining this site? Using a bot comes off to me as passive aggressive. 
> Why try to automatically discard years of issues (even if minor)? It's not 
> like the passage of time or lack of activity means the problem went away. A 
> responsible reporter will look through existing issues so they don't report 
> a duplicate and not necessarily leave a comment like "issue still valid." 
> If we close the issue automatically, what did that accomplish? I would 
> think triaging issues would be a good way for new team members to develop 
> their understanding of the site. If you're feeling unknowledgable about an 
> old issue, feel free to ping me for advice. I hope you might reconsider the 
> usefulness of the bot."
>
> It's six months later, and I'm now having to again comment on inactive 
> issues "stalebot, please don't close." to keep valid issues open.
>
> Paolo Melchiorre (author of this initiative) says, "activating the 
> stalebot last year allowed us to close many old issues. I think an issue 
> opened 7 years ago should be closed if no one takes care of it despite two 
> reminders in the last year. As the removal of the stalebot is not only up 
> to me, I think it is worth discussing it in a separate issue or on the 
> developer mailing list."
>
> I remain of the opinion that continued attempts to automatically abandon 
> valid issues are not helpful and do not reflect project maintenance best 
> practices. I would like to hear your thoughts on the matter. Thanks!
>

-- 
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/0fbe194d-2626-49c6-a91e-b8538b0ae1a6n%40googlegroups.com.

Re: Proposal: Check constraints at the model field level

['Adam Johnson' via Django developers (Contributions to Django itself)]

Mariusz, I agree with the burden, but it should be noted that SQL has both
CHECK on the field and table level, and CheckConstraint only defines
table-level constraints. This is not true for unique constraints or indices.

Also, what do you think of a way for custom field classes to add
constraints, at least? db_check() is somewhat limiting given it must return
raw SQL, plus it's undocumented.

On Thu, Apr 6, 2023 at 5:11 AM Mariusz Felisiak 
wrote:

> Hi,
>
> This proposal is not really nice from a maintenance point of view as we
> will end with the same complicated situation we currently have with
> uniqueness checks or indexes i.e. many ways to define the same:
>
> - Field.unique/index
> - Meta.unique_together/index_together
> - Meta.constraints/indexes
>
> It's especially error-prone in migrations and different database behavior
> on fields already covered by the same constraints/indexes. I'm pretty sure
> that we've introduced Meta.contraints/indexes to avoid this happening in
> the future, and we are rather leaning to leave only
> Meta.constraints/indexes and remove other options in the future. Not
> creating a new one.
>
> Initial -1 from me.
>
> 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/954af838-2176-4877-b4ac-70525cddcbf5n%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/CAMyDDM0QonqK_7ibWKFf7d8eX7QxzSD7JNRKsJn3o4y%2BYgHVnQ%40mail.gmail.com.

Re: Proposal: Check constraints at the model field level

[Mariusz Felisiak]

Hi,

This proposal is not really nice from a maintenance point of view as we 
will end with the same complicated situation we currently have with 
uniqueness checks or indexes i.e. many ways to define the same:

- Field.unique/index
- Meta.unique_together/index_together
- Meta.constraints/indexes

It's especially error-prone in migrations and different database behavior 
on fields already covered by the same constraints/indexes. I'm pretty sure 
that we've introduced Meta.contraints/indexes to avoid this happening in 
the future, and we are rather leaning to leave only 
Meta.constraints/indexes and remove other options in the future. Not 
creating a new one.

Initial -1 from me.

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/954af838-2176-4877-b4ac-70525cddcbf5n%40googlegroups.com.

Re: Proposal: Check constraints at the model field level

['Adam Johnson' via Django developers (Contributions to Django itself)]

I agree this feature would be useful, at least to allow bundling check
constraints with custom field classes. As you point out the
PositiveIntegerField classes do this within Django, and doubtless many
custom fields have used the db_check() method.

The only thing I'm not a fan of in your proposal is repeating the field
name within the check expression, like "price" in:

price = DecimalField(..., check=Q(price__gte=0))

This seems repetitive at least, and would increase error refactoring. Also
Django field classes typically don't “know” their name until the Model meta
class logic runs, and contribute_to_class() is called. Requiring the name
within check() would mean it would need to accept any name and validate it
later.

Perhaps we could support only a special name instead, like “self” or the
shorter “f”?

price = DecimalField(..., check=Q(f__gte=0))

On Wed, Apr 5, 2023 at 7:18 PM David Sanders 
wrote:

> Hi folks,
>
> We've had check constraints for a while now and they're awesome.
>
> I'd like to propose an alternative way to declare check constraints: at
> the field level. This sounds like it's duplicating the feature but there
> are some advantages that make this distinct from declaring at the
> model-level from the meta:
>
>- Colocality: the check rules are close to the field they're concerned
>with
>- Reusability: Allows for bundling with custom field types
>- Good for checks concerned only with the field its declared on, for
>multiple fields recommended to continue to use Meta. (Kind of analogous to
>unique=True vs UniqueConstraint)
>
> For example:
>
> class Product(Model):
> price = DecimalField(..., check=Q(price__gte=0))
> ...
> other fields
> ...
>
>
> class Meta:
> constraints = [
> ... declare constraints here that are concerned with multiple
> fields...
> ]
>
>
> For more complex fields you can then bundle the check for reusability:
>
> class PriceField(DecimalField):
> def contribute_to_class(self, ...):
> super().contribute_to_class(...)
> self.check = Q(**{f'{self.name}__gte': 0})
>
>
> Some other points:
>
>- To be consistent with model-level check constraints they'd also need
>to participate in validate_constraints().
>- (Small)PositiveIntegerField already has its own implementation of a
>check constraint, enforcing values >- 0 via the private db_check() method.
>I think this is an example of how bundling checks can be useful.
>- I won't go into implementation alternatives but making use of this
>existing db_check() method is one possibility. How participation in
>validation would work would still need to be decided upon.
>- See this Stupid Django Trick
>
> 
>for some experimentation with this idea.
>
>
> Cheers,
> David
>
> --
> 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-6Odv0dpo-En3Jm2NqPhBtK7ebaGKBi4OROe1n%2BvHEE-A%40mail.gmail.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/CAMyDDM3Tyj%3Djfo9yFiUythymjP2WHKGi6cJY%3DOKk1_XkggiMtQ%40mail.gmail.com.

Re: Issue with get_FOO_display not working in Django admin

[David Sanders]

At this point I'll let others chime in with their opinion on whether this
is something that needs to change because:

   1. I rarely use admin
   2. I've never really had the need to override a choice's display over
   those supplied via `choices`

:)

On Wed, 5 Apr 2023 at 19:05, 'Ibrahim Abou Elenein' via Django developers
(Contributions to Django itself)  wrote:

> Isn't this some sort of duplication? why not just use it instead of
> writing its logic again?
>
>

-- 
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-7r%3D%3Dwybp8XWp7tEdAOYWuhKucXGE_Kjq0twTy%3DN8KWPg%40mail.gmail.com.

Re: Issue with get_FOO_display not working in Django admin

['Ibrahim Abou Elenein' via Django developers (Contributions to Django itself)]

Isn't this some sort of duplication? why not just use it instead of writing 
its logic again?
On Wednesday, April 5, 2023 at 7:12:48 AM UTC+2 David Sanders wrote:

> Hi Ibrahim,
>
> get_FOO_display() isn't intended to be overridden like that, it's just a 
> convenience method for use in templates/whatever that refers to the 
> underlying flatchoices.
>
> For clarity, please see the documentation: 
> https://docs.djangoproject.com/en/4.2/ref/models/instances/#django.db.models.Model.get_FOO_display
>
> Kind regards,
> David
>
> On Wed, 5 Apr 2023 at 09:10, 'Ibrahim Abou Elenein' via Django developers 
> (Contributions to Django itself)  wrote:
>
>> Dear All,
>>
>> I am writing to report an issue I encountered while working with Django 
>> admin. I had a model with a field that uses Choices as follows:
>>
>> ```
>> status = FSMField(default=STATUSES.PENDING, choices=STATUSES, 
>> protected=True)
>> ```
>> I overrode the get_status_display method, but to my surprise, it did not 
>> have any effect in the Django admin.
>>
>> Upon investigating Django's code, I found the following method in 
>> contrib.admin
>>
>> ```
>> def display_for_field(value, field, empty_value_display):
>> from django.contrib.admin.templatetags.admin_list import _boolean_icon
>>
>> if getattr(field, "flatchoices", None):
>> return dict(field.flatchoices).get(value, empty_value_display)
>> ```
>> I noticed that this method uses flatchoices to get the display value for 
>> fields with choices. However, it does not take into account any custom 
>> display methods that may have been defined for the field.
>>
>> To resolve this issue, I modified the code to use get_FOO_display instead 
>> of flatchoices as follows:
>>
>> ```
>> def display_for_field(value, field, empty_value_display, model=None):
>> from django.contrib.admin.templatetags.admin_list import _boolean_icon
>>
>> if getattr(field, "flatchoices", None):
>> if model:
>> return getattr(model, "get_%s_display" % field.name)()
>> return dict(field.flatchoices).get(value, empty_value_display)
>> ```
>> This modification allowed my custom display method to work as expected in 
>> the Django admin.
>>
>> However, I am curious to know why Django's code behaves this way and how 
>> I can make use of this behavior in my application.
>>
>> Thank you for your attention to this matter.
>>
>> Sincerely,
>> Ibrahim.
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/4f432f39-b959-422e-b062-5db54722b18en%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/f60ef476-412e-4739-b43e-15e181d7a986n%40googlegroups.com.

Re: Issue with get_FOO_display not working in Django admin

[David Sanders]

Hi Ibrahim,

get_FOO_display() isn't intended to be overridden like that, it's just a
convenience method for use in templates/whatever that refers to the
underlying flatchoices.

For clarity, please see the documentation:
https://docs.djangoproject.com/en/4.2/ref/models/instances/#django.db.models.Model.get_FOO_display

Kind regards,
David

On Wed, 5 Apr 2023 at 09:10, 'Ibrahim Abou Elenein' via Django developers
(Contributions to Django itself)  wrote:

> Dear All,
>
> I am writing to report an issue I encountered while working with Django
> admin. I had a model with a field that uses Choices as follows:
>
> ```
> status = FSMField(default=STATUSES.PENDING, choices=STATUSES,
> protected=True)
> ```
> I overrode the get_status_display method, but to my surprise, it did not
> have any effect in the Django admin.
>
> Upon investigating Django's code, I found the following method in
> contrib.admin
>
> ```
> def display_for_field(value, field, empty_value_display):
> from django.contrib.admin.templatetags.admin_list import _boolean_icon
>
> if getattr(field, "flatchoices", None):
> return dict(field.flatchoices).get(value, empty_value_display)
> ```
> I noticed that this method uses flatchoices to get the display value for
> fields with choices. However, it does not take into account any custom
> display methods that may have been defined for the field.
>
> To resolve this issue, I modified the code to use get_FOO_display instead
> of flatchoices as follows:
>
> ```
> def display_for_field(value, field, empty_value_display, model=None):
> from django.contrib.admin.templatetags.admin_list import _boolean_icon
>
> if getattr(field, "flatchoices", None):
> if model:
> return getattr(model, "get_%s_display" % field.name)()
> return dict(field.flatchoices).get(value, empty_value_display)
> ```
> This modification allowed my custom display method to work as expected in
> the Django admin.
>
> However, I am curious to know why Django's code behaves this way and how I
> can make use of this behavior in my application.
>
> Thank you for your attention to this matter.
>
> Sincerely,
> Ibrahim.
>
> --
> 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/4f432f39-b959-422e-b062-5db54722b18en%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-65tb_3LZq0D%2BVbU4Dh71V%3DGMRWDeFHCuhT8pDcChVn_w%40mail.gmail.com.

Re: The problem of versioning a large project.

[Piyush Prasad]

Why not use a mono repo?

From: django-developers@googlegroups.com  
on behalf of Alex Sonar 
Sent: Sunday, April 2, 2023 10:21:33 PM
To: Django developers (Contributions to Django itself) 

Subject: Re: The problem of versioning a large project.

It is about one project that includes many applications.

We would like to separate the repository specifically for front-end guest 
groups.

With access to parts like: views_groups, templates, dummy_data, forms_group, 
helpers_group, static_blob and media_blob as an example.

Now our application tier and the file structure of the project looks something 
like in the picture below.


   .

├── apps

 . ├── .DS_Store

   ├── app_alpha

   │   ├── .git  <<<<<<<<<<<<<<<<<<<<<<<<<   git alpha

   │   └── alpha

   │ ├── __init__.py

   │ ├── admin_alpha.py

   │ ├── api_connectors

   │ ├── apps_alpha.py

   │ ├── conf_parser_alpha.py

   │ ├── controllers_groups

   │ ├── dummy_data_alpha

   │ ├── db_router_alpha.py

   │ ├── forms_group

   │ ├── helpers_group

   │ ├── media_blob_alpha

   │ ├── metadata

   │ ├── migrations

   │ ├── models_groups

   │ ├── signals_alpha.py

   │ ├── static_blob__alpha

   │ ├── templates

   │ ├── urls_alpha.py

   │ └── views_groups

   ├── app_beta

   │   ├── .git  <<<<<<<<<<<<<<<<<<<<<<<<<git beta

   │   └──  beta

   │ ├── __init__.py

   │  …….

   ├── app_gamma

   │   ├── .git  <<<<<<<<<<<<<<<<<<<<<<<<<git gamma

   │   └──  gamma

   │ ├── __init__.py

   │  …….

   ├── app_delta

   │   ├── .git  <<<<<<<<<<<<<<<<<<<<<<<<<git delta

   │   └──  delta

   │ ├── __init__.py

   …..  …….


On Saturday, April 1, 2023 at 2:56:33 PM UTC+3 Jason Johns wrote:
>Now we have organized versioning, where our project is divided into separate 
>GIT repositories which are created for each application.



why? what's the reasoning for this? django already has apps, so why do you need 
to make multiple projects for single components?
On Friday, March 31, 2023 at 10:15:06 AM UTC-4 cha...@gmail.com wrote:

Like Aharon, I'm not entirely certain what you mean but this line:
> The task looks like bad practice, where we have to create a repository within 
> another one.
reminded me of git submodules, which I don't think are considered bad practice. 
Is that what you mean?
On Thursday, March 30, 2023 at 5:17:41 AM UTC+9 Alex Sonar wrote:

The problem of versioning a large project.

Hi guys, I really got stuck with the challenge, with the design of versioning 
for a large project.

Now we have organized versioning, where our project is divided into separate 
GIT repositories which are created for each application.

The new necessity point is to split some of them for front-end and back-and 
developers.

The task looks like bad practice, where we have to create a repository within 
another one.

Or redesign the file structures of the application itself, to meet this 
requirement.


If someone has a similar challenge or practice and helps me make the right 
decision, I will be very grateful.

--
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<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1c2df2fc-0158-4da1-a686-5f2a69435f43n%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/1c2df2fc-0158-4da1-a686-5f2a69435f43n%40googlegroups.com?utm_medium=email_source=footer>.

-- 
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/PH0PR15MB5640DD26A7890FC754671486FC929%40PH0PR15MB5640.namprd15.prod.outlook.com.