Re: Proposal on how add configuration options to Email Backends

There is a ticket for this feature request now: https://code.djangoproject.com/ticket/35514#ticket -- 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

Re: Drop CSRF middleware from the settings template

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

Re: Drop CSRF middleware from the settings template

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

Re: Drop CSRF middleware from the settings template

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

Re: Feedback for my draft proposal

Hi Jayant, before inventing the wheel a second time, did you have a look at these Cookiecutter templates? https://github.com/cookiecutter/cookiecutter-django They probably are all you need for the purpose you're proposing. – Jacob -- You received this message because you are subscribed to the

Re: Exporting some of the `datetime` functions from `django.utils.timezone`

I find it confusing that we have to import now from django.utils.timezone, but timedelta from Python's internal datetime. This btw. is a violation of the Law of Demeter , hence I agree with Suayip's proposal. – Jacob On Monday, March 20, 2023 at

Re: Model icons

On Thu, Feb 23, 2023 at 7:38 AM Brice Parent wrote: > Hello! > > Really useful idea, I think! 2 points about it: > > 1. Syntax > > I would also remove the html from the models, but probably in this way: > class Hammer(models.Model): > ... > > Meta: > icon = ModelIcon("") > > >

Re: Model icons

I agree with Adam Johnson that adding HTML to the model class is a bit too coupled. But I like the idea of Mark Niehues to add them to the ModelAdmin class, although I would allow a HTML/SVG snippet rather than a CSS class. - How would we then handle 3rd party apps providing their own SVG

Re: dynamically added INSTALLED_APPS

Isn't it a bit dangerous to auto-add a package from PyPI to a running Django installation? That module then gains full database access and could do all kind of nasty stuff. Maybe I am a bit naive here, but 3rd party packages sometimes get installed incautiously. – Jacob -- You received this

Re: Multiple instances of DjangoAdmin share the same model LogEntry

Hi Adam, I'm currently preparing a pull request on this. No changes will be made to the model LogEntry. It will just allow implementers to filter log entries by registered models (of that instantiated admin). Not doing this, in my opinion is unexpected behaviour anyway. Thanks to Carlton for

Re: Multiple instances of DjangoAdmin share the same model LogEntry

Hi Carlton, that proposal makes a lot of sense. This means that one could for instance add a custom function to that context which, if set, would be called by the AdminLogNode.render method and then overrides the context[self.varname]. How would you name that extra context variable, maybe

Re: Multiple instances of DjangoAdmin share the same model LogEntry

Hi Carlton, As I understand it, separate admin sites may register different models, but I'm only going to see the History for instances that are visible to the current admin no? The Django admin interface uses a templatetag named get_admin_log. It renders the content of all entries of model

Multiple instances of DjangoAdmin share the same model LogEntry

If someone uses two or more instances of the Django Admin interface, the sidebar on the right containing the "Recent actions", shares the same information for all instances of the Django Admin interface. This is because the model LogEntry is a singleton and shared across all instances of the

Re: (Circa end of 2021) Localization issues with input type=date?

How about ditching the JS based datepicker altogether and replace it against the built-in datepicker offered by modern browsers? This would also help users of mobile devices because they already have good internal implementations to select a date. I agree that on desktop browsers the built-in

Re: Proposal: Add An in-memory data storage backend in Django

Big +1 from my side. (Would indeed help me to write more portable unit tests.) – 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,

Re: Proposal: Add utility class "ClassList"

> > I'm trying to imagine exactly what you have in mind, but I'm not entirely > clear. > > Thanks again. > Carlton > > On Friday, 23 September 2022 at 11:14:27 UTC+2 Jacob Rief wrote: > >> In JavaScript each HTMLElement has a property named clas

Proposal: Add utility class "ClassList"

In JavaScript each HTMLElement has a property named classList . This actually is a set allowing to *add* a single CSS class string, *remove* it and/or *toggle* it. If we would reimplement this as a Python class, methods such

Re: More user friendly delete confirmation template

On Wednesday, August 17, 2022 at 7:23:35 AM UTC+2 Carlton Gibson wrote: > > Can we at least agree to put an id="..." onto the element wrapping > that list. > > That seems pretty minimal.  Do you want to open a PR so we can have a > look? > Okay, will do that. Any suggestions for a name? My

Re: More user friendly delete confirmation template

Can we at least agree to put an id="..." onto the element wrapping that list. That would help me to add some JS and CSS to the overwritten delete_selected_confirmation template without having to copy a huge block of HTML code from that template. – Jacob -- You received this message because

Re: More user friendly delete confirmation template

The least intrusive change would be to add an id="..." to the -element wrapping that list. This at least allows me to add such a Javascript snippet into {% block extrahead %}. – Jacob -- You received this message because you are subscribed to the Google Groups "Django developers

