Feature Idea: extend dumpdata command with django-filters

I recently had the need to dump a huge table using the Django dumpdata command but I only needed a subset of records base on some standard filter. I think there is already an external package for this, but for basic filtering I think it would be useful to have it integrated in Django simply

Re: Feature Idea: Allow setting session cookie name dynamically

Ah, thank you for explaining. I missed the point and the existing setting, sorry. Cheers, Maciej wt., 7 cze 2022 o 11:26 Florian Apolloner napisał(a): > Hi Maciej, > > You can already customize the cookie name via a setting. What this request > is asking is customization based on the request

Re: Feature Idea: Allow setting session cookie name dynamically

Hi Maciej, You can already customize the cookie name via a setting. What this request is asking is customization based on the request object which is not that common. Did you check that you configured your applications correctly to use different cookie names

Re: Feature Idea: Allow setting session cookie name dynamically

Hi Dan and Carlton, In my current company I am impacted by conflicting session cookie name. We have several internal tools built on Django, available in the internal network under the same top-level domain. The scope of session cookies apparently was set on more than one service to a wildcard.

Re: Feature Idea: Allow setting session cookie name dynamically

Hi Carlton, thanks for the response. An external package might be useful, although the code majority of the code would be the copied SessionMiddleware code and the tiny changes to allow a dynamic cookie name, so my thoughts is that this might be "too small" for a published pypi package? But

Re: Feature Idea: Allow setting session cookie name dynamically

Hey Dan. Thanks for following up here. Just to recap, my reasoning on the ticket was that it's quite a niche use-case. For me, just use the custom SessionMiddleware, or put that in a third-party package for multi-tenancy folks to maintain together. (Or so would be my opening thought... --

Feature Idea: Allow setting session cookie name dynamically

Hi, Currently it's only possible to use a single session cookie, but it can be useful in a multi-tenant application to use multiple session cookies. To solve this we currently use our own, slightly modified SessionMiddleware class that we keep in sync with the official implementation and

Re: Feature Idea for overwrite_default_connection context manager

That's a great idea, actually. Thank you On Wednesday, June 1, 2022 at 4:56:31 PM UTC+3 Adam Johnson wrote: > Modifying the connections object seems like the wrong way to approach > this, as it's not intended for mutation. Did you consider writing a > database router and then having a context

Re: Feature Idea for overwrite_default_connection context manager

Modifying the connections object seems like the wrong way to approach this, as it's not intended for mutation. Did you consider writing a database router and then having a context manager that affects the router's state?

Feature Idea for overwrite_default_connection context manager

