tickets

32,817 rows sorted by status

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: stage, status, resolution, has_patch, changetime (date), last_pulled_from_trac (date)

needs_better_patch 2 ✖

  • 0 30,800
  • 1 2,009
id created changetime last_pulled_from_trac stage status ▼ component type severity version resolution summary description owner reporter keywords easy has_patch needs_better_patch needs_tests needs_docs ui_ux
470 2005-09-07 13:45:25 2022-03-01 05:55:35 2022-03-06 03:20:48.232775 Accepted assigned Database layer (models, ORM) New feature normal     Add Field.db_default for defining database defaults https://github.com/django/django/pull/13709 Apply this diff to django/core/mamagement.py Should work on any database. 75a76,77 > if f.default <> meta.fields.NOT_PROVIDED: > field_output.append("DEFAULT '%s'" % (f.default,)) joshiayush jws sql schema 0 1 1 0 0 0
2259 2006-06-28 19:20:45 2022-02-19 17:20:43 2022-03-06 03:25:30.037050 Accepted assigned contrib.admin Bug Normal dev   Primary keys should be readonly by default in admin When creating a simple model with a non-integer primary key, the Admin interface shows the field as editable, but when making a change, it seems to execute an incorrect query. For example: {{{ class Group(models.Model): name = models.CharField(maxlength=32, primary_key=True) def __str__(self): return self.name class Admin: list_display = ('name',) search_fields = ('name',) }}} When changing the primary key field (e.g. from 'Test' to 'TestX') when editing a record, a ProgrammingError exception is raised. The SQL that is generated is: {{{ UPDATE "config_group" SET WHERE "name"='Test' }}} This is missing the primary key field to be changed after SET. This is with the latest SVN code. It seems to be an issue around line 179 of db/models/base.py where it only adds the non-pk columns after SET. siddhartha-star-dev ed@edplese.com   0 1 0 1 0 0
3461 2007-02-08 20:38:52 2020-07-29 07:41:45 2022-03-06 03:28:46.362732 Accepted assigned Database layer (models, ORM) Bug Normal dev   DatabaseWrapper should pass through args and kwargs to underlying database adapter Currently the DatabaseWrapper (at least for the postgresql) does not pass args and kwargs for cursor() calls to the underlying database adapter. This makes it impossible to use the adapter fully at the low level. For example, to use dict cursors in psycopg2 you have to pass a different cursor factory via the cursor_factory keyword argument to cursor(). The attached patch passes through args and kwargs for cursor() calls. auvipy Jack Moffitt <metajack@gmail.com>   0 1 1 0 1 0
5711 2007-10-09 04:08:46 2016-09-10 14:45:42 2022-03-06 03:35:10.752092 Accepted assigned Core (Serialization) Bug Normal dev   Allow non-field attributes to be serialized It seems if I create a request set with extra(), the fields are not in the output generated by serialize(). senko valankar@gmail.com   0 1 1 0 0 0
6363 2008-01-11 19:15:42 2016-10-14 15:10:31 2022-03-06 03:36:56.468886 Accepted assigned contrib.admin Bug Normal dev   Login page is redisplayed without any message if AdminSite.has_permission() returns False I found a bug when using the has_permission method of the AdminSite class to filter which users can access the admin page: {{{ class SuperuserAdminSite(admin.AdminSite): def has_permission(self, request): return super(SuperuserAdminSite, self).has_permission(request) and request.user.is_superuser admin_site = SuperuserAdminSite() }}} When I try to log on a user that is not a superuser, it already get the login but stay on the login page (with the header but no application loaded), I think this is a bug :) The user should get a error message as if it passed a wrong password or such, isn´t it? yakky michelts   0 1 0 1 0 0
6376 2008-01-14 13:59:11 2019-07-03 08:53:02 2022-03-06 03:36:58.588792 Accepted assigned Internationalization New feature Normal dev   Allow using custom gettext domains I'm using django as a library in my non-web-based application. As such I prefer not to use the 'django' gettext domain but my own. I currently work around it with some symlinking trickery since being compatible with upstream django is more important than not having workarounds, but it would be great if django supported this. To illustrate what I mean, I've attached a simple and untested patch against current svn (rev 7020). R4G3-BABY dennis@kaarsemaker.net gettext 0 1 1 0 0 0
6989 2008-04-09 01:42:11 2020-11-27 20:21:11 2022-03-06 03:38:27.818961 Accepted assigned Core (Mail) Bug Normal dev   Inability to define DNS_NAME in django.core.mail results in e-mail messages being rejected or marked as spam '''Summary'''[[BR]] Being the case that the application server's hostname may not necessarily be a valid fully qualified domain name (FQDN) the use of socket.getfqdn() in defining DNS_NAME may yield a number of e-mail messages either rejected or marked as spam. Rejection issues arise if settings.EMAIL_USE_TLS is True - meaning smtplib.ehlo() will be called - and if a mail server is particularly strict (or misconfigured) and rejects any ehlo command followed by an invalid FQDN. Spam issues arise with DNS_NAME being used as the local_hostname argument to smtplib.SMTP() within the SMTPConnection.open() method, meaning the initial "Received:" e-mail header may be from an invalid FQDN. Further increasing the chance of being marked as spam is DNS_NAME being used by the make_msgid() method, leaving the "Message-ID:" e-mail header ending in an invalid FQDN. '''Real World Scenario'''[[BR]] A shared server has a hostname, which you may not and can not change, of "star-wars-reference". The socket.getfqdn() method fails to find info on its IP address and by default simply returns said hostname. E-mail is then sent by Django with a Message-ID of "200804....@star-wars-reference" from a server claiming to be "star-wars-reference ([server's IP address])" and is, of course, marked as spam. '''Solution'''[[BR]] Provide an optional settings variable such as EMAIL_LOCAL_HOSTNAME where Django developers may define a FQDN which maps to their application's server. EMAIL_LOCAL_HOSTNAME will be used by the class defining DNS_NAME in lieu of socket.getfqdn() if EMAIL_LOCAL_HOSTNAME exists in the settings file (this has the added benefit of preventing a call to socket.getfqdn() - further reducing overhead on restarts). jrief Franklin local_hostname, DNS_NAME, CachedDnsName, smtplib, SMTPConnection 0 1 1 0 1 0
8472 2008-08-21 15:58:44 2015-01-26 17:52:14 2022-03-06 03:42:21.934257 Accepted assigned contrib.admin New feature Normal dev   Add "Recent Actions" panel to app_index template This was a feature request and relates to the changeset in [http://code.djangoproject.com/ticket/1390 #1390]. The goal is to produce specified results for the Recent Actions panel (sidebar) to only display logged actions for that particular model. For example, at Home > Auth would only display logged actions for the apps pertaining to that model (e.g. User, Groups). burzak juliae   0 1 0 0 1 1
8912 2008-09-06 04:33:49 2021-01-09 01:02:51 2022-03-06 03:43:30.039022 Accepted assigned File uploads/storage New feature Normal 1.0   File storage and save/commit=False Background: I noticed this when playing with save_formset() on ModelAdmin in order to modify the data for a FileField on an inline model before it gets sent to S3 via a custom filestorage backend. In admin.py {{{ def save_formset(self, request, form, formset, change): instances = formset.save(commit=False) for instance in instances: if not instance.id: raise Exception('testing file creation') instance.save() formset.save_m2m() }}} Now, when saving a new inline instance which has a file field, the exception is raised before that instance gets save()'d. I kept noticing, however, that I would still get the full uploaded file with the proper name in my S3 account. So, I raised an exception in the _save() on my custom backend and walked it back to the formset.save(commit=False) call. It seems to me that the commit=False should keep file writes from happening; it doesn't. Looking in django/db/models/fields/files.py, the save() takes a save argument but doesn't use it when dealing with the save call to the storage backend. If the argument was passed along to the save on the storage backend, then it could decide whether or not to actually write the file. BenzhaminKim shadfc   0 0 1 0 1 0
8972 2008-09-08 17:35:43 2011-04-22 06:13:28 2022-03-06 03:43:39.683720 Accepted assigned GIS New feature Normal 1.0   Add ability to delete selected vector features within the Geodjango/OpenLayers Admin map interface This feature has been needed for some time, and was recently requested. See: http://groups.google.com/group/django-users/browse_thread/thread/36242edfd0d0281c?hl=en I've started a basic patch that adds a javascript function to allow multiple features to be selected in the map interface, deleted from view, and removed from the save method. I've tested this so far when editing multipolygon data in the admin. A known issue I'm hoping others may have a solution to: Currently, an OL javascript error occurs on line 948 of OpenLayer.js after successfully deleting a feature. This do not seem to cause any problems in saving the correct geometry or in continuing to use the select control. This is the firebug output: {{{ object is undefined selectFeature()(undefined)OpenLayers.js (line 948) clearSelectedFeatures()()277 (line 327) javascript:geodjango_geometry.clearSelectedFeatures()()()javascri...eatures() (line 1) [Break on this error] this.feature=null;this.dragControl.deact...ply(this.selectControl,[this.feature]);} }}} jbronn springmeyer OpenLayers, admin, vector editing 0 1 0 1 0 0
9373 2008-10-15 20:41:25 2014-12-18 21:39:03 2022-03-06 03:44:44.185994 Accepted assigned contrib.admin Bug Normal 1.7   "This field is required" error even on empty inlines formsets in the admin model page, when hiding a choice field of a custom form. I have a custom Form for one of my models (in the example !SecondModel) that adds one choice field with an initial value. If I use that model/form as an inline formset and I exclude the extra field using the "fields" attribute of the !ModelAdmin, I got "This Field is required" on all the forms of the formset, including those who where left blank. Here a simple example: {{{ #!python # models.py from django.db import models class FirstModel(models.Model): a = models.CharField(max_length=10) b = models.CharField(max_length=10) class SecondModel(models.Model): link = models.ForeignKey(FirstModel) c = models.CharField(max_length=10) # admin.py from django.contrib import admin from bug.bugged import models, forms class SecondAdmin(admin.TabularInline): model = models.SecondModel form = forms.SecondForm fields = ['c'] extra = 3 class FirstAdmin(admin.ModelAdmin): inlines = [SecondAdmin] admin.site.register(models.FirstModel, FirstAdmin) # forms.py from django import forms from bug.bugged import models DUMMY_CHOICES = ( (0, 'a'), (1, 'b'), (2, 'c') ) class SecondForm(forms.ModelForm): d = forms.IntegerField(label='d', initial=0, widget=forms.Select(choices=DUMMY_CHOICES)) class Meta: model = models.SecondModel }}} The problem is {{{fields = ['c']}}}, commenting out that line I get no errors. I guess, this is beacuse of the {{{has_changed}}} check, called by the {{{full_clean}}} method of {{{forms.Form}}}. It happens that {{{changed_data}}} compares the initial "d" value that had been set to 0 with the result of "field.widget.value_from_datadict(self.data,..." that is None because we have not a key for "d" in self.data. So changed_data will contain "d" even if the form has not been changed. From django/forms/forms.py {{{ #!python prefixed_name = self.add_prefix(name) data_value = field.widget.value_from_datadict(self.data, self.files, prefixed_name) … schacki tyrion.mx@gmail.com admin, inlines 0 0 0 0 0 0
9388 2008-10-17 11:03:58 2022-01-07 06:47:24 2022-03-06 03:44:46.528805 Accepted assigned contrib.admin New feature Normal dev   Made month and year selectable in admin calender widget. My colleague Javier de la Rosa has enhanced the calendar shown in admin's date fields to allow navigation through years, and not only through months. This requires changing calendar.js and DateTimeShortcuts.js. We have chosen not to maintain backwards compatibility because this should be a feature in Django 1.1, but it's easy to do if required. Javier de la Rosa will attach his patch later. ahmadekhalili framos admin calendar year previous next widget ui 0 1 1 1 1 1
9602 2008-11-14 19:23:15 2015-02-04 13:03:59 2022-03-06 03:45:16.530020 Accepted assigned contrib.admin New feature Normal dev   Add admin.site._registry manipulation methods This is a feature request... Currently, one can unregister a model from the admin and register it again with a new ModelAdmin. The problem I'm anticipating is when 2 or more apps want to add ModelAdmin options to a Model and the last one wins. Not to point out a specific 3rd party app, but this is an easily contrived example... If I have my own apps and one of them unregisters the User model's ModelAdmin and registers its own that, say, adds the `is_superuser` to the list_display. Then if I add the django-openid app that (currently) also unregisters the User model's ModelAdmin and registers its own that adds an inline to a ManyToManyField for the OpenID associations tied to that user. If django-openid is after my app in the INSTALLED_APPS list, I lose my list_display override. And if my app is after the django-openid app, I lose the OpenID associations inlines. (See: http://code.google.com/p/django-openid/source/browse/trunk/django_openid/admin.py) It's possible currently to write the unregistration/registration such that this doesn't happen, but it relies on pulling the ModelAdmin out of the "private" _registry dictionary in the admin.site class. For example: {{{ useradmin = admin.site._registry.get(User, None) if useradmin: useradmin.list_display = useradmin.list_display + ('is_superuser',) else: class MyUserAdmin(AuthUserAdmin): list_display = ('username', 'email', 'first_name', 'last_name', 'is_staff', 'is_superuser') admin.site.register(User, MyUserAdmin) }}} I can think of a few ways of fixing this, from least involved to more involved: 1. At the very least I think it would be nice if the internal `_registry` dictionary didn't have the prepended underscore to signify that it is a private variable not to be touched, so one doesn't feel dirty doing something like this. 2. I think it would be a bit cleaner if there were methods to lookup, get, and update this dict and keep it as a private dict. For example, something like `admin.site.get_model_admin(User)… anonymous robhudson register modeladmin 0 0 0 0 0 0
9739 2008-12-02 16:13:38 2019-11-29 10:16:32 2022-03-06 03:45:34.451359 Accepted assigned contrib.admin Bug Normal 1.0   Admin does not correctly prefill DataTimeField from URL I was not able to format URL for Admin interface to prefill DateTimeField with given value. It worked in 0.96, but does not work in 1.0 ( I used ../admin/MyApp/MyTable/add/?box=359&datum_date=2008-12-01&datum_time=17:30:27) After some looking on source code and testing i find a solution: - in /django/contrib/admin/options.py before line 520 add {{{ if isinstance(f, models.DateTimeField): initial[k] = initial[k].split(",") }}} - use this format: https://../admin/MyApp/MyTable/add/?box=359&datum=2008-12-01,17:30:27 For reference - the model of MyTable is such : {{{ class MyTable(models.Model): box = models.ForeignKey(Boxes) datum = models.DateTimeField(null=True, blank=True) }}} (plus some other insignificant fields. The "datum" field should be prefilled with some date, which is computed by long way (not simple now()) and the use must be able to edit it BEFORE saving it) ---- The problem arises from DateTimeField be treated by MultiWidget, but not properly broken when got by URL (GET) ----- Patch: {{{ --- options.py.old 2008-12-01 19:56:34.000000000 +0100 +++ options.py 2008-12-01 19:40:34.000000000 +0100 @@ -517,6 +517,8 @@ continue if isinstance(f, models.ManyToManyField): initial[k] = initial[k].split(",") + if isinstance(f, models.DateTimeField): + initial[k] = initial[k].split(",") form = ModelForm(initial=initial) for FormSet in self.get_formsets(request): formset = FormSet(instance=self.model()) }}} RidleyLarsen gilhad   0 1 1 0 0 0
10403 2009-03-03 18:21:58 2020-03-19 11:40:53 2022-03-06 03:47:11.452372 Accepted assigned Forms New feature Normal dev   provide declarative syntax to define FormSets - including ModelFormSet and InlineFormSet Provide a declarative mechanism to define modelformsets or inlineformsets. The attached patch allows definitions like this: {{{ class AuthorForm(forms.ModelForm): class Meta: model = Author class DeclarativeAuthorFormSet(forms.models.ModelFormSet): form = AuthorForm model = Author extra = 3 }}} and {{{ class BookForm(forms.ModelForm): class Meta: model = Book class DeclarativeAuthorBooksFormSet(forms.models.InlineFormSet): model = Book form = BookForm parent = 'author' }}} An advantage is that the defined form is directly used as the form class in the formset, not as a base class for a new form class (what inlineformset_factory does). This way specific field definitions and other customisations in the form work like they should so you don't need to redefine things in __init__(). Parth1811 Koen Biermans <koen.biermans@werk.belgie.be> formset modelformset inlineformset 0 1 1 1 1 0
10850 2009-04-17 06:38:01 2020-11-07 15:42:57 2022-03-06 03:48:24.371795 Accepted assigned File uploads/storage Bug Normal dev   Impossible to stop a large file upload mid-stream As described in [http://groups.google.com/group/django-users/browse_thread/thread/d4e4394c1b3d68dc/f8bc012acf797219?lnk=gst&q=StopUpload#f8bc012acf797219 this post] on the django-users group, raising {{{django.core.files.uploadhandler.StopUpload(connection_reset=True)}}} in order to cut off a too-large file upload does not work [http://docs.djangoproject.com/en/dev/topics/http/file-uploads/#required-methods as documented]. Nor does it work as specified in [http://code.djangoproject.com/browser/django/trunk/django/core/files/uploadhandler.py#L30 comments to the code], nor according to [http://code.djangoproject.com/ticket/2070#comment:275 a discussion] regarding the implementation of this feature. The connection reset functionality does work correctly using the development server, but not using mod_python or fastcgi on lighttpd or Apache. It seems that in both cases the webserver pre-loads the entire file, regardless of its size, without Django taking the opportunity to interrupt the stream, even if {{{StopUpload(connection_reset=True)}}} is raised by {{{receive_data_chunk()}}} inside a subclass of {{{FileUploadHandler}}}. The most egregious side effect of this defect is that while the file is uploading to the server, the server experiences significant slow-downs. In addition, without a fix, any restrictions on file-size for upload will not be delivered to users until they have waited for many minutes uploading their unacceptable file, a user-interaction failure that should be avoidable. mystmn legutierr upload, StopUpload 0 0 0 0 0 0
10944 2009-04-28 02:35:03 2018-02-08 12:01:35 2022-03-06 03:48:39.887440 Accepted assigned contrib.sites New feature Normal 1.0   Site app should be able to make absolute URLs. I wish Site instances could make (real) absolute URLs (e.g. http.../path/) based on a given relative path like /path/. And a template tag to make it nicer from templates, too: {% site_url ... %} or similar. Can I have a pony? I'll write the patch if I can have a pony. krzysiumed jdunck   0 1 1 0 0 0
11593 2009-07-29 19:30:41 2019-02-15 11:11:22 2022-03-06 03:50:18.847428 Accepted assigned Testing framework New feature Normal dev   Incomplete support for app-level testing Django and its community have a pretty strong focus on the concept of reusable applications: applications as pluggable behavior blocks, independent from one another and from projects. And the test framework documentation and setup emphasize that: the documentation page is called [http://docs.djangoproject.com/en/dev/topics/testing/ Testing Django applications] and the test themselves are saved at the application level not at the project level. Yet Django provides no provision whatsoever for running tests from an application: a project (or at least a settings and a urls file) is required, and barring fairly weird setups (global settings and urls modules) there is no way to create a new app, write a test and run it just like that. Which means applications aren't as self-contained as they could be, and can't easily be tested "in a void" (independently of everything else). RaphaelKimmig masklinn   0 1 1 0 0 0
11803 2009-08-30 14:18:30 2022-02-16 09:28:36 2022-03-06 03:50:47.756084 Accepted assigned contrib.admin Bug Normal dev   Admin does not update every ForeignKey select of the same model Consider I have the following models: {{{ #!python class City(models.Model): name = models.CharField(80) state = models.CharField(2) class Person(models.Model): living_city = models.ForeignKey(City) born_city = models.ForeignKey(City, related_name='born_city_set') }}} When I go to admin to add a new `Person`, I have the option to add a city at `living_city` select and `born_city` select, if I add a city at `living_city` select, for example, the `born_city` select does not update automatically, it remains empty or without the new option. mgaligniana danilo <danilo.cabello@gmail.com> admin select foreignkey 0 1 1 0 0 0
11927 2009-09-22 13:54:20 2020-01-31 14:06:07 2022-03-06 03:51:08.728490 Accepted assigned Core (Management commands) New feature Normal dev   Allow manage.py dumpdata to dump YAML in block style Using {{{ python manage.py dumpdata --format=yaml }}} produces output in [http://pyyaml.org/wiki/PyYAMLDocumentation#Dictionarieswithoutnestedcollectionsarenotdumpedcorrectly flow style]. That's OK for automated processing, but it isn't anything like as human-readable as block style YAML. For people who, like me, need to edit the fixtures manually, it would be very useful to be able to do something like: {{{ python manage.py dumpdata --format=yaml --flowstyle=false }}} matthijskooijman sampablokuper   0 1 1 0 0 0
12090 2009-10-26 16:19:44 2021-02-22 20:27:06 2022-03-06 03:51:35.059221 Accepted assigned contrib.admin New feature Normal dev   Show admin actions on the edit pages too Currently the workflow for comment moderation might look like this (without knowing the comment moderation admin actions ;)): * Look at the overview page * If in doubt open the comment in a new page * if it's spam go back to the previous page, select it and execute the admin action We could redisplay the admin actions box in the detail views (where they of course would only effect the current object) to prevent the unneeded roundtrip. jgmize apollo13   0 1 1 0 0 1
12498 2010-01-04 02:20:04 2013-03-14 22:05:47 2022-03-06 03:52:43.549673 Accepted assigned Forms New feature Normal     Add multi-field validators Multi-field validator functionality was taken out of the model-validation branch in [12078]. Add it back in. See [http://groups.google.com/group/django-developers/browse_thread/thread/d4a4bf8607f4b8a this thread] on django-developers for more details. There's also a more extensive and older [http://groups.google.com/group/django-developers/browse_thread/thread/436307e426844ae0/f2fa0647b97569ad discussion] that I missed. Thank you mrts for pointing it out. jkocherhans jkocherhans   0 1 1 0 0 0
12772 2010-02-04 12:19:03 2014-12-27 01:57:26 2022-03-06 03:53:25.067918 Accepted assigned Template system New feature Normal 1.2-beta   Allow loading template tags by fully qualified python module path Currently templatetags are magically searched for in the list of installed apps. This leads to all kind of problems when debugging code, starting from being forced to use find to locate tag libraries and ending with global namespace collisions. The attached patch adds the possibility to import tags by fully qualified module path by first trying to make an absolute import and only then falling back to searching inside installed apps. This also allows people to import tag libraries that are not parts of any application (so common tags can be kept together without the need of adding a fake app). Also: "Explicit is better than implicit." :) patrys patrys   0 1 1 1 1 0
13659 2010-05-28 16:05:59 2021-03-26 09:38:04 2022-03-06 03:55:48.674558 Accepted assigned contrib.admin New feature Normal dev   Make the request accessible in callables used in ModelAdmin.list_display Its a nice feature of the dajngo admin that you can use names of model or model admin methods and plain callables in ModelAdmin.list_display. But I want show content in my custom column dependant on the logged in user. This isn't possible at the moment. But I have written a patch that passes the request object to the given callable or method, when it has the needs_request attribute and it is True. czpython sebastian_noack   0 1 1 0 1 0
13677 2010-06-01 20:05:56 2019-06-20 13:11:26 2022-03-06 03:55:51.356314 Accepted assigned Forms Bug Normal dev   ModelFormSet may query wrong database backend When using a !ModelFormSet with a queryset using a DB different from the 'default' one, the validation of the fields fails. debugging the code shows that the db used is the wrong one: {{{ -> self.instance.clean_fields(exclude=exclude) /usr/lib/pymodules/python2.5/django/db/models/base.py(902)clean_fields() -> setattr(self, f.attname, f.clean(raw_value, self)) /usr/lib/pymodules/python2.5/django/db/models/fields/__init__.py(194)clean() -> self.validate(value, model_instance) /usr/lib/pymodules/python2.5/django/db/models/fields/related.py(831)validate() -> qs = self.rel.to._default_manager.filter(**{self.rel.field_name:value}) > /usr/lib/pymodules/python2.5/django/db/models/manager.py(141)filter() -> return self.get_query_set().filter(*args, **kwargs) (Pdb) p self.get_query_set().db 'default' }}} The !ModelFormSet was created by creating Form with a queryset: {{{ def make_projecttask_formset(p, extra=0): class _ProjectTaskForm(forms.ModelForm): project = forms.ModelChoiceField(label="Project", queryset=Project.objects.using('otherdb').filter(project_id=p.project_id)) ... return modelformset_factory(ew_projecttask, form=_ProjectTaskForm, extra=extra) }}} Expected behavior: used db should be the same as in the queryset Note: it seems the problems is known (bug not fixed): * discussed in http://groups.google.com/group/django-developers/browse_thread/thread/22e52a2fd03eac82 * someone proposed a patch at http://github.com/aparo/django/commit/edcdc1d9364224fcbc3b810b9d9fa19a10cd537c (only the fields/related part imho) rixx pollux   0 1 1 1 0 0
13841 2010-06-27 16:25:49 2014-06-06 00:04:34 2022-03-06 03:56:19.329137 Accepted assigned Template system New feature Normal dev   Allow context processors access to current version of context Allow context processors access to current version of context so that they can change values and not just override them. This can be easily done with another argument, context, and also backwards compatible. Functions would only get additional argument if they are defined to get two arguments and whatever they would return would override that in the context. copelco mitar   0 1 1 0 0 0
13910 2010-07-08 04:07:27 2019-07-18 09:25:13 2022-03-06 03:56:30.074716 Accepted assigned Template system New feature Normal dev   Add generator version of Template.render(Context) We already can make a streaming HttpResponse by passing a generator to it. This patch adds a "stream()" method to the Template class that returns a string generator that renders the template node-by-node suitable for passing to such HttpResponse. This also includes a shortcut function "stream_to_response()" -- the streaming version of render_to_response(). pglotov rooney   0 1 1 0 0 0
14035 2010-07-30 15:43:03 2021-11-26 10:28:20 2022-03-06 03:56:48.845876 Accepted assigned HTTP handling Bug Normal dev   Cannot access POST after request.encoding was set to a custom value Issue happens for multipart/form-data and WSGi handler. {{{ #Django trunk r13353. class DetectEncodingMiddleware(object): def process_request(request): # Lets say we define data encoding in POST param called "enc" enc = request.POST['enc'] # request._load_post_and_files() request.encoding = enc # request._set_encoding(): del self._post request.POST # request._load_post_and_files() # raise AttributeError("You cannot set the upload handlers after the upload has been processed."); }}} This issue is related: #12522 zimnyx zimnyx   0 0 0 0 0 0
14094 2010-08-11 13:59:39 2019-05-03 17:19:28 2022-03-06 03:56:59.156957 Accepted assigned Database layer (models, ORM) New feature Normal dev   Cannot define CharField with unlimited length Model validation throws an error on CharField with a null max_length: {{{ #!python class Test(Model): char_field = CharField(max_length=None) }}} ''' One or more models did not validate:[[BR]] test.test: "char_field": CharFields require a "max_length" attribute that is a positive integer. ''' CharField should allow max_length=None, which intuitively means there is no maximum length. This is a perfectly valid use case. Postgres, for example, supports varchar/text columns without a length limit, but Django appears to have no way to define such a column in a model class. The model validation code looks like this ([http://code.djangoproject.com/browser/django/tags/releases/1.2.1/django/core/management/validation.py#L40 django/core/management/validation.py:40]): {{{ #!python if isinstance(f, models.CharField): try: max_length = int(f.max_length) if max_length <= 0: e.add(opts, '"%s": CharFields require a "max_length" attribute that is a positive integer.' % f.name) except (ValueError, TypeError): e.add(opts, '"%s": CharFields require a "max_length" attribute that is a positive integer.' % f.name) }}} It should be changed to something this: {{{ #!python if isinstance(f, models.CharField) and f.max_length is not None: ... }}} The FileField does not happen to throw this error because it is not a derivative of CharField. However, the SQL generated for FileField is not correct when max_length=None, so that would need to be addressed as well. ar45 millerdev   0 1 1 0 0 0
14336 2010-09-23 21:24:23 2016-09-25 21:38:55 2022-03-06 03:57:37.248210 Accepted assigned contrib.admin New feature Normal 1.2   list_display should be able to contain sortable references to annotated fields Overriding the `queryset` method of a `ModelAdmin` should be an easy way to annotate the `QuerySet` used in the admin list view for a model. My use case is that I have two `IntegerField`s containing counts of various things, but what I'd like to be able to display and sort by in the admin list view is the sum of these two fields. This can best be explained by an example: {{{ #!python # Given this model class Article(models.Model): title = models.CharField(max_length=255) num_a = models.PositiveIntegerField() num_b = models.PositiveIntegerField() # Want ModelAdmin like... class ArticleAdmin(admin.ModelAdmin): list_display = ('title' 'total_nums') def queryset(self, request): qs = super(ArticleAdmin, self).queryset(request) return qs.extra(select={'total_nums':'num_a + num_b'}) }}} This fails at model validation with a `ImproperlyConfigured` exception in `django.contrib.admin.validation.validate` because the model has no 'total_nums' field, which we know. But the model validation mechanism has no access to the instance of the `ModelAdmin`, and therefore no access to the queryset to be able to check for any extras or annotations. I tried fixing this and would have submitted a patch, but I failed in the time I had. However, there is a workaround I discovered and am using, but it seems silly. You change `ArticleAdmin` to the following: {{{ #!python class ArticleAdmin(admin.ModelAdmin): list_display = ('title' 'total') def total(self, obj): return obj.total_nums total.admin_order_field = 'total_nums' def queryset(self, request): qs = super(ArticleAdmin, self).queryset(request) return qs.extra(select={'total_nums':'num_a + num_b'}) }}} This seems overly verbose and a little hacky, but it does work. I'd say that makes this ticket non-urgent, though I do wonder how many developers gave up before discovering this technique. bahoo pmclanahan   0 1 0 0 1 0
14761 2010-11-23 06:21:30 2015-05-28 15:39:30 2022-03-06 03:58:42.928679 Accepted assigned Core (URLs) New feature Normal dev   URL resolving / reversing design doesn't allow alternate specs Django's URL resolution system is currently based on regexps and is represented by the RegexURLPattern class. There are cases where it would be preferable to subclass this and allow alternate ways of specifying URL patterns that ultimately compile down to regexps. Right now, this works for URL resolving as during resolution, the resolve method on the RegexURLPattern class is called, and hence subclasses can modify that behaviour. It however, '''doesn't''' work for URL reversal, because the resolver class generates the possible matches itself, instead of calling a method on RegexURLPattern or its subclasses as is the case with URL resolution. The attached patch simply refactors urlresolvers.py so the resolver calls a method on RegexURLPattern to get possible matches. It passes all the URL tests in Django, is completely backwards-compatible and introduces no new issues or quirks. I don't believe any new tests are required, and because the new method on RegexURLPattern is marked private (hence subject to change), no new docs are required either. This should stay as an unsupported way to extend Django's URL system until it is fully revamped (support disjunctives, URI templates etc.). The relevant thread on django-developers is here - http://groups.google.com/group/django-developers/browse_thread/thread/c94b551ebd57fbe6/65d79a336fef04b2 knbk samuel337 url resolve reverse 0 0 0 0 0 0
15619 2011-03-15 20:43:07 2020-02-27 17:18:13 2022-03-06 04:00:59.946213 Accepted assigned contrib.auth Bug Normal dev   Logout link should be protected There is a logout link in admin app. It is link, not a form. Therefore it is not CSRF-protected. Probably it is not so important to protect logout from CSRF attack, because this fact cannot be used to do anything harmful. So this is just a request for purity. Another reason is that GET request should never change invernal state of the system. rfleschenberg void   0 1 0 0 1 0
15727 2011-03-31 13:16:57 2020-03-06 14:47:06 2022-03-06 04:01:16.472023 Accepted assigned HTTP handling New feature Normal dev   Add support for Content-Security-Policy (CSP) to core out of the box support for CSP would totally rock! See https://developer.mozilla.org/en/Security/CSP/Introducing_Content_Security_Policy for more information on what CSP is about. orf db.pub.mail@gmail.com   0 1 0 0 1 0
15855 2011-04-19 19:44:57 2017-07-15 11:39:14 2022-03-06 04:01:38.293417 Accepted assigned Core (Cache system) Bug Normal     cache_page decorator bypasses any Vary headers set in middleware A number of common response middlewares in Django (gzip, sessions, locale, csrf) add to the Vary header on responses, which is checked both by Django's caching system and upstream HTTP caches to determine what requests can safely be served that cached response. Getting the Vary header correct can be quite important, as failure to include it can mean upstream caches show session-private content to users who should not see it. Since view decorators run on the outgoing response first, before response middleware, the cache_page decorator caches the response before any of the mentioned response middlewares have a chance to add their Vary headers. This means two things: 1) the cache key used won't include the headers the response ought to vary on, and Django may later serve that response to users who really shouldn't get it, and 2) when that cached response is later served to a user, it still won't include the Vary header that it should have, and thus may also be cached wrongly by an upstream HTTP cache. I can't see a reasonable way of fixing this that maintains the current semantics of the cache_page decorator. The only option I've come up with is to require all users of full-response caching to always include the `UpdateCacheMiddleware` in their MIDDLEWARE_CLASSES (in its recommended spot at the top of the list, thus last in response processing), and only do the actual caching there. We'd then have to provide some way to say "don't cache pages unless they are marked" (a setting? ugh), and then the cache_page decorator would just mark the response for later caching (which would override the global don't-cache flag). renskiy carljm   0 1 0 0 1 0
16260 2011-06-15 01:40:13 2013-10-03 14:28:23 2022-03-06 04:02:43.015153 Accepted assigned contrib.admin New feature Normal dev   Ability to change dismissRelatedLookupPopup on custom callback function The best solution for some cases for customizing admin is put some links with showRelatedObjectLookupPopup javascript function on admin changelist, but after user choose the object, custom javascript function must be called instead of dismissRelatedLookupPopup javascript function. Execution of dismissRelatedLookupPopup is hard coded in python code now. The easiest way to implement use case described higher is adding new GET argument "_callback" to changelist view. alekam alekam admin javascript 0 1 1 0 0 1
16406 2011-07-04 16:51:22 2022-03-01 10:39:12 2022-03-06 04:03:08.571238 Accepted assigned Core (URLs) Cleanup/optimization Normal dev   Allow separate access to matches from urlpatterns and extra_context args Currently Django's ''!ResolverMatch'' (eg the one returned by ''urlresolvers.resolve'') gives access to ''args'' and ''kwargs'' which are ready to be passed to the ''func'' being resolved. This does eliminate the possibility of an interesting use-case: Let's assume I have a page written in english and german. I configured my urls using the new urlpatterns like this: {{{#!python urlpatterns = i18n_patterns('', url(_(r'^about/$'), 'about.view', {'some_extra': 'data'}, name='about'), url(_(r'^news/$'), 'home.view', {'some_extra': 'data'}, name='home'), ) }}} I now would like to give my visitors an easy way to access the content in german. So my ''/about'' should have a link to ''/über''. To do that, one could write a templatetag which does the following: {{{#!python match = urlresolvers.resolve('current-url') links = [] for lang in settings.LANGUAGES: translation.activate(lang): links.append(reverse(match.url_name, args=match.args, kwargs=match.kwargs)) # Further logic to display the links in the template }}} This doesn't work since the ''!ResolverMatch'' combined the ''kwargs'' captured from the url-regex with the dictionary supplied for the extra data. I think it would be a great if the ''!ResolverMatch'' would give access to ''kwargs'' and ''extra_context'' separately. There might be more usecases, but that's the only one I can come up with for now. From a quick view at the code it should be possible to do that backwards-compat (eg ''!ResolverMatch.!__getitem!__'' would still return the current result but internally it would use two dictionaries). Alokik-Roe apollo13 resolvers, reverse 1 1 0 0 0 0
16508 2011-07-24 11:36:29 2019-03-08 06:15:51 2022-03-06 04:03:24.785060 Accepted assigned Database layer (models, ORM) New feature Normal dev   Provide real support for virtual fields I have created a virtual field based on `GenericForeignKey`, but I found out that it can not be properly used for model initiation. Altered example from my test: {{{ class Managing(models.Model): shortcut = models.CharField(max_length=20) name_cs = TranslationProxyField('name', 'cs', False) class ManagingTranslation(models.Model): name = models.CharField(max_length=20) class TranslationProxyField(object): """ Descriptor that is a virtual field that provides access to translations. """ def __init__(self, field_name, language_code=None, fallback=False): self._field_name = field_name self._language_code = language_code self._fallback = fallback names = [field_name] if language_code is not None: names.append(language_code.replace('-', '_')) if fallback: names.append(FALLBACK_FIELD_SUFFIX) self.name = '_'.join(names) def contribute_to_class(self, cls, name): if self.name != name: raise ValueError('Field proxy %s is added to class under bad attribute name.' % self) self.model = cls cls._meta.add_virtual_field(self) # Connect myself as the descriptor for this field setattr(cls, name, self) # This results in Type error from Model.__init__, because of extra kwarg Managing(shortcut='name', name_cs='jméno') }}} I tried to use `pre_init` signal, but I found out that I will not get `instance` argument, so I can not use that. This way is truly usable only for virtual fields which are like `GenericForeignKey` built on real model fields of object. When it gets more complicated, it can not be used. Confusing on this path is that `instance` is in `providing_args` of `pre_init` signal. Currently I solve this by quite a hack which is deriving of `TranslationProxyField` from `property` instead of `object`. This works because of setting properties is allowed in `Model.__init__`. In my opinion, a stable solution would… auvipy vzima   0 0 0 0 0 0
16732 2011-08-30 21:49:03 2020-03-26 08:55:52 2022-03-06 04:03:59.860939 Accepted assigned Database layer (models, ORM) Bug Normal dev   Unable to have abstract model with unique_together I have such model definition: {{{ class SlugVersion(models.Model): class Meta: abstract = True unique_together = (('slug', 'version'),) slug = models.CharField(db_index=True, max_length=10, editable=False) version = models.IntegerField(db_index=True, editable=False) class Base(SlugVersion): name = models.CharField(max_length=10) class Test(Base): test = models.IntegerField() }}} And I am getting: {{{ Error: One or more models did not validate: test.test: "unique_together" refers to slug. This is not in the same model as the unique_together statement. test.test: "unique_together" refers to version. This is not in the same model as the unique_together statement. }}} I see this is as a bug. Why there could not be a table for class `Base` with unique constraints on its `slug` and `version` fields, and then 1-1 relationship with additional table for model `Test` with field `test`. cansarigol mitar   0 1 0 1 0 0
16872 2011-09-17 20:08:58 2014-06-06 00:04:05 2022-03-06 04:04:22.041518 Accepted assigned GIS New feature Normal     Add touch support to the geographic admin !OpenLayers 2.11 added support for touch events, it would be nice to be able to edit geometries inside the admin from mobile devices, e.g., the iPad and Android tablets. jbronn jbronn gis admin touch 0 1 1 0 0 0
17208 2011-11-12 09:22:11 2016-10-20 22:41:22 2022-03-06 04:05:15.782355 Accepted assigned contrib.admin Cleanup/optimization Normal dev   Dogfood class-based views in contrib.admin This is something that I believe was discussed at DjangoCon, as well as in the django-dev mailing list and on IRC. It would be good to do a) on principle, b) to make the admin views easier to extend, and c) to potentially find and correct issues in the generic class-based views. Naturally, any solution would need to be backwards-compatible. yoongkang melinath class-based views admin 0 1 0 0 1 0
17235 2011-11-15 15:41:51 2021-02-15 09:30:43 2022-03-06 04:05:19.883324 Accepted assigned HTTP handling Bug Normal dev   Multipartparser shouldn't leave request.POST/request.FILES mutable Currently the multipart parser constructs ''!QueryDicts'' for POST and FILES as mutable. Since we discourage users to change ''!QueryDicts'' (and don't allow it for GET and normal POST) the parser should change the flag to False before returning it. This way multipart POSTs would be more consistent with normal POSTs which aren't mutable. vinayinvicible apollo13   0 1 1 0 0 0
17508 2012-01-06 12:22:31 2013-07-06 09:21:06 2022-03-06 04:06:00.623385 Accepted assigned Generic views New feature Normal dev   DateDetailView should accept less specific dates, ie Year/Month or just Year DateDetailView currently expects segments for year, month and day in the URL. This introduces the requirement to have an archive page for each level of the date; ie a year archive, a month archive, and a day archive: /2012/ /2012/jan/ /2012/jan/06/ /2012/jan/06/blog-entry-name/ I don't think I'm inaccurate in saying that most bloggers (as opposed to news sites) don't usually create more than one post a day, and many (myself included) have a frequency of much less than once per month. This means we're introducing views such as day archive that have exactly the same information as the higher levels. As a URL purist, I don't like unnecessary segments in my schema and unnecessary pages in my information architecture. In my case my URL structure is as follows, I don't use DayArchive at all: /2012/ /2012/jan/ /2012/jan/blog-entry-name/ I've achieved this by creating my own version of DateDetailView that removes the use of DayMixin, but I think this can also be achieved by modifying DateDetailView itself to allow looser date matching using configuration of the view itself. Is this a common enough use case to be worth making the change in Django itself? I think it can be done without affecting backwards compatibility. moonlimb AndrewIngram   0 1 0 1 1 0
17688 2012-02-14 22:18:26 2016-10-07 09:34:49 2022-03-06 04:06:31.467303 Accepted assigned Database layer (models, ORM) Bug Normal 1.3   No m2m_changed signal sent to when referenced object is deleted {{{ class Topping(models.Model): name = models.CharField() class Pizza(models.Model): name = models.CharField() toppings = models.ManyToManyField(Topping, null=true, blank=true) }}} And this data established using those models: {{{ TOPPING id=1, name="Pepperoni" id=2, name="Onion" id=3, name="Mushroom" PIZZA id=1, name="foopizza" toppings=1,2,3 }}} 1. Deleting any Topping object (for example, deleting id=1, name="Pepperoni") also removes it from foopizza.toppings. '''GOOD''' 2. No m2m_changed signal is sent when 1 (above happens). '''BAD?''' jorgecarleitao jblaine@kickflop.net   0 1 1 0 0 0
17905 2012-03-15 13:20:41 2013-02-23 23:11:27 2022-03-06 04:07:07.515213 Accepted assigned contrib.admindocs New feature Normal 1.4-alpha-1   Admin documentation lists all models, even for users without access to certain applications By default, the admin docs lists documentation for all models. Some users may not have access to models that are still listed in their entirety. The easiest way to fix this was to check each model in the model index, and only add the model to the listing if a user has the correct permissions. I'm not sure if this is the correct way to go about this, but I'm submitting the patch for review. gszczepanczyk chriscohoat   0 1 0 1 0 0
18283 2012-05-07 17:17:13 2015-11-15 22:13:33 2022-03-06 04:08:10.718010 Accepted assigned Database layer (models, ORM) Bug Normal 1.4   FileField should not reuse FieldFiles A simple example: {{{ old_image = mymodel.image old_image.open() try: mymodel.image = do_something_with_image(old_image) finally: old_image.close() mymodel.save() # transaction manager is in auto commit mode old_image.delete() }}} '''Expected behavior:''' New file is commited to disk and database, old file is removed. '''Actual behavior:''' New file is commited to disk and database, then this new file is removed from disk. That's because FileField (or to be more precise: FileDescriptor class) is re-using FieldFile objects instead of creating new FieldFile for every new instance of a file. This leads to unexpected results and data loss (like in example). trg sayane   0 0 0 0 0 0
18468 2012-06-13 10:09:22 2021-10-12 15:40:17 2022-03-06 04:08:46.961748 Accepted assigned Database layer (models, ORM) New feature Normal dev   Add the ability to define comments in table / columns Database-level comments are valuable for database administrators, data analysts, data scientists, and others who are looking to consume data that is managed by Django. Most Django-supported databases also support table-level and column-level comments. This ticket would add functionality to Django to allow Django users to specify comments for syncdb manage.py to enter into the database. .... .... **new proposal** (kimsoungryoul : 2020.03.23) We will develop the code such as below {{{ class AModel(models.Model): aaa = model.CharField(help_text="i am help_text", db_column_comment="i am db_comment",~~~) class Meta: db_table = "a_model_example_name" db_table_comment ="this is a_model comment ~~~~" }}} jchubber mrechte   0 1 1 0 0 0
18887 2012-08-31 08:51:43 2015-11-11 11:06:57 2022-03-06 04:09:52.520149 Accepted assigned GIS Cleanup/optimization Normal 1.4   LineString array method (property) returns different data type without and with NumPy installed Apparently LineString (and probably other geometry types) return data in different types depending on whether NumPy is installed. Simple test case (reproducible in Django 1.3, 1.3.1 and 1.4.1). Clean virtual env with only Django installed (and ipython). First - no NumPy installed. {{{ In [1]: from django.contrib.gis.geos import LineString In [2]: line = LineString((0, 0), (3, 3)) In [3]: line.array Out[3]: [(0.0, 0.0), (3.0, 3.0)] }}} Now - install NumPy and try again. {{{ In [1]: from django.contrib.gis.geos import LineString In [2]: line = LineString((0, 0), (3, 3)) In [3]: line.array Out[3]: array([[ 0., 0.], [ 3., 3.]]) }}} [(0.0, 0.0), (3.0, 3.0)] =! array([[ 0., 0.],[ 3., 3.]]) This is rather serious issue. sir-sigurd mal GIS, NumPy, LineString 0 1 1 0 1 0
19221 2012-10-31 22:50:42 2020-04-16 16:59:51 2022-03-06 04:10:43.624604 Accepted assigned Core (Cache system) Bug Normal dev   Check that cache keys are string In current master cache keys can't be integers whilst they can in 1.4. Attempts to do this result in: {{{ File "/home/ismdj/src/django/django/core/cache/backends/dummy.py", line 15, in get key = self.make_key(key, version=version) File "/home/ismdj/src/django/django/core/cache/backends/base.py", line 80, in make_key new_key = self.key_func(key, self.key_prefix, version) File "/home/ismdj/src/django/django/core/cache/backends/base.py", line 26, in default_key_func return ':'.join([key_prefix, str(version), key]) TypeError: sequence item 2: expected string or Unicode, int found }}} The issue seems to have been introduced with this commit: https://github.com/django/django/commit/45baaabafb6cf911afad9ec63c86753b284f7269 etos mhsparks   0 0 0 0 0 0
19255 2012-11-06 09:24:36 2015-10-16 20:58:57 2022-03-06 04:10:49.537416 Accepted assigned contrib.contenttypes Bug Normal 1.4   BaseGenericInlineFormSet runs validation methods before linking form instances to their related object Given this model: {{{ class Model(models.Model): content_type = models.ForeignKey(ContentType) object_id = models.PositiveIntegerField() object = generic.GenericForeignKey() def clean(self): assert self.object_id assert self.object }}} and this admin: {{{ class ModelInline(generic.GenericStackedInline): model = Model }}} When saving a new `Model`, the assertion will fail. The object will not be linked, nor will the object_id be available to the clean function. This is because the fields are excluded from the formset and the values are set through the generic InlineAdmin, see this excerpt: {{{ generic.py:412 def save_new(self, form, commit=True): # Avoid a circular import. from django.contrib.contenttypes.models import ContentType kwargs = { self.ct_field.get_attname(): ContentType.objects.get_for_model(self.instance).pk, self.ct_fk_field.get_attname(): self.instance.pk, } new_obj = self.model(**kwargs) return save_instance(form, new_obj, commit=commit) }}} To hack around this issue, the forms and formsets involved should not cache the validation result. The clean function should then validate the value if it is present (the second time when cleaning). The hack is quite ugly and requires a lot of coding. It should be possible to easily validate the newly related-to foreign key object. arielpontes bouke   0 0 0 0 0 0
19755 2013-02-06 14:13:35 2019-01-09 21:39:03 2022-03-06 04:12:08.006713 Design decision needed assigned contrib.admin New feature Normal dev   Incremental filter Would be a good feature to have filter's value that change incrementally when user select one of them. I try to explain with an example: {{{ class Person(models.Model): name = models.CharField() hair_color = models.CharField() eye_color = models.CharField() class PersonAdmin(admin.ModelAdmin): list_filter = ["hair_color", "eye_color"] }}} At first I'll see all hair color and eye color values in the filter. When I select an hair color value from the filter I'll see only person with that hair color. I would view in the eye color filter only distinct values of eye colors of person that have hair color I selected from the filter. suligap paulox@paulox.net filter, admin 0 1 1 0 0 1
20313 2013-04-24 12:49:57 2020-04-13 23:04:34 2022-03-06 04:13:35.222941 Accepted assigned contrib.auth New feature Normal     AnonymousUser should follow custom User implementation Introducing custom User classes opened a few new options for handling authorization logic, e.g.: {{{ self.request.user.has_purchased(object) }}} or as @akaariai mentioned: {{{ request.user.has_role_in_org(some_org) }}} Without being able to define custom AnonymousUser class that follows User implementation this will not work. There are some ideas on how to solve that, and the ones discussed are: * defining {{{anonymous_user_class}}} on {{{UserClass}}} (@akaariai) * merging {{{User}}} and {{{AnonymousUser}}} (@apollo13) The current dirty patch uses the same approach as with {{{get_user_model()}}}: * django.contrib.auth.get_anonymous_model * django.conf.global_settings.AUTH_ANONYMOUS_MODEL and changes in: * django.contrib.auth.context_processors * django.db.models.sql.where.WhereNode thinkingpotato thinkingpotato@gmail.com   0 0 0 0 0 0
20372 2013-05-07 16:41:18 2020-04-10 15:58:53 2022-03-06 04:13:44.377682 Accepted assigned contrib.admin Cleanup/optimization Normal 1.5   using registration/logged_out.html template overrides admin logout Hi I created registration/login.html and registration/logged_out.html templates to handle my site login/logout using the provided auth views login/logout. While the admin app login using admin/login.html, it logouts using registration/logged_out.html. So, having my own registration/logged_out.html overrides that of the admin app. alexisbellido tomerz@cgen.com   0 1 1 0 1 0
20434 2013-05-18 10:40:16 2014-02-12 16:24:09 2022-03-06 04:13:55.435655 Accepted assigned Template system New feature Normal     Have a template tag grammar instead of handling token/parser for every tag, and make it possible to introspect the grammar. Right now, if people use @register.simpletag (or assignment_tag/inclusion_tag), a compiled parser function will be registered in the library.tags mapping. This however, is insufficient, if you need to do some introspection on the available template tags. I'd like to know for instance which template tags in module X are an instance of simpletag and would thus create a SimpleNode. Right now, we are unable to accurately build a real AST from the template without manually defining which templatetags behave in which way. This is also required for AST transformations, like template compression and such. I guess, it would be great to encourage people to always use @register.simpletag or anything that uses the built-in Node classes of Django. We can't force that, but it has a lot of advantages. jonathanslenders jonathanslenders   0 0 0 0 0 0
20752 2013-07-15 19:45:47 2014-06-07 20:46:02 2022-03-06 04:14:41.453550 Accepted assigned HTTP handling Bug Normal dev   Error signals are not reliable, especially when dealing with database errors In core.handlers.base, unhandled exceptions are processed as such: {{{ except: # Handle everything else, including SuspiciousOperation, etc. # Get the exception info now, in case another exception is thrown later. signals.got_request_exception.send(sender=self.__class__, request=request) response = self.handle_uncaught_exception(request, resolver, sys.exc_info()) }}} Which delivers the error signal to the various handlers (database transaction resets, things like Sentry etc). However, the code that dispatches signals aborts the dispatch if any of the handlers fail (to try..except block): {{{ for receiver in self._live_receivers(_make_id(sender)): response = receiver(signal=self, sender=sender, **named) responses.append((receiver, response)) return responses }}} This is perfectly reasonable in most cases, but is problematic when dealing with top-level error handling, as this prevents the unhandled error from reaching handlers that just want to report it. This is very noticeable in cases where "something bad" happens to the database connection, as the first handler is always the database rollback handler, which only catches DatabaseError, which excludes a lot of errors that can and do crop up in production {{{ def _rollback_on_exception(**kwargs): from django.db import transaction for conn in connections: try: transaction.rollback_unless_managed(using=conn) except DatabaseError: pass }}} I think that it will be better to have the error signal dispatcher defer except raising until after all the handlers were called (or just swallow them all). Alternatively, a different signal for error reporting is possible, but I think that's a little confusing. Thoughts? schacki tal@sookasa.com signals errors databaseError 0 1 1 1 0 0
20757 2013-07-17 17:58:09 2015-05-28 15:39:48 2022-03-06 04:14:42.238170 Accepted assigned Core (URLs) New feature Normal dev   A more Object-Oriented URLResolver Currently, the `RegexURLResolver` is populated using tuples. Because of that, code that tries to inspect the resolver will end up containg awkward indexing like this (semplified code for clarity's sake): {{{ def get_urlformat(urlname): """ Given a URL name, returns the URL as a string suitable for string.format. Example:: urlpatterns = patterns('', url(r'^extra/(?P<extra>\w+)/$', empty_view, name="named-url2"), ) >>> get_urlformat('named-url2') 'extra/%(extra)s/' """ resolver = get_resolver() return resolver.reverse_dict[urlname][0][0][0] }}} My proposal is to replace tuples with a tuple-like object whose elements can be accessed by using attribute names. That way, the above method could become: {{{ def get_urlformat(urlname): """ Given a URL name, returns the URL as a string suitable for string.format. Example:: urlpatterns = patterns('', url(r'^extra/(?P<extra>\w+)/$', empty_view, name="named-url2"), ) >>> get_urlformat('named-url2') 'extra/%(extra)s/' """ resolver = get_resolver() urlbit = resolver.reverse_dict[urlname].urlbits[0] return urlbit.format }}} I realize this is mostly aesthetic, and there could be performance implications since the URLResolver is probably the most hit codepath, so I appreciate every kind of opinion. The attached patch is still a draft, it definitely needs more extensive test coverage, but it's a start to get the idea. knbk fcurella   0 0 0 0 0 0
21076 2013-09-09 15:48:03 2020-08-12 06:43:36 2022-03-06 04:15:31.526846 Accepted assigned contrib.sessions New feature Normal dev   Offer the ability to store a hash of session IDs rather than the ID itself We should offer the ability to store a hash each session ID in the session backend rather the the ID itself. This hash should be reasonably fast, because it'll be re-computed for every request. Currently, if an attacker gains access to the session storage backend — which may easier than gaining access to the database — he can login as anyone on the site. On a related note, we're inconsistent about whether or not we sign entries in the session backends. Some do, some don't. If we're hashing session keys by default, we should probably also sign everything by default. Both of these things need an off-switch. There are a fair number of apps that rely on raw sessionids to provide cross-framework compatibility. markkorput timo   0 1 1 0 1 0
21080 2013-09-09 18:51:14 2021-05-07 08:37:28 2022-03-06 04:15:32.055935 Accepted assigned contrib.staticfiles Bug Normal dev   collectstatic post-processing fails for references inside comments "python manage.py collectstatic" is attempting to parse references inside css comments and generating errors during post-processing. I am using: `STATICFILES_STORAGE = 'django.contrib.staticfiles.storage.CachedStaticFilesStorage'` eg. The following snippet of code in test.css: {{{ .gfg-collapse-closed { /* background-image : url('arrow_close.gif'); */ } }}} produces the following error: {{{ ValueError: The file 'stylesheets/arrow_close.gif' could not be found with <django.contrib.staticfiles.storage.CachedStaticFilesStorage object at 0x1078a3910>. collectstatic }}} Ideally, collectstatic should respect CSS comments and should not attempt to parse/reference files in lines that are commented out. If the fix is too complex, a simple workaround might be to include a `--ignore-error` flag that would allow the application to continue post-processing even when it sees errors tmszi shreyas@gmail.com   0 1 1 1 0 0
21292 2013-10-19 08:13:38 2021-06-04 02:07:28 2022-03-06 04:16:03.913757 Accepted assigned Documentation New feature Normal dev   A how-to or tutorial document for using authentication views and forms is needed There's are some substantial documents in /topics/auth/, but there isn't a step-by-step tutorial or how-to. There's a need for it in the official documentation, because: * it's worthwhile getting users started on the right track, so that they don't find themselves doing it insecurely or incorrectly * there are plenty of questions on the subject on StackOverflow and elsewhere * there are numerous (often out-of-date or incomplete) weblog articles circulating on the subject Probably a how-to is more appropriate than a tutorial. Uttam-Singhh EvilDMP   0 0 0 0 0 0
21381 2013-11-03 20:58:56 2018-03-21 12:24:44 2022-03-06 04:16:19.749987 Accepted assigned contrib.redirects New feature Normal dev   Remove contrib.redirects dependency on contrib.sites Most websites aren't served on multiple domains. It'd be nice if redirects didn't depend on sites. The Redirect model would omit the ForeignKey to Site entirely when the sites framework isn't installed. Redirections would use a RequestSite instead of a Site. At first sight it looks like this can be achieved without breaking backwards-compatibility, as we're lifting a constraint. Users will have to generate a migration to add / remove the ForeignKey if the enable / disable sites while redirects in installed. dspechnikov aaugustin   0 1 1 1 0 0
21429 2013-11-13 02:33:48 2021-03-02 20:08:43 2022-03-06 04:16:28.125291 Accepted assigned Core (Management commands) New feature Normal dev   BaseCommand should use logging instead of custom output wrappers Since python offers the powerful logging class, django.core.management.base.BaseCommand should use it to output messages instead of using custom output wrappers (django.core.management.base.OutputWrapper). Doing so, we could override those loggers in the settings.py file. Instead of having two wrappers in a command and having to do: {{{ class Command(BaseCommand): def handle(self): self.stdout.write('this is an info message') self.stderr.write('this is an error message') }}} We could do {{{ class Command(BaseCommand): def handle(self): self.output.info('this is an info message') self.output.error('this is an error message') # and even self.output.warning('this is a warning message') }}} The style_func and ending arguments that the django.core.management.base.OutputWrapper.write method takes could be removed and be configured at once in a overriding custom logger. francoisfreitag Nical command output logger 0 1 1 0 0 0
21461 2013-11-18 19:38:53 2021-06-01 21:41:45 2022-03-06 04:16:33.394997 Accepted assigned Database layer (models, ORM) New feature Normal dev   Add pre_update and post_update signals Quoting Anssi from the ML post https://groups.google.com/forum/#!msg/django-developers/tCzFMpBm5-c/XLHFY0awVJ8J: The idea is that pre_update listeners get a queryset that isn't executed. Accessing that queryset might be costly, but if it isn't accessed, there isn't much cost of adding a pre_update signals. For post_update the signal handler would be given a list of PK values (the original queryset doesn't work for post_update, the update might cause different instances to be returned than was updated, consider qs.filter(deleted=False).update(deleted=True)) This feature will also provide an upgrade path for #21169 (for FK RelatedManager.remove() more specifically). loic84 loic84   0 1 1 0 0 0
21739 2014-01-06 22:23:28 2014-06-25 20:26:14 2022-03-06 04:17:17.008329 Accepted assigned Testing framework Bug Normal 1.6   When running tests fixture error output isn't visible Hi, On django 1.6, I'm running the command: python manage.py test -v 2 One of my tests has a fixture and it seems that there is an issue with that, because no data is loaded and it's failing silently. I was looking at the code of /django/test/testcase.py and I found this: {{{ call_command('loaddata', *self.fixtures, **{'verbosity': 0, 'database': db_name, 'skip_validation': True}) }}} So, verbosity is 0, hardcoded. Shouldn't inherit the verbosity from the test command in manage.py somehow? Olek camilo.lopez.a@gmail.com test fixture verbosity 0 1 1 0 0 0
21961 2014-02-06 07:43:39 2022-02-02 21:58:30 2022-03-06 04:17:51.370358 Accepted assigned Database layer (models, ORM) New feature Normal dev   Add support for database-level cascading options Per a discussion on -developers, this ticket is to document this proposed new feature. The general idea is to allow developers to specify that the database itself, rather than Django, should implement foreign key constraints where possible. The database can be considerably more efficient, and often can avoid locking situations, in a way that the Django backend can't. The proposal is to add a models.CASCADE_DB, models.SET_NULL_DB, models.PROTECT_DB constants. These specify that the appropriate functionality is to be implemented in the database if the database supports it; otherwise, they are implemented in the Django core as now. Some potential design issues with proposed solutions: 1. It is not an error to specify the _DB version with a database that doesn't support it. Instead, you get the non-_DB version. 2. The _DB version does not fire signals; this will need to be documented. 3. If a model A references a model B using CASCADE_DB, but model B references model C using regular CASCADE, a deletion of A won't cascade all the way to C. This needs to be documented. Another possibility is to make this an error condition and have model validation fail, but that seems excessive. 4. The _DB version is disallowed on generic foreign keys, because that way madness lies. 5. The implicit foreign key created from child to parent in model inheritance is never the _DB version. This is a shame, but there are two issues: a) Since it's created implicitly, there's no place to put it. b) Even if we extended the mechanism to allow manual specification of the key, deleting the parent wouldn't automatically delete the child. tvallois Xof   0 1 1 0 0 0
21963 2014-02-06 09:34:43 2018-02-26 15:43:21 2022-03-06 04:17:51.693139 Accepted assigned Internationalization Bug Normal 1.6   makemessages still ignores translations in templates with inline comment tags This bug is claimed to be fixed in #19552, though it's not. Here's the test case: Template: {{{#!django {% load i18n %} {# Translators: Abbreviated month name #} {% trans "Jan" %} {# Translators: Abbreviated month name #}{% trans "Feb" %} {% comment %}Translators: Abbreviated month name{% endcomment %}{% trans "Mar" %} {# Translators: Abbreviated month name #} {% trans "Apr" %} {% comment %}Translators: Abbreviated month name{% endcomment %} {% trans "May" %} {# Translators: Abbreviated month name #} {% trans "Jun" %} {# Translators: Abbreviated month name #} {% trans "Jul" %} {% comment %}Translators: Abbreviated month name{% endcomment %} {% trans "Aug" %} }}} The extraction session: {{{ $ ./manage.py version 1.6.1 $ ./manage.py makemessages -l ru -i venv .../trans_real.py:585: TranslatorCommentWarning: The translator-targeted comment 'Translators: Abbreviated month name' (file app1/templates/i18n_test.html, line 6) was ignored, because it wasn't the last item on the line. warnings.warn(warn_msg, TranslatorCommentWarning) .../trans_real.py:585: TranslatorCommentWarning: The translator-targeted comment 'Translators: Abbreviated month name' (file app1/templates/i18n_test.html, line 10) was ignored, because it wasn't the last item on the line. warnings.warn(warn_msg, TranslatorCommentWarning) processing locale ru }}} Resulting po file: {{{#!po #. Translators: Abbreviated month name #: app1/templates/i18n_test.html:4 msgid "Jan" msgstr "" #: app1/templates/i18n_test.html:6 msgid "Feb" msgstr "" #. Translators: Abbreviated month name gettext(u'Mar') #: app1/templates/i18n_test.html:10 msgid "Apr" msgstr "" #. Translators: Abbreviated month name gettext(u'May') #. Translators: Abbreviated month name #: app1/templates/i18n_test.html:15 msgid "Jun" msgstr "" #. Translators: Abbreviated month name #: app1/templates/i18n_test.html:19 msgid "Jul" msgstr "" #. Translators: Abbreviated month name #: app1/templates/i… sergeykolosov Ihor Kaharlichenko <madkinder@gmail.com> makemessages, template, gettext, xgettext 0 1 1 0 0 0
21978 2014-02-07 20:46:15 2018-08-09 23:50:51 2022-03-06 04:17:53.760821 Accepted assigned Core (Management commands) New feature Normal dev   Add optional gunicorn support to runserver gunicorn has added a [https://github.com/benoitc/gunicorn/pull/682 --reload option for code reloading] which should lower the barrier of entry to removing our own HTTP server functionality. Simply deprecating and removing the `runserver` management command entirely may not be desirable. As Loic noted on IRC "even if we use gunicorn, we still need some special handling for the dev server, we run validate() and now there are some migrations checks going as well. So would we really deprecate runserver? rather than just change the underlying webserver it wraps?" Michael Manfre also expressed concern the gunicorn does not currently work on Windows. Aymeric suggested: "optional support for gunicorn could be an interesting start." berkerpeksag timo   0 1 1 0 0 0
21987 2014-02-08 18:27:37 2014-05-04 15:13:28 2022-03-06 04:17:55.109844 Accepted assigned Forms Cleanup/optimization Normal dev   Allow Media objects to have their own MEDIA_TYPES Currently, [https://github.com/django/django/blob/a2814846ca006b4fbf3a893ec52cd9d444b3a3eb/django/forms/widgets.py#L35 instances of Media] look to the module scope to get the known [https://github.com/django/django/blob/a2814846ca006b4fbf3a893ec52cd9d444b3a3eb/django/forms/widgets.py#L31 MEDIA_TYPES]. This makes it difficult to subclass `Media` to add extra `render_x`/`add_x` methods because `MEDIA_TYPES` is hardcoded in [https://github.com/django/django/blob/a2814846ca006b4fbf3a893ec52cd9d444b3a3eb/django/forms/widgets.py#L45 __init__], [https://github.com/django/django/blob/a2814846ca006b4fbf3a893ec52cd9d444b3a3eb/django/forms/widgets.py#L56 render], [https://github.com/django/django/blob/a2814846ca006b4fbf3a893ec52cd9d444b3a3eb/django/forms/widgets.py#L83 __getitem__] and [https://github.com/django/django/blob/a2814846ca006b4fbf3a893ec52cd9d444b3a3eb/django/forms/widgets.py#L102 __add__] and isn't easily available for a subclass to add to without monkeypatching the module constant. As far as I can tell, the only use of `MEDIA_TYPES` is in the widgets module, and could be shifted to the class itself, leaving the module level one to raise a deprecation warning. Rationale is that I want to be able to add `inline_css` and `inline_js`, or `text` (for JS templates etc) to a `Media` object, and currently that's more difficult than just adjusting a subclass' attribute and adding the appropriate methods. Osmose Keryn Knight <django@kerynknight.com>   0 1 1 0 0 0
22078 2014-02-17 15:35:17 2017-03-17 14:48:23 2022-03-06 04:18:08.401314 Accepted assigned contrib.syndication Bug Normal 1.6   views.Feed methods cannot be decorated If one applies a decorator on a method which is called by `__get_dynamic_attr` a `TypeError` like this occurs: {{{ Exception Type: TypeError at /blog/feed/ Exception Value: item_link() takes exactly 2 arguments (1 given) }}} I think this is because `__get_dynamic_attr` tries to count the function's arguments, but decorators usally get defined with the `*args, **kwargs` syntax, so this trick does not work here. {{{ if code.co_argcount == 2: # one argument is 'self' return attr(obj) else: return attr() }}} I think the best approach would be to remove one of the two methods. IMHO We should have either `attr(item)` or `attr()` not both, as "there should be one, and preferably only one, obvious way to do it". coldmind tyrion   0 0 0 0 0 0
22425 2014-04-12 15:57:15 2021-06-29 15:19:38 2022-03-06 04:18:58.703687 Accepted assigned Core (URLs) New feature Normal dev   provide ability to abort URL resolution early This is a feature request to provide a way to abort early from URL resolution if a regex doesn't match. I was able to figure out a way to do this myself using some wrapper constructs, but it seemed unnecessarily tricky and also relied on Django internals (and so may be brittle). To illustrate the use case, consider a typical URLconf: {{{ urlpatterns = patterns('', url(r'^articles/', include(article_urls)), url(r'^blogs/', include(blog_urls)), ... ) }}} While the above is common, it also seems common that one would want URL resolution to result in a 404 if an URL matches `^articles/` but does not match the first `url()` pattern above. This would be the case, for example, when all `article` URLs should be in the `article_urls` URLconf. However, Django would process such an URL by unnecessarily continuing to examine every pattern in `urlpatterns` that follows (`^blogs/`, etc). It would be good to have a way to achieve this 404 functionality in a performant and DRY way. For example, the following would not be as performant or DRY as it could be because you have to duplicate the regex and because Django's URL resolver would unnecessarily need to match against `^articles/` twice: {{{ urlpatterns = patterns('', url(r'^articles/', include(article_urls)), url(r'^articles/', page_not_found), url(r'^blogs/', include(blog_urls)), ... ) }}} Modifying `account_urls` and `public_urls` etc by including `page_not_found` is also not a good solution because it is not DRY (the `page_not_found` addition needs to be repeated) and because those URLs might be in third-party libraries. Tijani-Dia cjerdonek   0 0 0 0 0 0
22449 2014-04-15 22:21:31 2018-03-06 08:57:52 2022-03-06 04:19:02.219457 Someday/Maybe assigned Testing framework New feature Normal dev   Colorize output of test results Colorized test result output will improve readability dizballanze jrothenbuhler   0 1 1 0 0 0
22479 2014-04-21 03:17:11 2017-05-11 20:30:07 2022-03-06 04:19:07.072007 Accepted assigned HTTP handling New feature Normal dev   Support byte range requests in django.views.static.serve As supported by this google groups discussions: https://groups.google.com/d/msg/django-developers/NZ1qTkZ6vok/fhdz7rTtL1EJ slurms slurms   0 1 1 1 1 0
22492 2014-04-22 23:48:47 2021-10-26 14:08:41 2022-03-06 04:19:09.069238 Accepted assigned Database layer (models, ORM) New feature Normal dev   provide a way to prevent database queries on model objects This is a feature request to provide a way to prevent database queries from happening in a block of code, especially on model objects (e.g. using a context manager, or an internal flag on model objects). The motivation is for use with the QuerySet method [https://docs.djangoproject.com/en/dev/ref/models/querysets/#only `only()`], for example. (The `only()` method is used to prevent unnecessary fields from being loaded from a database when querying.) Consider the case of using `only()` to retrieve a list of many model objects, and then subsequently displaying them. If one executes some Django code after obtaining this list (e.g. by looping through the list of objects), it would be bad if this later code accidentally accessed some other field on each object. This could trigger the unintentional execution of many individual database queries (e.g. on a production database), with potentially bad consequences. I don't currently know an easy way to prevent this. It would be good to have such a way. For example, Django could provide some sort of `noQuery()` context manager which would raise an exception if the database were queried inside it. Code after the `only()` line could be included in such a context manager. This could prevent accidentally hammering a database. Alternatively, the QuerySet API could expose a way to return objects with some sort of `no_query` flag set. If attribute access on such a model object required a database query, objects with such a flag set could instead raise an exception. This would also suffice to prevent accidental queries. raulcd cjerdonek model,queryset,defer,only 0 0 0 0 0 0
22633 2014-05-16 09:26:07 2014-05-17 12:36:14 2022-03-06 04:19:35.328989 Accepted assigned Internationalization New feature Normal dev   LANGUAGE_CODE should be automatically set based on system locale Many other frameworks (like Wordpress) make a good job of using the user's language when you set them up. In many countries, for example some european countries where people are generally not english speaking, this is a really important first impression. I propose that the settings.py should set LANGUAGE_CODE to the user's locale, if: 1) We find a locale on the system 2) The locale is matched by the list of locales supported by django If not, we can fall back to the normal en-us. In addition (but this is more like a bonus thing), since USE_TZ is always set to True by default, I think it would be cool to set the TIME_ZONE variable to the user's time zone, but this might be better spun off as another ticket. hakanw hakanw   0 1 1 0 0 0
22752 2014-06-02 20:00:36 2021-01-19 02:27:01 2022-03-06 04:20:10.458304 Accepted assigned contrib.auth Cleanup/optimization Normal dev   Allow PasswordResetForm email to render URLs based on the current namespace I have multiple namespace instances for password reset urls. The email template rendered by the default PasswordResetForm does not included a `current_app` context. It's an easy fix, though, ass the PasswordResetForm already has `self.current_app`. Just need to wrap the context instance passed to the email template: {{{ #!diff diff --git a/django/contrib/auth/forms.py b/django/contrib/auth/forms.py index 6e07d45..baef873 100644 --- a/django/contrib/auth/forms.py +++ b/django/contrib/auth/forms.py @@ -4,7 +4,7 @@ from collections import OrderedDict from django import forms from django.forms.utils import flatatt -from django.template import loader +from django.template import loader, Context from django.utils.encoding import force_bytes from django.utils.html import format_html, format_html_join from django.utils.http import urlsafe_base64_encode @@ -264,10 +264,13 @@ class PasswordResetForm(forms.Form): 'token': token_generator.make_token(user), 'protocol': 'https' if use_https else 'http', } - subject = loader.render_to_string(subject_template_name, c) + context_instance = Context(current_app=self.current_app) + subject = loader.render_to_string( + subject_template_name, c, context_instance) # Email subject *must not* contain newlines subject = ''.join(subject.splitlines()) - email = loader.render_to_string(email_template_name, c) + email = loader.render_to_string( + email_template_name, c, context_instance) if html_email_template_name: html_email = loader.render_to_string(html_email_template_name, c) ~ }}} hramezani bendavis78   0 0 0 0 0 0
22757 2014-06-03 23:00:26 2017-07-10 21:58:11 2022-03-06 04:20:15.263455 Accepted assigned Database layer (models, ORM) Cleanup/optimization Normal dev   prefetch_related isn't as effecient as it could be with GenericForeignKey and proxy models `prefetch_related` is able to prefetch across a GenericForiegnKey. However, it does more queries than necessary when using proxy models. Our models: {{{#!python from django.db import models from django.contrib.contenttypes.generic import GenericForeignKey from django.contrib.contenttypes.models import ContentType class Parent(models.Model): content_type = models.ForeignKey(ContentType) object_id = models.PositiveIntegerField() child = GenericForeignKey('content_type', 'object_id', for_concrete_model=False) class Child(models.Model): pass class ProxiedChild(Child): class Meta: proxy = True }}} Now create some instances {{{ >>> child = Child.objects.create() >>> proxied_child = ProxiedChild.objects.create() >>> p1 = Parent.objects.create(child=child) >>> p2 = Parent.objects.create(child=proxied_child) }}} And query using prefetch_related: {{{ >>> Parent.objects.all().prefetch_related('child') SELECT "foo_parent"."id", "foo_parent"."content_type_id", "foo_parent"."object_id" FROM "foo_parent" LIMIT 21 SELECT "foo_child"."id" FROM "foo_child" WHERE "foo_child"."id" IN (3) SELECT "foo_child"."id" FROM "foo_child" WHERE "foo_child"."id" IN (2) }}} This is doing 3 queries instead of the expected 2. The two queries for the `foo_child` table should be combined to be `"foo_child"."id" IN (2, 3)` czpython gwahl@fusionbox.com prefetch_related 0 0 0 0 0 0
23051 2014-07-17 10:12:10 2020-01-15 09:24:23 2022-03-06 04:21:44.039624 Accepted assigned Database layer (models, ORM) Bug Normal dev   QuerySet.only() fail to work with reverse o2o relationships Specifying a field from reverse relationship model in the .only() queryset method have no effect on compiled query: {{{ # sample models class Person(models.Model): name = models.CharField(max_length=64) class PersonExtra(models.Model): bio = models.TextField() information = models.TextField() person = models.OneToOneField(Person) # manage.py shell >>> from testapp.models import Person >>> print Person.objects.all().only('name').query SELECT "testapp_person"."id", "testapp_person"."name" FROM "testapp_person" >>> print Person.objects.all().select_related('personextra').only('name', 'personextra__bio').query # expected table join and personextra__bio to be loaded SELECT "testapp_person"."id", "testapp_person"."name" FROM "testapp_person" }}} defer() method works fine: {{{ >>> print Person.objects.all().select_related('personextra').defer('personextra__information').query SELECT "testapp_person"."id", "testapp_person"."name", "testapp_personextra"."id", "testapp_personextra"."bio", "testapp_personextra"."person_id" FROM "testapp_person" LEFT OUTER JOIN "testapp_personextra" ON ( "testapp_person"."id" = "testapp_personextra"."person_id" ) }}} czpython vvd orm only reverse relationship OneToOneField 0 1 1 0 0 0
23268 2014-08-11 07:13:13 2019-04-13 12:26:36 2022-03-06 04:22:39.834652 Accepted assigned Core (Serialization) Bug Normal 1.6   Fixtures: Natural Key support for Generic Foreign Keys Currently, the natural key support is incomplete when it comes to generic foreign keys (I say bug, you may think feature). One cannot remove PKs from any object that has a generic foreign key reference limiting the whole idea of having natural keys to direct foreign keys only. Since generic foreign keys can inherently have an entry with any model, PKs have to be dumped for all models necessitating the maintenance of updated PKs There is a great answer by someone who has done the leg work for figuring out what is required. http://stackoverflow.com/questions/11159377/is-it-possible-to-use-a-natural-key-for-a-genericforeignkey-in-django Creating a ticket to document it here and see what the interest is for the same. gtnx eskhool natural generic fixtures 0 1 1 0 0 0
23318 2014-08-19 15:51:31 2020-10-28 09:14:30 2022-03-06 04:22:49.948662 Accepted assigned Core (Management commands) New feature Normal dev   Management command dbshell does not use DATABASE[...]['OPTIONS'] to set env PGOPTIONS I am trying to make use of a different "search_path" by use of {{{settings.DATABASE[...]['OPTIONS'] = '-c search_path=my_other_schema,public'}}} -- however, since they are not passed, {{{python manage.py dbshell --database=MY_OTHER_DATABASE_CONNECTION}}} will yield an unexpected result. The problem is that the shell env variable PGOPTIONS="-c search_path=MY_SEARCH_PATH_CONF" is not set. I am using it for the purpose of having multiple south_migrationhistory tables, one for every database connection. They should have been populated by: {{{ python manage.py sqlall south | python manage.py dbshell --database=DBNAME }}} Current work-around: {{{ python manage.py sqlall south | PGOPTIONS="-c search_path=NAME_OF_MY_SCHEMA" python manage.py dbshell --database=DBNAME }}} I am not sure how 1.7 will handle migration histories when populating different database connections and auto-selecting them using routers. But at least having the above to work would be nice, because it makes it easy to manually pipe around the SQL statements to different DB connections. Also in more severe cases, not having the connection options passed to dbshell might yield other unexpected results!? This might be of interest to other db backends, but please limit the issue here to only postgres, as it's perfectly simple to copy in the contents of OPTIONS to the env variable PGOPTIONS. dulmandakh benjaoming   0 1 1 0 1 0
23356 2014-08-23 22:59:44 2021-08-25 11:55:18 2022-03-06 04:22:56.493662 Accepted assigned Template system Cleanup/optimization Normal dev   Unable to create template tag which behaves similar to {% verbatim %} Currently it is impossible to create custom template tags which behave similar to {{{ {% verbatim %} }}}. The reason is in {{{Lexer.create_token()}}}. There, the class member {{{self.verbatim}}} is set for template blocks in "verbatim" state. It is impossible to turn on that state from outside, ie. a template tag. Fixing this, would be as simple as changing {{{if block_content[:9] in ('verbatim', 'verbatim ')}}} to {{{if block_content.startswith('verbatim')}}} or to {{{if block_content[:9] in ('verbatim', 'verbatim ', 'verbatim_')}}}. Then all template tags beginning with verbatim..., would start in "verbatim" state. I don't assume this will break any existing code; who starts the name of a templatetag with 'verbatim...' if not for that purpose? Background information why this is useful: Templates syntax for Django and AngularJS is very similar, and with some caveats it is possible to reuse a Django template for rendering in AngularJS. I therefore attempted to add a context sensitive variation of the verbatim tag to this app https://github.com/jrief/django-angular, but was hindered by this issue. BTW: This part of the Django code did not change from 1.6 up to master. atul-bhouraskar jrief verbatim 0 1 1 0 0 0
23424 2014-09-05 12:36:47 2021-09-01 06:15:26 2022-03-06 04:23:19.926370 Accepted assigned Template system Bug Normal dev   Verbatim tag fails to render curly braces The {% verbatim %} tag fails to render curly braces under certain conditions - notably when there are two verbatim tags on the same line. This works: {{{ {% verbatim %}{{{% endverbatim %} – correctly renders as – {{ {% verbatim %}}}{% endverbatim %} – correctly renders as – }} {% verbatim %}{ {% endverbatim %}text{% verbatim %} }{% endverbatim %} – correctly renders as – { text } }}} However, this fails: {{{ {% verbatim %}{{% endverbatim %}text{% verbatim %}}{% endverbatim %} – incorrectly renders as – {{% endverbatim %}text{% verbatim %}} {% verbatim %}{{{% endverbatim %}text{% verbatim %}}}{% endverbatim %} – incorrectly renders as – {{{% endverbatim %}text{% verbatim %}}} {% verbatim %}{{ {% endverbatim %}text{% verbatim %} }}{% endverbatim %} – incorrectly renders as – {{ {% endverbatim %}text{% verbatim %} }} }}} atul-bhouraskar stephband verbatim template tag 0 1 1 0 0 0
23521 2014-09-18 19:17:10 2021-01-19 06:28:36 2022-03-06 04:24:15.849667 Accepted assigned Migrations Bug Normal dev   removal of concrete Model from bases doesn't remove it from ModelState bases Steps to reproduce: * add `test` app with `models.py`: {{{ class Thing(models.Model): pass class SuperThing(Thing): pass }}} * do {{{ manage.py makemigrations test }}} * change `models.py` (remove `Thing`): {{{ class SuperThing(models.Model): thing_ptr = models.AutoField(primary_key=True) }}} * do {{{ manage.py makemigrations test }}} * do it one more time {{{ manage.py makemigrations test }}} last command results in {{{ django.db.migrations.state.InvalidBasesError: Cannot resolve bases for [<ModelState: 'test.SuperThing'>] This can happen if you are inheriting models from an app with migrations (e.g. contrib.auth) in an app with no migrations; see https://docs.djangoproject.com/en/1.7/topics/migrations/#dependencies for more }}} Zorking sir-sigurd   0 1 0 1 0 0
23595 2014-10-03 20:29:21 2014-12-28 00:13:35 2022-03-06 04:24:28.809048 Accepted assigned contrib.admin Cleanup/optimization Normal dev   “add” button for related fields in admin interface should send 'limit_choices_to' parameter to add form I think it's self-explanatory. When the related field has a 'limit_choices_to' parameter, the new object added to the related class should have that field pre-defined with the 'limit_choices_to' value. gchp macarena   0 0 0 0 0 1
23718 2014-10-27 20:02:30 2021-11-19 07:33:01 2022-03-06 04:24:47.549469 Accepted assigned Documentation Bug Normal 1.7   TEST_MIRROR setting doesn't work as expected (and has no tests) TEST_MIRROR promises "connection to slave will be redirected to point at default. As a result, writes to default will appear on slave" I've set up a minimum django project (using postgres backed) to demonstrate behavior. {{{ def test_fixture(self): MyModel.objects.using('default').create(name=1) MyModel.objects.using('slave').create(name=2) MyModel.objects.using('slave').create(name=3) self.assertEqual(list(map(repr, MyModel.objects.using('default').all())), list(map(repr, MyModel.objects.using('slave').all()))) }}} Both lists should be equal, because replica queries should be hitting default instead. It appears not to be the case for Django>=1.4 up to latest 1.7.1 (but actually passes against 1.3.7) {{{ AssertionError: Lists differ: ['<MyModel: 1>', '<MyModel: 2>... != ['<MyModel: 2>', '<MyModel: 3>... First differing element 0: <MyModel: 1> <MyModel: 2> First list contains 1 additional elements. First extra element 2: <MyModel: 3> - ['<MyModel: 1>', '<MyModel: 2>', '<MyModel: 3>'] ? ^ ---------------- + ['<MyModel: 2>', '<MyModel: 3>'] ? ^ }}} Here is a project I used to test: https://github.com/coagulant/test_mirror christianbundy coagulant replica testing 0 1 1 0 0 0
23764 2014-11-05 18:36:36 2015-03-22 12:24:48 2022-03-06 04:25:01.154305 Accepted assigned contrib.sessions Cleanup/optimization Normal 1.7   sessions.backends.cache.SessionStore does not respect settings.SESSION_SERIALIZER According to [https://docs.djangoproject.com/en/1.6/topics/http/sessions/#session-serialization Session serialization docs], `SESSION_SERIALIZER` setting, introduced in 1.5.3, allows to customize how session data is stored. `JSONSerializer` is used as default since 1.6. All session backends honor this setting, except for `sessions.backends.cache.SessionStore`, which still uses pickle as serialization format (not directly, but via cache backend). It should be documented that cache store ignores this setting or SessionStore should be modified to support it. r4vi coagulant pickle json sessions 0 1 0 0 1 0
23843 2014-11-15 20:25:50 2015-08-14 17:48:39 2022-03-06 04:25:18.609487 Accepted assigned Database layer (models, ORM) Bug Normal dev   Test failures on Oracle/Python3 On CI, as well as on my system: {{{ ERROR: test_custom_functions (annotations.tests.NonAggregateAnnotationTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/django/django/django/db/backends/utils.py", line 65, in execute return self.cursor.execute(sql, params) File "/home/django/django/django/db/backends/oracle/base.py", line 916, in execute return self.cursor.execute(query, self._param_generator(params)) cx_Oracle.DatabaseError: ORA-12704: character set mismatch The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/home/django/django/tests/annotations/tests.py", line 254, in test_custom_functions lambda c: (c.name, c.tagline) File "/home/django/django/django/test/testcases.py", line 869, in assertQuerysetEqual items = six.moves.map(transform, qs) File "/home/django/django/django/db/models/query.py", line 161, in __iter__ self._fetch_all() File "/home/django/django/django/db/models/query.py", line 989, in _fetch_all self._result_cache = list(self.iterator()) File "/home/django/django/django/db/models/query.py", line 289, in iterator for row in compiler.results_iter(): File "/home/django/django/django/db/models/sql/compiler.py", line 720, in results_iter for rows in self.execute_sql(MULTI): File "/home/django/django/django/db/models/sql/compiler.py", line 817, in execute_sql cursor.execute(sql, params) File "/home/django/django/django/db/backends/utils.py", line 65, in execute return self.cursor.execute(sql, params) File "/home/django/django/django/db/utils.py", line 95, in __exit__ six.reraise(dj_exc_type, dj_exc_value, traceback) File "/home/django/django/django/utils/six.py", line 624, in reraise raise value.with_traceback(tb) File "/home/django/django/django/db/backends/utils.py", line 65, in execute return self.cursor.execute(sql, params) File "/home/django/… shaib shaib   0 0 0 0 0 0
24018 2014-12-18 01:19:24 2021-09-02 07:05:34 2022-03-06 04:26:07.538596 Accepted assigned Database layer (models, ORM) New feature Normal dev   Support journal_mode=WAL for sqlite SQLite, as of 3.7, supports a WAL journal mode [https://www.sqlite.org/wal.html] It's been my experience that enabling this can dramatically improve performance, especially under heavy writes. I've seen some write-heavy operations go from a couple of minutes to a few seconds. It can be enabled by executing the command: PRAGMA journal_mode=wal; which will return 'wal' on success. If it fails to apply for any reason, it will return the mode it is in - 'delete' or 'memory'. I propose to add JOURNAL_MODE as an option to the sqlite backend. however, some quick tinkering shows that the sqlite backend doesn't ever explicitly create the DB, so it's not immediately apparent how to detect if/when this command should be issued. I am still investigating. linville funkybob   0 1 1 0 1 0
24529 2015-03-24 11:52:13 2021-07-25 02:58:16 2022-03-06 04:27:54.505730 Accepted assigned Migrations New feature Normal dev   Allow double squashing of migrations While #23090 added a safeguard to prevent `squashmigrations` from blowing up when squashing an already squashed migration, this should be possible in the future to ease transition for 3rd party projects. It is generally possible to add a squashed migration as a dependency together with its replaced migrations (e.g. have `0001_initial`, `0002_second` and `0001_squashed_0002_second` in the dependency list). An example can be found here: https://github.com/MarkusH/django-ticket-triage/tree/0aac03c597c744909db60772b99c34c99ed7111d/app_a/migrations The tasks I identified so far are for now: 1. Remove the safeguard 2. When squashing `0001_0002` and `0003`, the squashed migration `0001_0003` doesn't consider the already squashed migration operations and doesn't add them to it's operations list 3. Add squashed migrations to the dependency list rtpg MarkusH   0 1 1 1 1 0
24662 2015-04-19 01:48:47 2015-04-20 06:40:49 2022-03-06 04:28:53.932664 Accepted assigned Database layer (models, ORM) Bug Normal 1.8   Sum() returns True/False when used with BooleanField & MySQL When using Sum() on a BooleanField when only 1 record is present, the ORM returns True/False rather than 1/0. I've tested with MySQL and SQLite, only MySQL exhibits the bug. This is a change in behavior from previous versions of Django where a Decimal would be returned. Environment: MySQL - 5.6.24 MySQL-python==1.2.5 Code to reproduce (new project / app): {{{ class Example(models.Model): foo = models.BooleanField(default=True) }}} Simple query to demonstrate the difference: {{{ # add a single row a = Example() a.save() # query Example.objects.all().aggregate(count=Count('foo'), sum=Sum('foo')) # results # notice Django 1.8 + MySQL Django 1.7.7 + MySQL {'count': 1, 'sum': Decimal('1')} Django 1.7.7 + SQLite {'count': 1, 'sum': 1} Django 1.8 + MySQL {'count': 1, 'sum': True} Django 1.8 + SQLite {'count': 1, 'sum': 1} # add a second row a = Example() a.save() # query Example.objects.all().aggregate(count=Count('foo'), sum=Sum('foo')) # results # notice Django 1.8 + MySQL now returns a decimal Django 1.7.7 + MySQL {'count': 2, 'sum': Decimal('2')} Django 1.7.7 + SQLite {'count': 2, 'sum': 2} Django 1.8 + MySQL {'count': 2, 'sum': Decimal('2')} Django 1.8 + SQLite {'count': 2, 'sum': 2} }}} marco-santamaria chriskief   0 0 0 0 0 0
25068 2015-07-06 09:41:06 2021-01-19 06:19:54 2022-03-06 04:40:09.722846 Accepted assigned Migrations Bug Normal dev   Metaclass conflict when doing createmigrations in ModelState.render I'm migrating my project from Django 1.6.x to 1.8.2, I found this bug and fix for it. In my project I'm using few ModelMixins with custom {{{__metadata__}}}, problem is that render is trying do a class using {{{type}}} but this code forgot about python class metadata multi inheritance. Traceback looks like this, for each model with more complex metadata: {{{ $ /manage.py makemigrations (...) Traceback (most recent call last): File "/home/vagrant/***/manage.py", line 10, in <module> execute_from_command_line(sys.argv) File "/home/vagrant/env/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line utility.execute() File "/home/vagrant/env/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 330, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/home/vagrant/env/local/lib/python2.7/site-packages/django/core/management/base.py", line 390, in run_from_argv self.execute(*args, **cmd_options) File "/home/vagrant/env/local/lib/python2.7/site-packages/django/core/management/base.py", line 441, in execute output = self.handle(*args, **options) File "/home/vagrant/env/local/lib/python2.7/site-packages/django/core/management/commands/makemigrations.py", line 125, in handle migration_name=self.migration_name, File "/home/vagrant/env/local/lib/python2.7/site-packages/django/db/migrations/autodetector.py", line 43, in changes changes = self._detect_changes(convert_apps, graph) File "/home/vagrant/env/local/lib/python2.7/site-packages/django/db/migrations/autodetector.py", line 110, in _detect_changes self.old_apps = self.from_state.concrete_apps File "/home/vagrant/env/local/lib/python2.7/site-packages/django/db/migrations/state.py", line 170, in concrete_apps self.apps = StateApps(self.real_apps, self.models, ignore_swappable=True) File "/home/vagrant/env/local/lib/python2.7/site-packages/django/db/migrations/state.py", line 232, in __init__ … ethanhowell kosz85 metaclass conflict createmigrations 0 1 1 1 0 0
25139 2015-07-17 20:31:53 2020-08-24 09:13:05 2022-03-06 04:40:20.895775 Someday/Maybe assigned Forms New feature Normal dev   ModelFormSet: allow swapping unique values As a user, I would expect to be able to swap ''unique'' values in an HTML form backed by a ModelFormSet. Turns out, this is not the case. The user must do a two step process of first setting the values to temporary value, then swapping the values. I have created a test case in the Django project that demonstrates my expectation in tests/model_formsets/tests.py: {{{ def test_swap_unique_values(self): p0 = Product.objects.create(slug='car-red') p1 = Product.objects.create(slug='car-blue') FormSet = modelformset_factory(Product, fields="__all__") data = { 'form-TOTAL_FORMS': '2', 'form-INITIAL_FORMS': '2', # Swap slug values. 'form-0-id': p0.pk, 'form-0-slug': 'car-blue', 'form-1-id': p1.pk, 'form-1-slug': 'car-red', } formset = FormSet(data) self.assertTrue(formset.is_valid()) formset.save() p0 = Product.objects.get(pk=p0.pk) self.assertEquals(p0.slug, 'car-blue') p1 = Product.objects.get(pk=p1.pk) self.assertEquals(p1.slug, 'car-red') }}} However, the form fails to validate on the is_valid() line with the message "Product with this Slug already exists.". When thinking about the details, I understand why this happens. But I don't think it should error in this way. Swapping values is a convenience that a program can handle without the intervention of a human. Knowing that in the end all values will be unique, I think the Django form engine should go ahead with the steps necessary to get there. I think it is reasonable for a user to expect that they could swap unique values through an HTML form in this way. As a point of reference, the following test passes. It demonstrates a user using temporary values. {{{ def test_swap_unique_values_two_step(self): p0 = Product.objects.create(slug='car-red') p1 = Product.objects.create(slug='car-blue') FormSet = modelformset_fac… Parth1811 jdufresne   0 0 0 0 0 0
25281 2015-08-16 14:53:19 2020-06-23 07:52:16 2022-03-06 04:40:41.563195 Accepted assigned contrib.auth Cleanup/optimization Normal dev   Permission strings don't uniquely identify permissions APIs related to permissions (e.g. User.has_perm()) take a 'permission string' argument of format "<app label>.<permission codename>" to refer to Permissions. But each permission is uniquely defined on the model level as a tuple of (content type, permission name). As content type refers to concrete model within a concrete app, we should be using permission string of the format "<app label>.<model name>.<permission codename>". This becomes a concrete issue once one wants to define custom permissions for their models, and doesn't observe the convention of putting the model name in the permission codenames (or wants to inherit the custom permissions form an abstract model). See also https://groups.google.com/forum/#!searchin/django-developers/permissions/django-developers/ngV5KhLXUrQ/DTfqhG0LRG4J . tsyplakou ppiet   0 1 1 0 1 0
25409 2015-09-15 19:40:13 2019-06-01 15:14:25 2022-03-06 04:41:05.736692 Someday/Maybe assigned Core (URLs) New feature Normal dev   Allow url and groups of urls to be easily tagged and selected == The Problem == Often (usually in middleware) processing has to be applied to a certain URLs only eg CORS. The usual way to specify this would be to create an additional set of regex patterns identifying these urls - eg. {{{ CORS_URLS_REGEX = r'^/api/.*$' }}} The middleware then typically matches the incoming request URL to the regex and determines whether it is to be selected for processing. This approach has several limitations including: * It violates DRY as the regexes in the settings have to be synced with the actual URL patterns * Matching multiple patterns may require the app writer to essentially reinvent URL patterns - poorly. == The Proposal == Add an optional {{{tags}}} keyword argument to {{{django.conf.urls.url}}} allowing a URL to be optionally tagged with one or more tags which can then be retrieved via {{{HttpRequest.resolver_match.tags}}} in the middleware / view etc. {{{ urlpatterns = [ url(r'^$', views.home, name='home'), url(r'^articles/$', views.show_articles, name='show-articles', tags=['require_GET']), url(r'^private/$', include(private_patterns), tags=['login_required']), url(r'^api/', include(api_patterns), tags=[ 'cors_allowed', 'nologin_forbidden', 'ajax_required' ]), ] }}} In the example above, the {{{home}}} url has no tags, the {{{show-articles}}} url is tagged {{{require_GET}}}, the urls under {{{private/}}} are all tagged {{{login_required}}} while the the urls under {{{api/}}} have multiple tags. This allows app middleware to selectively process urls very easily: {{{ class LoginRequiredMiddleware(object): def process_view(self, request, view_func, view_args, view_kwargs): if 'login_required' in request.resolver_match.tags and \ not request.user.is_authenticated(): return redirect('login') class RequireGETMiddleware(object): def process_view(self, request, view_func, view_args, view_kwargs): if 'require_GET' in request.resolver_match.tags and request.meth… atul-bhouraskar atul-bhouraskar   0 1 0 0 0 0
25582 2015-10-21 08:58:02 2021-12-17 18:37:12 2022-03-06 04:41:38.066008 Accepted assigned Core (URLs) New feature Normal dev   Add a way to build URLs with query strings It is a common question on stackoverflow and other places: How to reverse() to url including GET parameters? Example: .../myview?foo=bar http://stackoverflow.com/questions/9585491/how-do-i-pass-get-parameters-using-django-urlresolvers-reverse http://stackoverflow.com/a/27641445/633961 It would be very nice if django could implement a short-cut which provides this. It would be useful for python code and template, too. MisterRios guettli   0 0 0 0 0 0
25617 2015-10-27 17:20:44 2019-04-12 16:44:26 2022-03-06 04:41:45.223962 Accepted assigned contrib.auth Cleanup/optimization Normal dev   Disallow usernames that differ only in case in UserCreationForm Most applications don't treat user names as case sensitive. While we can't treat usernames as case-insensitive everywhere in Django due to backwards compatibility (#2273), by using `username__iexact` when checking for uniqueness of new usernames in `UserCreationForm`, we can at least prevent the creation of new usernames that differ only in case from an existing one. This protection won't cover creating a user in the shell or through the `createsuperuser` management command, but I don't think this is critical. This wouldn't affect any usernames that already exist, and users will still need to login with the same case that they register with. nmundar timgraham   0 1 1 0 0 0
25656 2015-10-31 20:12:34 2015-10-31 22:29:32 2022-03-06 04:41:51.795561 Accepted assigned contrib.admin Bug Normal dev   Recent Actions admin section contains link to edit form even when user does not have edit permission Steps to reproduce: - Login to admin with user that has add-only permission to certain model - Create an instance of this model - See that there is new logline within "Recent Actions" which contains link to edit form and results in 403 Forbidden. This is something similar to what has been spotted by Tim Graham during https://github.com/django/django/pull/5244 review so perhaps it will be handy to fix it after PR 5244 is merged so one can extend {{{test_no_forbidden_links_visible}}} test with checks for this ticket. bak1an bak1an   0 0 0 0 0 0
25706 2015-11-08 01:25:05 2021-11-30 07:25:32 2022-03-06 04:42:00.399826 Accepted assigned GIS Cleanup/optimization Normal dev   Support CSP default-src 'self' on Django Admin GIS Currently there's work (https://github.com/django/django/pull/5567) to comply with Content-Security-Policy: default-src 'self' on the base admin. It's going to require further re-factoring to apply the same to django GIS This change will also require the addition of Selenium tests for the Django Admin GIS UI See also #15727 claudep graingert CSP inline javascript 0 0 0 0 0 0
25741 2015-11-12 10:30:29 2015-11-19 09:03:30 2022-03-06 04:42:06.197592 Accepted assigned contrib.syndication Cleanup/optimization Normal 1.8   Make 'request' available to syndication.Feed methods Use case : adding an image to feed. i will to override Feed.item_extra_kwargs() and get my image url, But i can't make a Full URL as i'm missing the request.host Proposal: Add request to Feed class so it's accessible via self.request (as CBV) alexmorozov RamezIssac syndication, request 0 0 0 0 0 0
25762 2015-11-16 13:29:33 2022-02-03 08:36:50 2022-03-06 04:42:09.343885 Accepted assigned Utilities Cleanup/optimization Normal dev   Optimize numberformat.format `numberformat.format` is used a lot by Django and in most cases it's called with a number. Yet the current implementation is pretty much built for strings. I've refactored the function to be up to 4x faster on my machine (and in the worst case it performs roughly the same). Attached is the benchmark script I've used. tim-mccurrach jaap3   0 1 1 0 0 0
25880 2015-12-07 18:56:13 2019-07-20 19:12:39 2022-03-06 04:42:27.974110 Accepted assigned Forms Cleanup/optimization Normal 1.8   Forms created by formset_factory's extra parameter don't have instance set i have code of the following form: {{{ Model A: pass Model B: related_field = ForeignKey(A) class BForm(ModelForm): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) print(self.instance.related_field) def some_view(request): InlineBFormset = inlineformset_factory(A, B, formset=ABFormset, form=BForm, extra=1) formset = InlineBFormset(request.POST or None, instance=some_a_instance) }}} the line with the print crashes for the form created by the extra=1 with RelatedObjectDoesNotExist: B has no A. i would have expected that the some_a_instance is set on the form's self.instance. in django 1.9, i can easily work around that by handing over constructor parameters, but it would still seem weird to me to hand over the related instance that would later be set by the formset's save method anyways. i can provide the real code if needed. Parth1811 karyon   0 0 0 0 1 0
25946 2015-12-16 14:04:10 2020-01-28 13:30:42 2022-03-06 04:42:38.239997 Accepted assigned Database layer (models, ORM) Bug Normal dev   Negated clauses' "isnull" added term does not take field transforms into account In https://github.com/django/django/blob/32ef48aa562e6aaee9983f5d0f1c60f02fd555fb/django/db/models/sql/query.py#L1209: {{{ if (lookup_type != 'isnull' and ( self.is_nullable(targets[0]) or self.alias_map[join_list[-1]].join_type == LOUTER)): # The condition added here will be SQL like this: # NOT (col IS NOT NULL), where the first NOT is added in # upper layers of code. The reason for addition is that if col # is null, then col != someval will result in SQL "unknown" # which isn't the same as in Python. The Python None handling # is wanted, and it can be gotten by # (col IS NULL OR col != someval) # <=> # NOT (col IS NOT NULL AND col = someval). lookup_class = targets[0].get_lookup('isnull') clause.add(lookup_class(targets[0].get_col(alias, sources[0]), False), AND) }}} The problem with this is that it always performs the `isnull` on the base field, ignoring any transforms that may apply. Consider a simple custom transform on a field, `base_field`, which transforms it into `some_function ( base_field )`. Performing a negated `exact` lookup on this will generate SQL along the lines of: {{{ NOT (some_function ( "some_table"."base_field" ) = 1 AND "some_table"."base_field" IS NOT NULL) }}} This will not produce the correct results in cases where `some_function` doesn't pass through nulls as nulls or generates nulls of its own (though it's true that many functions null behaviour is to mirror the source expression null-ness exactly, which is probably why this hasn't been noticed before). The suggested "correct" SQL is probably {{{ NOT (some_function ( "some_table"."base_field" ) = 1 AND some_function ( "some_table"."base_field" ) IS NOT NULL) }}} Though I note that this is itself not problem free if we consider cases where `some_function` may have si… cansarigol ris transform negated null 0 1 1 0 0 0
25947 2015-12-17 16:57:00 2021-12-02 12:30:16 2022-03-06 04:42:38.411645 Accepted assigned Database layer (models, ORM) Bug Normal 1.9   Query's str() method fails when 'default' database is empty According to the [https://docs.djangoproject.com/en/1.9/topics/db/multi-db/ docs], we can have {{{ default database...[with]...parameters dictionary...blank if it will not be used. }}} However, when trying to print a query with something like: {{{ print Question.objects.all().query }}} you get the error that {{{ settings.DATABASES is improperly configured. Please supply the ENGINE value. }}} even though the query itself can return results. You can replicate this by creating a new project, creating a router that routes everything to a test database like so: {{{ class Router(object): def db_for_read(self, model, **hints): """ Reads go to a randomly-chosen replica. """ return 'test' def db_for_write(self, model, **hints): """ Writes always go to primary. """ return 'test' def allow_relation(self, obj1, obj2, **hints): """ Relations between objects are allowed if both objects are in the primary/replica pool. """ return True def allow_migrate(self, db, app_label, model=None, **hints): """ All non-auth models end up in this pool. """ return True # Database # https://docs.djangoproject.com/en/1.8/ref/settings/#databases DATABASE_ROUTERS = ['test123.settings.Router'] DATABASES = { 'default': {}, 'test': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': os.path.join(BASE_DIR, 'db.sqlite3'), } } }}} Create a simple model like this one: {{{ from django.db import models # Create your models here. class Question(models.Model): question_text = models.CharField(max_length=200) pub_date = models.DateTimeField('date published') }}} and run the appropriate migrations on the test database. Then attempting to print the query will fail, but the query itself will work. I believe the error is because the sql_with_params method in django.db.models.sql.quer… tjni liboz   0 1 1 0 0 0

Next page

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE tickets (
        id int primary key,
        created datetime,
        changetime datetime,
        last_pulled_from_trac datetime,
        stage text,
        status text,
        component text,
        type text,
        severity text,
        version text,
        resolution text,
        summary text,
        description text,
        owner text,
        reporter text,
        keywords text,
        easy boolean,
        has_patch boolean,
        needs_better_patch boolean,
        needs_tests boolean,
        needs_docs boolean,
        ui_ux boolean
    );