Re: More user friendly delete confirmation template

On Tuesday, August 16, 2022 at 4:23:03 PM UTC+2 Carlton Gibson wrote: > > Then as Maxim points out, this is already possible with overriding the > template. > > That's what I did of course in the first place. It however turns out that you have to copy quite a bunch of boilerplate code, the

More user friendly delete confirmation template

Whenever a user attempts to delete an object inside the Django admin, a delete confirmation page is shown. If the object to be deleted contains many relations, the user is overwhelmed with a list of other objects to be deleted together with the current object. Often those objects are just internal

Re: UI/UX - FilteredSelectMultiple - Filtering the selected options

I'have implemented such a widget in django-formset . It just hides (removes) the selected options which have been filtered out. Otherwise, filtering by muting options, wouldn't have the desired visual effect. Please note that in order to implement this feature,

Re: Feature Request: New PostgreSQL ArrayField

Hello Liamine, Django offers a JSONField which can be used to store an array. You can use it to store a list of prices. What's the benefit of using an array instead of JSON? – Jacob -- You received this message because you

Re: Custom Ordering and Grouping of Models in Django Admin

Hi Mariusz, On Thursday, June 16, 2022 at 7:20:23 PM UTC+2 Mariusz Felisiak wrote: > It's already solved in Django 4.1+ by > https://github.com/django/django/commit/2bee0b4328319eaf6a0d1686677d629f2ecf6dec. > > You can now override get_app_list() to change the default order on the >

Re: Custom Ordering and Grouping of Models in Django Admin

Hi, just encountered this same problem today. As Roman reported in ticket-32484 : > Sometimes model names are so unfortunate that default alphabetical order > of models in contrib.admin application makes no sense at all. > The same applies to

Re: Status of 4.1 pre-release.

Hi Carlton, there is somehow a contradiction: In https://code.djangoproject.com/wiki/Version4.1Roadmap it's written: Better yet, find someone to review your patch and mark the ticket as "Ready > for checkin". > but

Re: For discussion: JSON-aware views for error responses

I encountered this problem many times myself, so I'm +1 for this proposal. – 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

Re: Ticket #21289 - Login rate limiting

How about this proposal? Someone opens the login page. In addition to the visible fields username and password and the hidden field csrftoken we add another hidden field. This field contains the earliest (server-)timestamp a user might login, and lies in the near future, for instance now() +

Re: Issue with documentation page

The SSL certificate for docs.djangoproject.com was issued on December, 6th and is valid until March 6th, so that's not the problem. You're accessing that site through a misconfigured proxy, that's the problem. -- You received this message because you are subscribed to the Google Groups

Re: Proposal on how add configuration options to Email Backends

On Monday, January 31, 2022 at 7:55:47 AM UTC+1 f.apo...@gmail.com wrote: > Okay then, > > some of the things like sender reputation and different bounce hooks came > to my mind as well, but it is good to hear confirmation from others. I > think the next steps would be to create a new ticket to

Re: Proposal on how add configuration options to Email Backends

Well, that ticket is 8 years old and in the meantime other email backends have emerged, requiring different configuration options. I made this proposal after attempting to fix a 14 year old open ticket #6989 but this was ultimately postponed, see comment by Carlton Gibson on

Proposal on how add configuration options to Email Backends

This proposal attempts to address the following issues: https://code.djangoproject.com/ticket/6989 (14 years old) https://github.com/django/django/pull/13728 and https://code.djangoproject.com/ticket/31885 https://github.com/django/django/pull/13305 Currently all the parameters to configure the

Re: Admin webcomponents

In the past month, I have written a webcomponent, which encapsulates most of the functionality the Django admin's change view implements. It is very Pythonic/Djangonic in the sense, that it does not require to write any JavaScript, nor HTML. You can just use your Django Form as usual, warp it

Re: Developing an SPA version of Django admin

I really would like to see the django-admin being more SPA-like. I therefore wrote a library which implements all the features of the admin's change view and much more. It is very Pythonic/Djangonic in the sense, that it does not require to write any JavaScript, nor HTML. You can just use your

Re: Django's issue tracker uses timezone CDT

On Monday, August 9, 2021 at 12:10:51 PM UTC+2 Adam Johnson wrote: > I'd be +1 on moving the default to UTC. > > Or we could change Trac to pick up the browser's timezone offset and > display datetimes accordingly. > The latter world be the cleanest solution. I'm not familiar with Trac's

Django's issue tracker uses timezone CDT

This presumably is a legacy from the days when Adrian Holovaty and Jacob Kaplan-Moss started the Django project in Kansas City. The Django issue tracker uses the timezone CDT which is correct for central Americas, but since Django became a world wide project, in my opinion this should either be

Re: Removal of USE_L10N setting