In some of the previous version on Django I had a very useful context manager. from contextlib import ContextDecorator from django.db import connections class overwrite_default_connection(ContextDecorator): prev_default = None write_connection = None def __init__(self,

Re: A new feature idea

Hi Ath In my experience the analytics that website operators are interested in varies vastly between projects. There are also many competing popular solutions. I don't think we'd include any analytics package inside Django at this point. But I don't mean to discourage you, it could be a good

A new feature idea

I was seeing some website and came across a blog site, which have a small section which show monthly visits and other things like that. An idea came in my mind that to make a admin like page which show total website visits,modal read and write,update,deletion , many filters to filter on basis

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

*Requesting reviewers* for the latest iteration of the PR to bulk-associate many-to-many relationships. *The new PR to review*, which is *only a documentation change* showing how to bulk-associate many-to-many relationships, is here: https://github.com/django/django/pull/11948  In case it's

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

Here's the link to the PR for review: https://github.com/django/django/pull/11899 (Apologies for the double-post) - David On Sunday, October 13, 2019 at 3:37:07 PM UTC-7, David Foster wrote: > > I've created a PR which is waiting for review, if someone has time. > > According to Trac, the next

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

I've created a PR which is waiting for review, if someone has time. According to Trac, the next step is: For anyone except the patch author to review the patch using the patch review checklist

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

Trac ticket created: https://code.djangoproject.com/ticket/30828 On Tuesday, October 1, 2019 at 3:02:38 AM UTC-7, Tom Forbes wrote: > > Hey David, > I like this idea, while I don’t think the use case is common there have > been a few times where I’ve needed this and got around it by >

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

Hey David, I like this idea, while I don’t think the use case is common there have been a few times where I’ve needed this and got around it by creating/modifying the through model in bulk. Having a method that does this would be good IMO. Unless anyone has strong opinions against this then can

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

Here is another API variation I might suggest: M1.m2_set.add_pairs(*[(m1, m2), ...], assert_no_collisions=False) # --- OR --- M1.m2_set.add_pair_ids(*[(m1_id, m2_id), ...], assert_no_collisions=False) This has the advantages of being more similar to the existing add() API and not requiring a

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

Errata: The proposed default value for assert_no_collisions is False rather than True, for safety. On Thursday, September 26, 2019 at 10:45:45 AM UTC-7, David Foster wrote: > > Given the following example model: > > class M1(models.Model): > m2_set = models.ManyToManyField('M2') > > It is

Feature idea: bulk_associate: Add ManyToMany relationships in bulk

Given the following example model: class M1(models.Model): m2_set = models.ManyToManyField('M2') It is already possible to associate *one* M1 with *many* M2s with a single DB query: m1.m2_set.add(*m2s) However it's more difficult to associate *many* M1s with *many* M2s, particularly if

Re: Feature idea: forms signals

Hi JP, That's a good point, sorry I didn't make it clear. The fork is installed from within the requirements file but you can also see it here, on the ticket_27923 branch: https://github.com/seddonym/django/tree/ticket_27923 I've updated the README to help. I'd be interested to hear if

Re: Feature idea: forms signals

Hello David, Is it possible to try to use it as part of the Django fork you mention, instead of the app ? I couldn't find any link on your github profile, your website and google but perhaps I've missed it. Thanks ! Best <3 -- You received this message because you are subscribed to the

Re: Feature idea: forms signals

I've put together a brief proof of concept here: https://github.com/seddonym/formsignals It demonstrates what you could do with post_init, post_clean and post_save signals, which I've also implemented in a fork of Django (no test coverage or documentation yet though). The concept it

Re: Feature idea: forms signals

Hello, > On 10 Mar 2017, at 10:25, Florian Apolloner wrote: > > On Friday, March 10, 2017 at 10:12:54 AM UTC+1, David Seddon wrote: > What are the next steps? Shall I create a pull request, or does this need > more consensus first? > > Imo absolutely more consensus,

Re: Feature idea: forms signals

On Friday, March 10, 2017 at 10:12:54 AM UTC+1, David Seddon wrote: > > What are the next steps? Shall I create a pull request, or does this need > more consensus first? > Imo absolutely more consensus, especially (to minimize the work for you), please do not just suggest the signals but also

Re: Feature idea: forms signals

I've created a ticket for this here: https://code.djangoproject.com/ticket/27923#ticket What are the next steps? Shall I create a pull request, or does this need more consensus first? David On Wednesday, 8 March 2017 17:46:12 UTC, Melvyn Sopacua wrote: > > On Wednesday 08 March 2017 18:18:26

Re: Feature idea: forms signals

On Wednesday 08 March 2017 18:18:26 Melvyn Sopacua wrote: > On Monday 06 March 2017 10:10:41 David Seddon wrote: > > Hi all, > > > > One thing I've always found challenging with Django is to adjust the > > functionality of forms from other apps. An example might be to add > > an extra field to a

Re: Feature idea: forms signals

On Monday 06 March 2017 10:10:41 David Seddon wrote: > Hi all, > > One thing I've always found challenging with Django is to adjust the > functionality of forms from other apps. An example might be to add an > extra field to a login form provided by a third party module. > > What I end up doing

Re: Feature idea: forms signals

Seems similar to this discussion: https://groups.google.com/forum/#!searchin/django-developers/forms%7Csort:relevance/django-developers/zG-JvS_opi4/wS-4PBfPBwAJ Yes, signal/slot is a pattern that allows quick and easy decoupling of components that have to work on the same payload, and I've been

Re: Feature idea: forms signals

Hi David, It's good to hear that you did significant research in this area (which I couldn't tell from your original email). I get how this feature can come in handy and I won't stand in the way if it gets implemented. Improving the guidance about when (not) to use signals in the process

Re: Feature idea: forms signals

I totally agree that signals are open to misuse, and I take your points. Inexperienced developers often seem to use them just because they're there, rather than to encapsulate their apps and avoid circular dependencies. The Django signals documentation could probably do with a bit more

Re: Feature idea: forms signals

