About #33904, Many-To-Many field is deleted/ignored from internal JavaScript “filter” interface

Dear group, ticket https://code.djangoproject.com/ticket/33904 was closed with https://code.djangoproject.com/changeset/0756c61f2ada56e4ae625589099c0141a77737eb/ However, it seems that that commit has a fix for #33893, not for #33904 ? Best regards, Carsten -- You received this message becaus

Re: About #33904, Many-To-Many field is deleted/ignored from internal JavaScript “filter” interface

eleases/4.1.1/ > <https://docs.djangoproject.com/en/4.1/releases/4.1.1/> > > Can you give stable/4.1.x a try and confirm it fixes your problem? If it > doesn't work please reopen the ticket with a comment to that effect. > > Thanks! > > On Tue, 23 Aug 2022

#29120 and #29502: autocomplete requires view permission

Dear group, with https://code.djangoproject.com/ticket/29120 it was documented that the change permission of the related model was needed, later https://code.djangoproject.com/ticket/29502 reduced this from change to view permission. However, there is a problem that was well described in this

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

Hello, unfortunately, the emails sent by the forum have long prefixes in the subject lines, e.g. [Django Forum] [Django Internals/ORM] Multiple Database Switching That makes the messages easy to filter by mail client software, but comes at the cost of much visual clutter that is hard to parse,

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

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 surpri

Conclusion of ticket #26761

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 analogous

Re: Proposing the removal of Oracle from the Django supported backend databases

Hello, when I got started with Django more than 10 years ago, I had inherited a legacy project with an Oracle database for porting from PHP to Python. It might also have worked out well if Oracle support had been a 3rd party package, but I can say for sure that Oracle being a core feature of Dj

Re: GitHub migration done!

Hi all, On Saturday, April 28, 2012 5:08:09 AM UTC+2, Adrian Holovaty wrote: > > On Fri, Apr 27, 2012 at 11:50 AM, Adrian Holovaty wrote: > > We're going to do the migration to GitHub today. This means we'll no > > longer be committing code to our Subversion repository. Committers, > > please h

Problem with creating a one-to-one instance

Dear Django devs, sorry to bother you here, but I posted to django-users first (https://groups.google.com/d/msg/django-users/WHnCxHkEVjE/9puR4youvwsJ) and there was no reply, so please let me re-try here: I'm probably overlooking something very simple, but still cannot explain what the code be

Re: Problem with creating a one-to-one instance

Hi Jacob, hi Florian, Am 19.04.2013 18:18, schrieb Jacob Kaplan-Moss: Unfortunately, we can't help you. Django-developers isn't a "second level" for django-users; they're completely different lists. The purpose of this list is to discuss the development of Django itself, not answer user question

__ne, #5763

Hi all, sorry if this is a stupid question, but after having read https://code.djangoproject.com/ticket/5763 and the discussions linked from it, why should __ne not be implemented? Without __ne, I'm experiencing the same problems that asmoore82 described at https://code.djangoproject.com/ticke

Re: __ne, #5763

Hi Marcin, Am Samstag, 21. November 2015 02:22:10 UTC+1 schrieb Marcin Nowak: > > On Friday, November 20, 2015 at 8:37:02 PM UTC+1, Carsten Fuchs wrote: >> >> sorry if this is a stupid question, but after having read >> https://code.djangoproject.com/ticket/5763 an

Re: __ne, #5763

Hi James, Am Samstag, 21. November 2015 02:56:45 UTC+1 schrieb James Bennett: > > 8 years later, I still think we should figure out how to make exclude() do > what people expect it to do, rather than implement another lookup type that > overlaps with it. > What really confuses me is how exclude

Re: __ne, #5763

Am Samstag, 21. November 2015 02:27:42 UTC+1 schrieb Aaron C. de Bruyn: > > With all due respect, looking through the ticket and reading responses > shows me that the 'pro' side has good use cases for __ne, and the 'con' > side basically says "use exclude" or "a core committer close the ticket,

Re: __ne, #5763

Hi Marten, Am 2015-11-21 um 11:53 schrieb Marten Kenbeek: The 'con' side argument is that it would create in inconsistency in the API, since we don't have any other negated lookups either. If we can get the same behaviour by fixing the current API, Django should not introduce an unnecessary cons

Re: __ne, #5763

Hi Anssi, Am 2015-11-21 um 12:50 schrieb Anssi Kääriäinen: In summary, the imaginary query of comment 14 Blog.objects.filter(entry__tag__name='django', entry__author_count__ne=2) This isn't a real query. There isn't a field author_count, the query needs an annotation somewher

Re: __ne, #5763

Dear Anssi, Am 2015-11-22 um 13:53 schrieb Anssi Kääriäinen: The author_count name suggested this was an aggregation. If this is just a regular field, then things are a bit simpler. Note that negated Q-object + filter and exclude() queries are the same thing. [...] There is a fix for exactly t

Re: Making startproject's settings more 12-factor-y

Hello, Am 25.06.20 um 19:51 schrieb Kit La Touche: > […] Once we see how this gets used, we can see about passing it a file > instead of `os.environ`, […] This is probably a stupid question, but what is the advantage of this (and env vars) over this: In project_dir/project_dir: settings.py lo

Re: Development story for CBV FormViews using GET

oglegroups.com>. > To post to this group, send email to django-developers@googlegroups.com > <mailto:django-developers@googlegroups.com>. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.

Re: Deferring "Sign the CLA"

Am 01.05.19 um 01:11 schrieb Tobias McNulty: > In the absence of information to the contrary, I'd hazard a guess that we > still need the CLAs... I don't know to what extend this applies to Django, but here someone argues that CLAs are not necessary at all: http://ebb.org/bkuhn/blog/2014/06/09/

After #28321 len(formset.forms) != len(formset.errors) is possible

Dear group, I just upgraded from Django 1.11 to 2+ and thereby found https://code.djangoproject.com/ticket/28321 The ticket was resolved with commit https://github.com/django/django/commit/f32d24652b920135eb6a0f3de74599f03e181731 Well, this change leaves us with a situation where `formset.forms