I in favor with René Fleschenberg's proposal to enforce localization using a template filter. It happened too often, that someone forgot to unlocalize a primary key in their templates causing unwanted results. -- You received this message because you are subscribed to the Google Groups

Re: Proposal to add attribute 'step' to FloatField and DecimalField

The problem with modulo on floats is, that due to rounding errors it often created weird results, for instance in Python-3.8 this happens: 3.5 % 0.1 = 0.09981 This btw. also applies to the builtin divmod and math.fmod functions. Therefore I proposed to do it via classic division and

Re: Proposal to add attribute 'step' to FloatField and DecimalField

Say, you have a value and step, both are floats, then if value / step is can be represented integer, the validation is fulfilled. Otherwise if the result has to be rounded to become an integer, a ValidationError shall be raised. Be aware of rounding errors. On Sunday, March 21, 2021 at 9:53:43

Re: Proposal to add attribute 'step' to FloatField and DecimalField

Great News! So please accept ticket #32559 . I then will assign myself to it and implement it. So I add step (or would you prefer step_value?) to IntegerField and FloatField, but not to DecimalField (because there it's handled through

Re: Proposal to add attribute 'step' to FloatField and DecimalField

> > We set maxlength/minlength on widgets for CharFields *because they map > from an already existing kwarg*. > > For the case of `step` on a FloatField we’d need to add a kwarg — but > that’s only there to set a single attribute on the widget. > > But FloatField also offers a min_value and

Re: Proposal to add attribute 'step' to FloatField and DecimalField

On Wednesday, March 17, 2021 at 12:49:48 AM UTC+1 in...@markusholtermann.eu wrote: > That sounds like a sensible feature. Do you want to open a ticket and > maybe implement it? > Hi Markus, ticket #32559 has been issued to propose this feature. If

Proposal to add attribute 'step' to FloatField and DecimalField

If someone wants to use the step attribute as provided by the HTML field , she/he has to specify that using for instance FloatField(widget=NumberInput(attrs={'step': 0.5})). Since the HTML standard offers a step attribute on input fields of type number, from my point of view, this feature shall

Re: Add image and phone_number fields to Django User auth model

No they should not! Django provides an easy way to extend (or replace) the built-in User model. There are far too many fields people might want to add and it would be a complete mess, if we would fulfill all of these requests. Please refer to the docs at