Hello, My experience with Django — and not just with inexperienced developers — is that signals are a footgun. I've seen them misused as workarounds for badly structured code and unclear dependency trees too often. I'm not eager to encourage their use. Fundamentally, signals in Django allow a

Feature idea: forms signals

Hi all, One thing I've always found challenging with Django is to adjust the functionality of forms from other apps. An example might be to add an extra field to a login form provided by a third party module. What I end up doing is often overriding the urlconf, view and form class. Or,

Re: Feature idea

Hello Bruno, This is getting quite specific. In that case, I think a third-party, pluggable application is a better way to do this. Best regards, -- Aymeric. > On 17 Nov 2016, at 13:38, Bruno Ribeiro da Silva > wrote: > > Guys, > > Thanks for the feedback. My

Re: Feature idea

Guys, Thanks for the feedback. My initial thought was to have a more complete approach to this problem, there is always the case that the admin who is creating the user doesn't know the person's full name and/or what to use for username. This is the flow that I had in mind: - Admin goes to user

Re: Feature idea

My solution to the "initial password problem" is to send a password reset token first... And Django has this built in, handily :) http://musings.tinbrain.net/blog/2014/sep/21/registration-django-easy-way/ It would be very easy to use the same approach for an "invite" registration pattern.

Re: Feature idea

Hello, > On 16 Nov 2016, at 21:22, Anthony King wrote: > Sending a link to set a password isn't much better. > The cardinal rule of passwords is “you must be the only person who knows your password”. This means never writing it down anywhere, except in a proper

Re: Feature idea

Sending a link to set a password isn't much better. Perhaps a way to force a password change on login would be better, which has more use elsewhere, such as being able to periodically force password changes On 16 Nov 2016 8:13 p.m., "Aymeric Augustin" < aymeric.augus...@polytechnique.org> wrote:

Re: Feature idea