Re: Adding Origin header checking to CSRF middleware (#16010)

Shouldn't we consider to put the CSRF token onto the deprecation list anyway? All browsers released later than 2017 support the 'SameSite' cookie attribute , making the CSRF token obsolete. I don't know what kind of policy the Django Project follows in

Re: Replace the default django test runner to a more robust testing framework (like pytest)

There is already a ticket for this: https://code.djangoproject.com/ticket/25707 I'm actually very much in favor of switching to pytest. In my newer projects I use pytest exclusively. -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Proposal: Make the domain part of the Email Message-ID configurable

Here is a pull request to fix https://code.djangoproject.com/ticket/6989 https://github.com/django/django/pull/13728 -- 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

Re: Support for No-SQL database in Django

> Do you need aggregations, database functions, joins with filtering on >> foreign keys, etc.? Then you should consider a relational database anyway. >> Or would you just like to define models and have the Django admin >> generate some nice editors for your non relational data-model? >> If the

Re: Support for No-SQL database in Django

Hello Vineet, you can perfectly use MongoDB together with Django. In fact I do that in one of my projects and where I use it, it perfectly makes sense. The question you raised is, if the Django community can adopt the ORM for non-relational databases, such as MongoDB. I would say no, for the

Re: runserver MIME types on Windows

Hi Peter, as a co-maintainer of django-filer I experienced similar problems. Often you can not rely on the MIME-type provided by the uploading browser. In your situation, one possible solution would be to guess the MIME-type by looking at the magic header of the received file. For this purpose

Feature request: To plugin API, add hook to inform about plugin having moved in structure editor

After a plugin has been moved inside the structure editor, no hook method is called to inform the plugin that is has been moved inside the tree. This would be very useful in some situations, for instance to recompute the grid widths, etc. Implementing this is a no-brainer, just one additional

Proposal: Make the domain part of the Email Message-ID configurable

When Django's mail subsystem generates an email, it creates a unique Message-ID. This is a requirement specified in RFC2822 https://tools.ietf.org/html/rfc2822#section-3.6.4>. The domain part of that Message-ID is generated by the Python network utilities. It defacto is the domain name

Re: Security release for djangocms-text-ckeditor

Hi folks, I have released a security update for https://github.com/divio/djangocms-text-ckeditor as version 3.10.0 It fixes a XSS vulnerability found in earlier versions of CKEditor. This release upgrades CKEditor to version 4.14.0. – Jacob -- Message URL:

Security release for djangocms-text-ckeditor

I'd like to release a new version of djangocms-text-ckeditor . Possible versions would either be 3.9.2 or 3.10.0. This is because we really should upgrade to a newer version of CKEditor, since the current one (4.7.3) has a documented XSS

Re: f-strings again.

I strongly agree with Mariusz on I would also be in favor of keeping only %-formatting and f-strings in > Coding style docs. I don't see any reason to use also `format()` in a new > code. so +1 from my side for f-strings. Actually, in one of my side projects, %-formatting wouldn't even

Re: Admin webcomponents

I'm very much in favor of this. Getting rid of jQuery is a very important step to make Django future-prove. In my other (non-legacy) projects, I currently replaced all JavaScript against webcomponents. I actually made good experience with the StencilJS compiler. Compared to Svelte, I really

Re: Question about the PlaceholderAdminMixin for a model using placeholder fields

As far as I know, you need this, when using the templatetag render_placeholder in one of the templates rendering an object with its placeholderfield. Otherwise Django-CMS does not know how to handle the structure mode, etc. -- Message URL:

Re: Proposal: FileSystemFinder and AppDirectoriesFinder shall serve unminimized assets in DEBUG mode

On Friday, April 24, 2020 at 7:21:24 AM UTC+2, Carlton Gibson wrote: > > For instance if we were to include a compression step, you’d always just > reference the raw assets, these being processed, with source maps if we had > that, for production. > It certainly is the proper approach to refer

Proposal: FileSystemFinder and AppDirectoriesFinder shall serve unminimized assets in DEBUG mode

When specifying paths to assets like JavaScript files, but also CSS, the Django documentation states: > Any links to the file in the codebase should point to the compressed > version. >

Re: CrossDB JSONField — Testing needed.

The reason it behaves differently to jsonfield and jsonfield2 is that it does not use the built-in django.core.serializers.json.DjangoJSONEncoder. Therefore serializing Decimal fields fails. In my opinion the basic types, such as Decimal and Date/Time fields shall be serializable to JSON, but

Re: CrossDB JSONField — Testing needed.

Hi Carlton, hi Sage, I just tested this implementation against my JSONField form editor library, namely django-entangled , using SQLIte. As you can see from the testing matrix , everything works fine using

Re: CrossDB JSONField — Testing needed.

The error just reported, seems to be related to the use of Django's internal forms.DecimalField. If I change that to a FloatField, everything works as expected. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)"

Re: CrossDB JSONField — Testing needed.

Hi Carlton, hi Sage, I just tested this implementation against my JSONField form editor library, namely django-entangled , using SQLIte. As you can see from the testing matrix , everything works fine using

Re: declarative settings

You have hit a salient point in Django. It indeed is a mess how every third party application must add its own configuration classes in order to make their own default settings configurable through a settings.py. This results in settings directives which can have any attribute name and do not

Proposal: Drop model menu.models.CacheKey

During my work on a faster implementation of the MenuRenderer, I came across the model menu.models.MenuCache . This models in my opinion doesn't make any sense at all, and could be dropped. It has been added in 2010 without

Optimize MenuRenderer and make it configurable

One of the problems with the current MenuRenderer is, that it takes far too long to build the menus for large page trees. This has already been addressed by Stefan Foulis 3 years ago in this issue: https://github.com/divio/django-cms/issues/5802 Now, for my

Re: Form customization

> > > Hi Jacob — Possibly. Sounds like a moderate change... — what would it look > like? — proof of concept. (As ever... :) > > Something similar such as the templatetag render_form from django-restframework ,

Re: Form customization

With Django-1.10 we got the ability to override form fields with our own templates, however the form structure is still hard-coded. Examples are BaseForm.as_table() , BaseForm.as_ul()

Re: Redis cache support in core

I'm also in favor on having it as part of the core, since memcache is also supported. One of the nice features Redis provides, is the possibility to invalidate one or more cached object by using a wildcard key. It namely is the method delete_pattern() added by django-redis-cache to the given

Re: Adding generated common table expressions

For my better understanding, could you please elaborate on what you mean by Hashes.as_literal(input_hashes) ? -- 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

Re: Proposal to format Django using black

Well, this thread is a very good example of Parkinson's law of triviality . –– Jacob -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from

Re: Proposal to format Django using black

I share the opinion of Mariusz Felisiak, Luke Plant and Claude Paroz, and believe that it is a bad idea to do this in an automatic way without the possibility to interfere manually. - Jacob -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Proposal to format Django using black

To address some of Curtis Maloney's concerns: > > 1. automated code formatting will be a great boon - reduce work, lower > barrier for new committers, reduce work for the fellows, etc. > > 2. there are issues with git history in doing "the great commit". > > 3. there are issues with black's