Hello, I wouldn’t dismiss the idea so quickly. Adding staff users from your company is a fairly common use case. Currently you have to email them a password and ask them to change it. This doesn’t set a good example. The better solution is SSO with the corporate directory (often

Re: Feature idea

I don't think this registration model is common on most websites. On Wednesday, November 16, 2016 at 2:24:43 PM UTC-5, Bruno Ribeiro da Silva wrote: > > Hello everyone, > > I have this simple idea that I think django could benefit from, which > would be the option to create a user by an

Feature idea

Hello everyone, I have this simple idea that I think django could benefit from, which would be the option to create a user by an invitation from the django admin page. So the person who is creating a new user doesn't have to type a password neither a username for this new user. He would only fill

Re: Feature idea: Add support for PostgreSQL's COPY command in contrib.postgres

+1 for this integration. This is a great feature that I've been using on projects as well. I'd love to be able to do it within django rather than hack my own sql scripts around it. The efficiency/speed up is very real. This solves the problem that when working with data where people replicate

Re: Feature idea: Add support for PostgreSQL's COPY command in contrib.postgres

+1 for this feature addition. I work with a lot of public data and I almost always go through the steps of loading data into PostgreSQL and building from there. COPY reduces data load time significantly so a core load command for Django is welcome. I've used LOAD DATA INFILE for MySQL on

Re: Feature idea: Add support for PostgreSQL's COPY command in contrib.postgres

Glad you're interested! 1. Yes you can. You can use the field or model method transformations to provide any SQL you'd like. PostgreSQL has a to_timestamp

Re: Feature idea: Add support for PostgreSQL's COPY command in contrib.postgres

That looks interesting - I might be able to use your module for a project I'll be working on soon. Two questions I had about data transformation from the temp column to model column. 1. Can you create datetime stamps from the text data? 2. Can you skip rows where a column == "unwanted data"?

Feature idea: Add support for PostgreSQL's COPY command in contrib.postgres

Hello, I am a big fan of PostgreSQL's excellent bulk loader COPY . It can rapidly load a CSV file directly into the database, an oftentimes tedious task that I have to do frequently as part of my job. I am not a big fan of having to

Re: new feature idea: even and odd forloop iteration variables

Hi skazhy, > I've been working with Django for a while now, but today I decided to > make a first contribution to Django that would make templates less > ugly by adding these two values to loop_dict (in django/template/ > defaulttags.py): > > loop_dict['even'] = (i %2 == 0) > loop_dict['odd'] =

Re: new feature idea: even and odd forloop iteration variables

On Tue, Sep 20, 2011 at 2:57 AM, Travis Swicegood wrote: > Hey Karlis; > This is a cool idea.  I don't do enough template work to always remember the > cycle syntax, but an odd/even is pretty simple to remember. I disagree, for a number of reasons * There should be Only

Re: new feature idea: even and odd forloop iteration variables

Hey Karlis; This is a cool idea. I don't do enough template work to always remember the cycle syntax, but an odd/even is pretty simple to remember. As for getting this into Django, check out the Contributing Docs[1]. It has everything you need on how to help out. In particular the Requesting

Re: new feature idea: even and odd forloop iteration variables

On 09/19/2011 12:58 PM, skazhy wrote: Hi all! I've been working with Django for a while now, but today I decided to make a first contribution to Django that would make templates less ugly by adding these two values to loop_dict (in django/template/ defaulttags.py): loop_dict['even'] = (i %2 ==

new feature idea: even and odd forloop iteration variables

Hi all! I've been working with Django for a while now, but today I decided to make a first contribution to Django that would make templates less ugly by adding these two values to loop_dict (in django/template/ defaulttags.py): loop_dict['even'] = (i %2 == 0) loop_dict['odd'] = (i %2 != 0)

Re: Feature idea

On Wed, Jun 2, 2010 at 3:14 PM, Jacob Kaplan-Moss wrote: > Aat EuroDjangoCon Russ and I discussed a "startup" mechanism that'd > cover this use case, as well as a whole lot more. There's a few hints > in the logging discussion a few threads down. > > So I'm -1 on this specific

Re: Feature idea

On Wed, Jun 2, 2010 at 9:28 PM, Gregor Müllegger wrote: > I don't know much about the startup proposal, but I expect it to be a > startup.py file in an application folder that gets loaded right after > the django internals are ready and before the models have been loaded. >

Re: Feature idea

Hi Jacob, I don't know much about the startup proposal, but I expect it to be a startup.py file in an application folder that gets loaded right after the django internals are ready and before the models have been loaded. The mechanism we ask for in this thread is something different. It would be

Re: Feature idea

Aat EuroDjangoCon Russ and I discussed a "startup" mechanism that'd cover this use case, as well as a whole lot more. There's a few hints in the logging discussion a few threads down. So I'm -1 on this specific proposal, but only because I expect it to be obsoleted by me and Russ' startup

Re: Feature idea

On 06/01/2010 09:42 PM, Sean O'Connor wrote: I've been generally thinking about putting together a package of reusable tools to implement common "patterns" for reusable apps. Included in this would be this type of auto-discovery system as well as a registration pattern. Auto-discovery and

Re: Feature idea

Hi Dj Gilcrease, I've almost implemented kinda similar proposal (draft here: http://groups.google.com/group/django-developers/browse_thread/thread/b7339d8577567d95 ), and what worries me, is that in current Django you just can't do autodiscover of django contribs in settings.py because of

Re: Feature idea

I would volunteer for the development needed to get this into django. I will start working on it right after a core developer has looked into this discussion and points out if my proposal is at least the right direction. -- Servus, Gregor Müllegger 2010/6/1 Dj Gilcrease :

Re: Feature idea

On Tue, Jun 1, 2010 at 3:02 PM, Gregor Müllegger wrote: > My proposal would go into the direction of pulling the autodiscover > function out of the django.contrib.admin module and putting it > somewhere in the core. Since the admin needs some special > functionality on

Re: Feature idea

I've been generally thinking about putting together a package of reusable tools to implement common "patterns" for reusable apps. Included in this would be this type of auto-discovery system as well as a registration pattern. Unfortunately I probably won't get much practical work done on this

Re: Feature idea

I like the idea of boxing up the autodiscover code into a publicly accessible utility class... it's a problem many people solve for themselves (myself included) but even moreso it would go well with the new startup.py proposal that's in the works. Once it's easy to have things run once at

Re: Feature idea

I also needed this functionality in one of my apps and just went the way of copy and pasting the existing solution that is already implemented in django.contrib.admin. But making this code reuseable would IMO be a benefit for some app developers. But I think the approach of using an setting for

Feature idea

There are currently several modules / apps that require auto discovery based on whats listed in INSTALLED_APPS. admin, django_nav, and the proposed startup.py and I know one or two other apps that use similar methods but cannot remember their names off the top of my head. I would like to propose