tickets

1,144 rows where needs_tests = 1 sorted by resolution

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: stage, status, type, severity, resolution, easy, has_patch, needs_better_patch, needs_docs, ui_ux, changetime (date), last_pulled_from_trac (date)

needs_tests 1 ✖

  • 1 · 1,144 ✖
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
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
2539 2006-08-13 04:09:44 2013-06-13 11:36:09 2022-03-06 03:26:19.077726 Accepted new Template system New feature Normal     Custom tags and filters can be restricted by namespace How to use namespace? For example, {{{ {% load example %} {% example.testtag %} }}} And I think if the namespace can be optional is better. I don't know if it's useful, but sometimes I read others projects, and as I reading the template, I don't know which tag is in which file. So find the correct tag definition file is somewhat diffcult. If I can add namespace in the front of a custom tag name, it'll be easy to locate the source file. The maillist discussion thread is [http://groups.google.com/group/django-developers/browse_frm/thread/2b5a4a31f0349d27/b92c96a8dccc214b#b92c96a8dccc214b HERE]   limodou@gmail.com djangocon 0 1 1 1 1 0
5349 2007-09-06 11:53:12 2012-02-18 10:42:49 2022-03-06 03:34:09.499173 Accepted new contrib.syndication Cleanup/optimization Normal dev   Shouldn't the item_enclosure_url automatically prefixed with the current site? I'd recommend to add a call to add_domain() to the enclosure URL because other URLs are also automatically extended with the site's URL. I've included the patch. nobody anonymous   0 1 0 1 1 0
5372 2007-09-09 21:36:10 2015-01-26 16:46:06 2022-03-06 03:34:12.740642 Accepted new contrib.admin Cleanup/optimization Normal newforms-admin   Cache inline ForeignKey options   nobody anonymous nfa-someday newforms, admin, inlines 0 1 0 1 1 0
5815 2007-10-25 05:20:57 2020-09-01 10:16:15 2022-03-06 03:35:27.706265 Accepted new Core (Cache system) New feature Normal dev   Adds per-view cache refreshing (clearing) This patch adds the possibility to clear(refresh) cached data per view. SmileyChris sugested it would be good to add another key to the cached keys where we could keep track of all the different cache_page_key hashes, so we that can delete those then. It is possible to clear the cache for an specific view, to achieve that, you should tell your view's url path (and optionally, a key_prefix) to ``clear_cache_for_path(path, key_prefix=None)``. {{{ from django.utils.cache import clear_cache_for_path # clear the all cached data for path '/blog/posts/2/' clear_cache_for_path('/blog/posts/2/') }}} Note that it will delete every page cached from matching this path, ``Vary`` headers doesn't matter. NOTE: Thanks SmileyChris for your help and supervision with this. nobody k0001 cache refresh clear 0 1 1 1 0 0
5865 2007-11-03 01:52:35 2013-03-22 19:25:51 2022-03-06 03:35:35.584653 Accepted new Template system New feature Normal dev   cycle template tag should accept a single argument When passed a single argument, the cycle tag should treat it as an iterable to cycle through. For example, with the context: {{{ #!python {'colors': ['red', 'blue', 'green']} }}} you should be able to have a template like: {{{ #!xml {% for row in mydata %} <tr class="{% cycle colors %}">...</tr> {% endfor %} }}} that would output: {{{ #!xml <tr class="red">...</tr> <tr class="blue">...</tr> <tr class="green">...</tr> <tr class="red">...</tr> ... }}} munhitsu gwilson   0 1 1 1 1 0
5899 2007-11-08 14:08:08 2021-11-23 11:47:07 2022-03-06 03:35:41.012357 Accepted new contrib.admin New feature Normal newforms-admin   Allow admin fieldsets to be collapsible but not initially collapsed I want to use the collapse feature of the admin, but not have the field initially collapsed, so I made this little patch. It adds a "collapsible" class that does just that. It also patches the documentation.   Ionut Ciocirlan <ionut.ciocirlan@gmail.com> admin fieldset collapsed collapsible nfa-someday 0 1 0 1 0 1
6343 2008-01-08 12:47:24 2011-09-11 01:56:58 2022-03-06 03:36:53.277353 Accepted new Database layer (models, ORM) Bug Normal dev   % symbols not escaped in db_column column names when preparing queries Using {{{%}}} in database column names (specified using {{{db_column}}}) causes the database wrapper to fail when preparing queries. This is because the {{{%}}} symbol is not properly quoted (as {{{%%}}}), and conflicts with the usage of {{{%s}}} for passing parameters to queries. I am attaching a patch for the MySQL backend where I encountered the issue; I'm not sure if other backends exhibit this bug because it presumably depends both on whether the database's native capability to support {{{%}}} characters in column names, and on the [http://www.python.org/dev/peps/pep-0249/ Python DB-API] {{{paramstyle}}}. nobody Daniel Pope <dan@mauveinternet.co.uk>   0 1 0 1 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
7556 2008-06-27 15:32:35 2021-12-31 06:39:42 2022-03-06 03:39:56.720336 Accepted new Core (Management commands) Bug Normal dev   inspectdb fails in MySql if a table references a table outside the current schema If a table contains a foreign key that refers to another table that sits outside the schema, that index includes a '.' in the table name. Suppose our current schema is `schema1`: {{{ CREATE TABLE `T1` ( `ACID` int(8) unsigned NOT NULL, `SITE` varchar(8) character set latin1 default NULL, CONSTRAINT `FK_T1_SITE` FOREIGN KEY (`SITE`) REFERENCES `schema2`.`site` (`SITE`) ) }}} For this situation, inspectdb will return something similar to this: {{{ _mysql_exceptions.ProgrammingError: (1146, "Table 'schema1.site' doesn't exist") }}} So it tries to use `schema1.site` as the table to introspect instead of the appropriate `schema2`.`site` Notice it not only needs to use the schema as part of the table name, but also not quote the '.'. Also, introspection.py was not pulling the schema name and just assuming the current schema, which for most cases is right, but in this case causes issues for legacy databases.   brockweaver mysql foreign key schema inspectdb 0 1 0 1 0 0
7623 2008-07-03 15:23:26 2021-07-31 03:29:24 2022-03-06 03:40:06.805816 Accepted new Database layer (models, ORM) New feature Normal dev   Multi-table inheritance: Add the ability create child instance from existing parent As it exists now, multi-table inheritance does not allow for the creation of a child model instance that inherits from an existing parent model instance. For example: Parent Class- {{{ class Place(models.Model): name = models.CharField(max_length=50) address = models.TextField(max_length=150) }}} Child Classes- {{{ class Restaurant(Place): place = models.OneToOneField(Place, parent_link=True) cuisine = models.CharField(max_length=75) rating = models.IntegerField() class Bar(Place): parent = models.OneToOneField(Place, parent_link=True) happy_hour = models.BooleanField() beers_on_tap = models.ManyToManyField("Beers", null=True, blank=True) }}} Sample Use-case- When the system is first deployed, a restaurant instance is created. Later, the restaurant adds a bar to increase revenue, and we now want to create a Bar model instance for the parent Place for the restaurant. I would propose the following interface for doing so: {{{ parentPlace = Restaurant.objects.get(name__iexact="Bob's Place").parent barInstance = Bar(parent=parentPlace, happy_hour=True) }}} However, if you attempt to create an instance in this manner now, you receive a DatabaseIntegrityError, saying that a Place object with that id already exists.   brooks.travis@gmail.com model-inheritance, multi-table-inheritance 0 1 1 1 0 0
7732 2008-07-12 14:30:08 2019-05-15 15:41:02 2022-03-06 03:40:23.387297 Accepted new Database layer (models, ORM) New feature Normal dev   Oracle Backend with SessionPool This new backend uses Oracle session pool to improve database performance in threaded environment. Overall speedup for large amounts of small queries is 2-3 times.   halturin yandex-sprint oracle session pool 0 1 1 1 1 0
8408 2008-08-19 07:09:11 2021-11-03 09:40:45 2022-03-06 03:42:11.159268 Accepted new contrib.admin New feature Normal dev   Add a new meta option: don't do count(*) in admin Hello, everytime when I use Admin to view a table, the Admin count the rows in the table. if the database is mysql+innodb, this step is very slow, how about add an option in Meta to prevent this, such as {{{ #!python class A(models.Model): class Meta: do_not_count = True }}} thanks tchaumeny lidaobing   0 1 1 1 0 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
9107 2008-09-16 18:06:39 2021-01-28 05:51:10 2022-03-06 03:44:02.469352 Accepted new contrib.admin New feature Normal dev   URL arguments to set values of fields in admin don't work for inlines Though it works just fine to set the value of a field in the admin with URL arguments (i.e. adding '?title=foo' to your URL sets the value of the field 'title' to 'foo'), this doesn't work if the field you're trying to set is in an inline. In such a case the syntax would presumably be something along the lines of '?inlinemode_set-0-fieldname' if you were trying to set the value fo the first instance of the inline model. This, however, doesn't work nor does any other variation I was able to think of.   josh@dydxtech.com admin inline 0 1 1 1 1 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
10070 2009-01-19 19:41:46 2020-12-29 19:55:54 2022-03-06 03:46:23.124309 Accepted new Database layer (models, ORM) Bug Normal dev   Named parameters not working on raw sql queries with sqlite The following code shows the problem when using sqlite: {{{ $ python manage.py shell Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from django.db import connection >>> c = connection.cursor() >>> c.execute("select name from inventory_host where id=%(id)s",{'id':'1'}) Traceback (most recent call last): File "<console>", line 1, in <module> File "/usr/lib/python2.5/site-packages/django/db/backends/util.py", line 19, in execute return self.cursor.execute(sql, params) File "/usr/lib/python2.5/site-packages/django/db/backends/sqlite3/base.py", line 167, in execute query = self.convert_query(query, len(params)) File "/usr/lib/python2.5/site-packages/django/db/backends/sqlite3/base.py", line 179, in convert_query return query % tuple("?" * num_params) TypeError: format requires a mapping >>> >>> import django >>> django.VERSION (1, 0, 2, 'final', 0) }}} {{{ $ sqlite3 --version 3.5.9 }}} When using Mysql or Postgres, that works (not tested by me, but by others on django-users). nobody msurdi   0 1 0 1 0 0
10191 2009-02-04 10:22:41 2014-06-06 00:01:16 2022-03-06 03:46:40.495646 Accepted new contrib.admin New feature Normal dev   Fix / Add support for radiobuttons after adding item with popup in Django Admin The following patch adds support for dynamically adding radiobutton items to the admin page. Without this patch the newly added item through the popup menu does not get added to the page and the user must reload the page before being able to select the new item. The patch adds an extra case to dismissAddAnotherPopup in RelatedObjectsLookup.js which creates and appends the necessary html to the list of radiobuttons on the page. Tested with django.contrib.redirects and a slightly modified version of django-podcast. Works (for me) on Firefox, IE and Opera. bodiddlie trbs admin, radio, radiolist, dismissAddAnotherPopup, popup 0 1 1 1 0 1
10244 2009-02-12 14:40:54 2021-02-01 17:56:04 2022-03-06 03:46:48.400509 Accepted new Database layer (models, ORM) Bug Normal 1.0   FileFields can't be set to NULL in the db Saving FileFields with a none value sets the field to a empty string in the db and not NULL as it should. nobody oyvind filefield NULL empty 0 1 0 1 1 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
10449 2009-03-09 15:44:36 2018-11-13 22:19:07 2022-03-06 03:47:18.535515 Accepted new Internationalization Bug Normal 1.0   HTML accents not escaped out when using forms When passing a translated string to a select box using a Forms Select widget, the output string still contains accent HTML entity codes. For example: "Problemas para el Inicio de Sesi&oacute;n o relacionados con la Cuenta My code is set up as follows: Models.py {{{ from django.utils import translation from django.utils.translation import ugettext_lazy as _ SUBJECT = ( (10, _('Log-in or Account related problems')), (20, _('General enquiry')), (30, _('Other feedback')), ) }}} This is then used in a form: {{{ class HelpFeedbackForm(forms.Form): #form for user to submit their feedback when not logged in subject = forms.CharField(widget=forms.Select(choices=SUBJECT)) }}} This is then presented in the template as: {{ form.subject }} which produces: "Problemas para el Inicio de Sesi&oacute;n o relacionados con la Cuenta" as mentioned above. The translations are returned from the django.po file, but all of the HTML entity codes are returned as is, in the Select box in the template. Also, use of the safe template filter tag does affect this and the string is still rendered with accents. nobody tipan accents, newforms 0 0 0 1 1 0
10743 2009-04-05 23:08:42 2021-12-10 19:05:31 2022-03-06 03:48:05.610868 Accepted new contrib.admin New feature Normal dev   Support lookup separators in ModelAdmin.list_display As with #3400, supporting the `__` lookup separator in `ModelAdmin.list_display` is useful as it avoids calling `__unicode__` bluntly, giving users more control over the output: * display several fields from the same related model, * as listed in #3400, traverse several levels of relations. One could argue that most of this can be achieved with `__unicode__` by cramming the information to its output. However, there's a larger problem with deferred fields (deferring is exemplified in [http://code.djangoproject.com/ticket/10712#comment:3 this comment]) -- namely, that couples admin code to the implementation of `__unicode__` in related models. That is, knowledge of what fields are referred to in `__unicode__` is required to write proper deferred statements. A case to illustrate how changes in `__unicode__` can have dramatic, unintentional impact: * assume the related objects are large and complex, * to keep the admin changelist view snappy, the developer looks which fields are referred to in their `__unicode__` and writes the `ModelAdmin.queryset()` method correspondingly, selecting only these fields with `only()`, * a single query is all that is needed to display the data in changelist view, admin is snappy, there is much rejoicing, * a second person keeps hacking at the related models, unknowing the impact changes to `__unicode__` could have to admin, adds another field to it, * suddenly rendering the changelist results in `n` queries, each of which pulls in the whole object. All that can be avoided with explicit `__` support. nobody mrts efficient-admin, list_display 0 1 0 1 1 0
11156 2009-05-20 10:24:55 2013-03-11 21:58:48 2022-03-06 03:49:14.909468 Accepted new Database layer (models, ORM) Cleanup/optimization Normal dev   Unnecessary savepoints with Oracle Savepoints are implemented in the Postgresql and Oracle backends, and provide a useful features to users of both. In addition, the framework itself wraps various calls in savepoints (e.g. inside django/db/models/query.py:get_or_create). This is to work around a Postgresql-specific oddity that the open transaction needs to be rolled back to a prior savepoint if it experiences a database exception. This oddity is not present on Oracle, so the extra savepoints are not required. We probably need to split the current single backend flag uses_savepoints into two: can_savepoint and needs_savepoint_after_exception. See http://groups.google.com/group/django-developers/browse_thread/thread/bca33ecf27ff5d63   Richard Davies <richard.davies@elastichosts.com> oracle savepoints 0 1 0 1 0 0
11265 2009-06-05 12:03:46 2015-01-26 18:13:50 2022-03-06 03:49:30.992285 Accepted new Database layer (models, ORM) New feature Normal     ForeignKey/OneToOneField should support user-defined id attribute name Currently, when defining a !ForeignKey/OneToOneField field XXX, Django automatically defines a XXX_id attribute to store the id value.[[BR]] However, it is sometimes desirable to decide of the name as XXX_id may not be the most appropriate. ---- Let's take the following example: - I initially have a table "Payment" with a "ccy_code" field designating a 3-letter currency code. My model definition looks like: {{{ from django.db import model class Payment(models.Model): # ... ccy_code = models.CharField(max_length=3) }}} In my python code I refer to the currency code as follows: {{{ p = Payment() #... print p.ccy_code }}} - Later, I decide to actually create a "Currency" table to hold some information about currencies. And I also decide to define a foreign key constraint from "Payment" to "Currency". My model now looks like: {{{ from django.db import model class Currency(models.Model): ccy_code = models.CharField(max_length=3, primary_key=True) #... class Payment(models.Model): # ... ccy = models.ForeignKey(Currency, to_field="ccy_code", db_column="ccy_code") }}} The problem here is that my existing Python code is broken, because "ccy_code" is not defined anymore for "Payment". Django has instead define a "ccy_id" attribute. ---- Based on the principle that defining things like foreign keys should only add functionality (and not remove any) it seems quite important to me that one can choose the id attribute name.[[BR]] [[BR]] This can be achieved by adding an optional keyword argument to !ForeignKey/OneToOneField constructors (here I decided to call it "id_attr_name").[[BR]] The implementation of this feature is pretty small and fully backward-compatible.[[BR]] Here is the SVN diff against trunk: {{{ Index: related.py =================================================================== --- related.py (revision 10924) +++ related.py (working copy) @@ -660,6 +660,7 @@ class Fo… nobody dstora foreign key ForeignKey OneToOneField id 0 1 0 1 1 0
12044 2009-10-16 16:06:11 2011-04-16 06:54:47 2022-03-06 03:51:28.367604 Accepted new contrib.admin New feature Normal 1.1   Add extra_context to admin action delete_selected We need to pass extra context in admin action delete_selected, just like admin view's delete_view. nobody rjc   0 1 0 1 0 0
12075 2009-10-22 16:06:12 2020-11-13 12:21:52 2022-03-06 03:51:32.842321 Accepted new HTTP handling New feature Normal dev   Add wsgiorg.routing args support The [http://wsgi.readthedocs.org/en/latest/specifications/routing_args.html wsgiorg.routing_args] standard may be really useful if you want to use WSGI middleware or applications inside Django because some of them take advantage of that to do nice/useful things. It's currently not supported in Django - But it will with the attached patch. ''[edit] fixed broken link.''   Gustavo WSGI, wsgiorg.routing_args 0 1 0 1 1 0
12238 2009-11-18 03:19:05 2011-04-12 17:17:56 2022-03-06 03:51:58.277595 Accepted new contrib.admin Bug Normal 1.1   ModelAdmin ignores dynamic fields of ModelForm If a ModelForm is created and then modified to programatically add fields (say, in `__init__`), !ModelAdmin ignores these fields when rendering the form. If one of these fields is added to the !ModelForm's `Meta`, the field shows up just fine. I would expect the field to display without the coaxing in `Meta.fields`. 1. Create a !ModelForm 2. Add it to !ModelAdmin 3. View Form 4. Update !ModelForm's `__init__` to include `self.fields['xyz'] = forms.CharField(max_length=255, initial='keke')` 5. View Form (note no change) 6. Update !ModelForm's `Meta.fields` to include "xyz" 7. View Form (note the change) nobody anonymous modelform modeladmin dynamic field 0 1 0 1 0 0
12651 2010-01-20 15:11:23 2016-06-22 10:10:06 2022-03-06 03:53:06.574190 Accepted new Database layer (models, ORM) New feature Normal     AutoSlugField, that can recreate unique slugs during saving. Hi! I would like to see something that can create ''unique slugs'' during ''saving of the model'' like [http://www.djangosnippets.org/snippets/728/ AutoSlugField by GaretJax in djangosnippets]. That specific implementation might be too simple and not enough configurable, but if it were improved a little perhaps? There are several slug hacks in djangosnippets alone that tries to implement unique slugs, with varying results. Naturally it should be ''part of Django'' since it is used by almost every project and every model. Housing fleet of utility libraries is not the nicest way to implement programs, I have stumbled with that a lot in the past. nobody Ciantic   0 1 1 1 1 0
12733 2010-01-30 03:41:35 2013-12-06 14:47:45 2022-03-06 03:53:18.226932 Accepted new GIS New feature Normal 1.1   Added support for Extent aggregate on mysql databases This patch enables the usage of extent aggregates for mysql backends, using MIN/MAX queries. nobody jann.kleen@freshx.de extent, mysql 0 1 1 1 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
12780 2010-02-04 22:46:02 2010-06-10 18:43:05 2022-03-06 03:53:26.324203 Accepted new contrib.admin New feature Normal dev   Provide a hook for compound form/formset validation in ModelAdmin Sometimes it is necessary to validate inline formset data based on the main form data and vice-versa. See e.g. http://groups.google.com/group/django-users/browse_thread/thread/259c1679ddaaceb8/6ad3698e5451d3fe for a use case. My use case is somewhat similar: an object can be published only if its associated items meet certain criteria. Thus, to validate the "is published" flag in the form, access to formsets is required. For advanced users a simple change is sufficient: substitute `if all_valid(formsets) and form_validated:` with `if self.formsets_are_valid(formsets, form, form_validated) and form_validated:` in `admin/options.py`, where `def formset_are_valid(self, formsets, ...): return all_valid(formsets)`. The latter can then be overriden for arbitrary further manipulations. Will upload a patch eventually. However, this means that people have to mess with either `Form` or `FormSet` internals directly (`_non_form_errors` etc) to expose the errors. This is yet another proof of a conceptual problem, quoting myself from http://groups.google.com/group/django-developers/browse_thread/thread/f9aae709a7fda689/fb16a17ab6a31931 : "''Inline formsets usually represent composition, i.e. the inline objects are inseparable from the main entity. The relation is stronger than a ForeignKey (from the main entity to another entity), yet the latter is displayed as a field of the form and can be easily manipulated -- but not the inlines.''" So, this is yet another reason for introducing !FormsetFields in the long run -- `Form.clean()` would have access to formsets both in the admin and ordinary forms. nobody mrts   0 1 0 1 0 0
13117 2010-03-15 02:10:01 2011-04-09 09:05:51 2022-03-06 03:54:18.326837 Accepted new GIS New feature Normal 1.1   Recenter OSMGeoAdmin widget with coordinates By default, all mapplets that gets created by the contrib.gis.admin.GeoModelAdmin and contrib.gis.admin.OSMGeoAdmin classes are centered at 0,0, which makes it tedious to enter geographic data with that widget when you have the lattitude and longitude coordinates in numeric form. There should be a textbox for centering the map to a set of coordinates. nobody anonymous admin widget OSMGeoAdmin 0 1 0 1 1 0
13295 2010-04-08 10:35:07 2020-03-08 04:10:18 2022-03-06 03:54:48.009026 Accepted new Database layer (models, ORM) New feature Normal 1.1   Add a Meta.sequence option to models PostgreSQL users need to be able to override the name of the serial sequence. Mostly to match existing databases, but also to solve issues like #15682, #13179 and #1946. nobody smglab sequence last_id postgresql 0 1 1 1 1 0
13539 2010-05-14 09:54:09 2020-09-14 20:28:39 2022-03-06 03:55:29.217493 Accepted new contrib.admin Bug Normal 1.8   The delete confirmation page does not check for object-level permissions when building the related list I implemented a custom authentication backend for providing object level permissions. It's all working fine, except the delete confirmation page for a particular object. I found that when building the related objects list for the confirmation page, the permissions are checked only for the model itself and not the object being processed.[[BR]] In django/contrib/admin/util.py at the 77th line you can see this check: {{{ if not user.has_perm(p): }}} which should be: {{{ if not user.has_perm(p, obj): }}} I'm attaching a patch for this. I hope that this fix will be included in the 1.2 final release. [[BR]] Thanks!   delinhabit delete object-level permissions 0 1 1 1 0 0
13664 2010-05-29 09:21:10 2015-07-24 13:40:06 2022-03-06 03:55:49.318458 Accepted new contrib.admin New feature Normal dev   Enable admin permission checks from outside the ModelAdmin At the moment there is no clean and convinient way to check for the admin permissions of a model from outside its ModelAdmin class. But for example, when I link from one model's admin to onther models's admin changelist, It would be good pratice to check first if the logged in user has the change permission for the other model. So it would be nice if the AdminSite, which is accessible from all ModelAdmin classes has methods to check those permissions for the admin of a given model. My patch adds the has_*_permission() methods from the ModelAdmin class also to the AdminSite class. But those methods in the AdminSite class takes also a model (or a string in the form 'app_label.model_name') and forwards the call to the corresponding method on the given models's admin class. nobody sebastian_noack   0 1 0 1 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
14688 2010-11-15 01:56:22 2019-04-16 16:48:10 2022-03-06 03:58:30.859304 Accepted new Forms Bug Normal dev   BaseInlineFormSet does not support "auto_id" `BaseInlineFormSet.__init__` does not accept the `auto_id` argument, unlike its ancestors. Furthmore, its parent `BaseModelFormSet` takes `**kwargs` and passes them along. I can't think of a good reason for this omission/difference. I've attached a small patch to "match" `BaseInlineFormSet.__init__` with `BaseModelFormSet.__init__`. The patch puts the "new" `auto_id` argument last in order to maximize backwards compatibility (the order is different for `BaseModelFormSet`). Arguably, both `prefix` and `auto_id` could be removed from the explicit arg list since they're just passed along (in both `BaseModelFormSet` and `BaseInlineFormSet`). nobody vicvicvic formsets 0 1 1 1 0 0
15610 2011-03-15 02:56:21 2015-10-02 19:53:40 2022-03-06 04:00:58.825199 Accepted new contrib.contenttypes Bug Normal dev   Generic Foreign Keys break when used with multi-db. Specifically, retrieving and saving objects that use the !GenericForeignKey descriptor fails when the !ContentType table is stored in a different database than the table of the instance being retrieved or saved. There can only be one valid and consistent content-type table in a system. In a two-db system, the content type table will be in either db A or db B. Therefore, a portion of the system's tables will be registered in a content-type table that is stored in a different database. This is all OK when retrieving objects based on a !GenericForeignKey reference, because a user in such a situation will typically rely on the underlying routers to determine which database to use in retrieving content-type records. However, this method in [http://code.djangoproject.com/browser/django/trunk/django/contrib/contenttypes/generic.py#L52 django/trunk/django/contrib/contenttypes/generic.py] does not use routers in determining what database to use to fetch the content-type, but instead uses the source database of the orm object the content-type of which is being queried: {{{ 52 def get_content_type(self, obj=None, id=None, using=None): 53 # Convenience function using get_model avoids a circular import when 54 # using this model 55 ContentType = get_model("contenttypes", "contenttype") 56 if obj: 57 return ContentType.objects.db_manager(obj._state.db).get_for_model(obj) 58 elif id: 59 return ContentType.objects.db_manager(using).get_for_id(id) 60 else: 61 # This should never happen. I love comments like this, don't you? 62 raise Exception("Impossible arguments to GFK.get_content_type!") }}} The above method is what is used at object-creation time to transform a generic object in the `__init__` kwargs of a new orm object into a content-type/object-id pair for purposes of saving. The use of this method results in either: (a) an error being generated when the specified table is not to be found in t… nobody legutierr   0 1 0 1 0 0
15879 2011-04-21 10:30:55 2011-04-21 19:35:27 2022-03-06 04:01:42.362788 Accepted new File uploads/storage Bug Normal 1.3   multipart/form-data filename="" not handled as file Django does not parse file uploads with empty filename as file objects in multipart/form-data requests. This happens currently if you try to upload a Blob in Firefox 4 (https://bugzilla.mozilla.org/show_bug.cgi?id=649150) Firefox sends this: {{{ Content-Disposition: form-data; name="fieldname"; filename="" Content-Type: content/type DATA }}} Reading the related RFCs there is no mention that filename="" is not allowed and the existence of the filename parameter should be enough to treat it as a file. looking at django/http/multipartparser.py 165ff {{{ file_name = disposition.get('filename') if not file_name: continue }}} this would need to set a default filename instead of bailing out (i.e. if file_name == '': file_name = 'data.bin) 590: {{{ if params.get('filename'): }}} this would need to check {{{ if 'filename' in params: }}} nobody j@mailb.org   0 1 1 1 0 0
16281 2011-06-16 09:29:37 2020-11-07 22:43:51 2022-03-06 04:02:46.731375 Accepted new contrib.contenttypes Bug Normal dev   ContentType.get_object_for_this_type using wrong database for creating object There is a subtle error in [https://docs.djangoproject.com/en/1.3/ref/contrib/contenttypes/#django.contrib.contenttypes.models.ContentType.get_object_for_this_type ContentType.get_object_for_this_type] method. {{{ def get_object_for_this_type(self, **kwargs): return self.model_class()._default_manager.using(self._state.db).get(**kwargs) }}} Database used to ''get'' ''model_class'' object is taken from self._state.db, which provides an error when ''contenttype'' model is hold in one database and model, of which object we're going to create, in another one. Database should be provided using self.model_class().objects.db not self._state.db. poirier tfrydrychewicz@gmail.com contenttype, object get_object_for_this_type, database, multiple 0 1 0 1 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
17193 2011-11-10 18:11:37 2022-01-29 22:31:33 2022-03-06 04:05:13.714085 Accepted new Core (Mail) New feature Normal     Send templated email. If your sending email it's likely that you want to render the body text from template, but there's currently no shortcut to send an email based on a template. The attached patch is based on a stripped down version of https://github.com/bradwhittington/django-templated-email It adds `django.shortcuts.send_templated_mail`, which mirrors the existing `send_mail`, but which renders the subject and body of the mail from a template, rather than taking their values explicitly. It also supports multipart html/plaintext emails. The docs will look something like this... {{{ **send_templated_mail(template_name, from_email, recipient_list, dictionary=None, context_instance=None, fail_silently=False, auth_user=None, auth_password=None, connection=None):** Sends a mail, rendering the subject and body of the email from a template. The template should contain a block named 'subject', and either/both of a 'plain' and/or 'html' block. If only the 'plain' block exists, a plaintext email will be sent. If only the 'html' block exists, the plaintext component will be automatically generated from the html, and a multipart email will be sent. If both the 'plain' and 'html' blocks exist, a multipart email will be sent. **Required arguments:** `template_name` - The template that should be used to render the email. `from_email` - The sender's email address. `recipient_list` - A list of reciepient's email addresses. **Optional arguments:** `dictionary` - The context dictionary used to render the template. By default, this is an empty dictionary. `context_instance` - The Context instance used to render the template. By default, the template will be rendered with a Context instance (filled with values from dictionary). `fail_silently` - As in `send_mail`. `auth_user` - As in `send_mail`. `auth_password` - As in `send_mail`. `connection` - As in `send_mail`. }}} julianapplebaum tomchristie   0 1 1 1 1 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
17637 2012-02-04 13:18:51 2015-05-08 14:33:37 2022-03-06 04:06:23.526574 Accepted new Forms New feature Normal 1.3   Client side validation classes for forms Having client side javascript validation for forms having common fields like username having only alphanumerics or password and Confirm password fields matching by providing a validation class. For example a user should be able to do something like : {{{ forms.TextField(validators ="usernameValidation") }}} And automatically a javascript validation for this form field should be in place. One way to do it could be using HTML5 attributes like ticket #16304. nobody karthikabinav Forms , Client Side validation, js 0 0 1 1 1 1
17814 2012-03-02 14:18:26 2015-10-07 22:41:58 2022-03-06 04:06:52.223360 Accepted new Database layer (models, ORM) New feature Normal     Add a way to override related_name on models that you can't edit I use external apps with same name models (for example it's forum.post and blog.post) and have conflict with related_name, both have user = models.!ForeignKey(User, related_name="posts") I writed patch with principle like ABSOLUTE_URL_OVERRIDES nobody yanchenko.igor@gmail.com   0 1 1 1 1 0
17834 2012-03-05 15:48:27 2016-12-08 12:54:48 2022-03-06 04:06:55.678127 Accepted new HTTP handling Bug Normal 1.3   ETag generated from empty content can break http caching The [source:/django/trunk/django/utils/cache.py?rev=17286#L100 patch_response_headers] function will set an ETag header using an md5 hash of the response content. Many responses like redirects can have an empty body and this results in the same ETag for each such response. The response headers may vary but an intermediate cache can serve an incorrect response because the ETag is not unique. A simple solution is to not set ETag if the content is empty - see attached patch. {{{#!python >>> from django.http import HttpResponseRedirect >>> from django.utils.cache import patch_response_headers >>> r1 = HttpResponseRedirect('/u1') >>> patch_response_headers(r1) >>> r2 = HttpResponseRedirect('/u2') >>> patch_response_headers(r2) >>> r1['ETag'] == r2['ETag'] True }}} nobody paulegan   0 1 0 1 0 0
17881 2012-03-12 18:16:54 2022-01-17 08:46:52 2022-03-06 04:07:03.585652 Accepted new contrib.admin New feature Normal 1.4-beta-1   Implement BaseModelAdmin.get_raw_id_fields, similar to get_readonly_fields In order to prevent massive drop downs for related fields when the related model has lots of items, I'd like to add such fields automatically to `raw_id_fields`. I've managed to make them read only by implementing the following `get_readonly_fields` method in the base class that all my `ModelAdmin` classes inherit: {{{ MODELS_WITH_TOO_MANY_INSTANCES_FOR_ADMIN_SELECT = [ 'auth.User', # ... } class ModelAdmin(admin.ModelAdmin): def get_readonly_fields(self, request, obj=None): explicit_readonly_fields = super(ModelAdmin, self).get_readonly_fields(request, obj) automatic_readonly_fields = self.related_fields_with_too_many_instances() return tuple(set(explicit_readonly_fields) | set(automatic_readonly_fields)) def related_fields_with_too_many_instances(self): fields = [] for f in self.model._meta.fields: # If the field isn't shown anyway, don't bother. if self.fields and not f.name in self.fields: continue # If we made the field editable by id, that means we want to edit it, even if it's impractical if f.name in self.raw_id_fields: continue # If the field is a ForeignKey to a blacklisted model, make it read only. if isinstance(f, (django_models.ForeignKey, django_models.ManyToManyField)): related_model = '%s.%s' % (f.rel.to._meta.app_label, f.rel.to._meta.object_name) if related_model in MODELS_WITH_TOO_MANY_INSTANCES_FOR_ADMIN_SELECT: fields.append(f.name) return fields }}} However, power users occasionally complain that they can no longer edit these fields... which is why I'd like a `get_raw_id_fields` method that I could override. nobody aaugustin raw_id_fields 0 1 0 1 1 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
18098 2012-04-10 21:44:37 2013-10-07 14:22:48 2022-03-06 04:07:38.427506 Accepted new Database layer (models, ORM) Bug Normal dev   order_with_respect_to should construct set_RELATED_order() method name from related_name If two identically named models in separate apps refer to a parent to the same parent model in their order_with_respect_to, only one set_RELATED_order() method is created on the parent model. nobody pressureman   0 1 1 1 0 0
18296 2012-05-10 07:14:49 2013-08-29 07:25:23 2022-03-06 04:08:13.026022 Accepted new Core (Management commands) Cleanup/optimization Normal 1.5   Make creating apps inside project folder more intuitive with manage.py startapp command The structure of the project created by 'django-admin.py startproject' has changed from Django 1.4. The 'manage.py' file is at the same level where the project folder containing settings.py, urls.py is present. In order to create an app within the project as was possible with Django < 1.4, the command to be used is 'python manage.py startapp <app name> <destination folder which is optional>. So if I execute the command "python manage.py startapp myapp myproject", there is an error that says "Error: <full path>/<project name>/<project name>/__init__.py already exists, overlaying a project or app into an existing directory won't replace conflicting files". The command actually expects an empty directory having the name of the app inside the project directory to work correctly. So the user has to create that directory and then create the app. This isn't very intuitive and django should create the app directory if it doesn't exist and then create the app to show the same behaviour as the previous versions. One other way to work around this behaviour is to change to the project directory and then execute python ../manage.py startapp appname. vanessagomes lgp171188@gmail.com manage.py, startapp 0 1 0 1 0 0
18597 2012-07-09 01:19:52 2021-06-08 19:19:32 2022-03-06 04:09:06.336854 Accepted new Forms Cleanup/optimization Normal 3.2   `BaseInlineFormSet` should attempt to get it's queryset from it's instance related manager before falling back to it's model's default manager The newly introduced `prefetch_related` method can be quite handy to avoid unnecessary queries (thanks Luke :), however it's quite useless when used with `BaseInlineFormSet` since [https://github.com/django/django/blob/4a103086d5c67fa4fcc53c106c9fdf644c742dd8/django/forms/models.py#L694 it won't even try to get its needed `queryset` from the related manager]. i.e. {{{#!python from django.db import models class Author(models.Model): name = models.CharField(max_length=255) class Book(models.Model): name = models.CharField(max_length=255) author = models.ForeignKey(Author, related_name='books') class Meta: # Needed because `BaseModelFormSet.get_query_set` wants an ordered set or issue another query ordering = ('pk',) }}} {{{ In [1]: from django.conf import settings In [2]: from django.db import connection In [3]: from library.models import * In [4]: from django.forms.models import inlineformset_factory In [5]: a = Author.objects.create(name='David Abram') In [6]: b1 = Book.objects.create(name='Becoming Animal', author=a) In [7]: b2 = Book.objects.create(name='The Spell of the Sensuous', author=a) In [8]: BookInlineFormSet = inlineformset_factory(Author, Book) In [9]: settings.DEBUG = True In [10]: instance = Author.objects.prefetch_related('books').get() In [11]: BookInlineFormSet(instance=instance) Out[11]: <django.forms.formsets.BookFormFormSet at 0x3c68d50> In [12]: print connection.queries [{u'time': u'0.000', u'sql': u'SELECT "library_author"."id", "library_author"."name" FROM "library_author"'}, {u'time': u'0.000', u'sql': u'SELECT "library_book"."id", "library_book"."name", "library_book"."author_id" FROM "library_book" WHERE "library_book"."author_id" IN (1) ORDER BY "library_book"."id" ASC'}, {u'time': u'0.000', u'sql': u'SELECT "library_book"."id", "library_book"."name", "library_book"."author_id" FROM "library_book" WHERE "library_book"."author_id" = 1 ORDER BY "library_book"."id" ASC'}] }}} I guess it'… nobody charettes model formset inline 0 1 0 1 0 0
18914 2012-09-06 13:17:02 2017-02-22 17:40:36 2022-03-06 04:09:56.370216 Accepted new contrib.admin New feature Normal dev   Add a way to add items to the admin's object tools using Python code Adding object tools requires template overrides or subclassing of ModelAdmin. It should be possible to add object tools in the same way that admin actions can be defined. nobody mcrute admin object-tools 0 1 1 1 0 0
19806 2013-02-12 04:44:17 2013-02-24 23:35:42 2022-03-06 04:12:18.939062 Accepted new Core (Management commands) Bug Normal 1.4   django_bash_completion clobbers upstream completion of ‘python’ `extras/django_bash_completion` now tries to complete `python manage.py` in addition to `./manage.py` (#12174), but this results in the upstream completion hook for `python` being entirely clobbered. For example, the upstream hook completes `python -Q`, but this is lost when loading `django_bash_completion`: {{{ $ python -Q <TAB> new old warn warnall $ . extras/django_bash_completion $ python -Q <TAB> AUTHORS .git/ LICENSE setup.py CONTRIBUTING.rst .gitattributes MANIFEST.in tests/ django/ .gitignore README.rst .tx/ docs/ .hgignore scripts/ extras/ INSTALL setup.cfg }}} That seems like a really unfriendly thing to do, especially on Linux distros where merely installing the Django package pulls in `django_bash_completion` automatically. I don’t know of a way to install a completion hook for `python manage.py` without clobbering all of `python`, so I would propose that the second half of the script (starting at `_python_django_completion`) should be deleted entirely. Users who want bash completion can type `./manage.py` or `django-admin` instead.   andersk   0 1 0 1 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
20942 2013-08-20 00:49:01 2013-09-10 22:38:05 2022-03-06 04:15:11.258932 Accepted new Forms Bug Normal 1.5   modelformset wrongly assumes foreign keys can't point to proxy models. Background: My reusable app [https://github.com/craigds/django-typed-models django-typed-models] extends proxy models with a type field, so the proxy model for each instance gets stored in the database. I wanted to have a ForeignKey pointing to one of those proxy models. The database level behaviour is the same (it points to the concrete model that the proxy model proxies), but this makes Django do better type checking for me: {{{ class Animal(TypedModel): name = models.CharField() class Canine(Animal): pass class Feline(Animal): pass class BigCat(Feline): pass class OtherModel(models.Model): # at DB level this points to Animal cat = models.ForeignKey(Feline) }}} The idea being that this will work fine: {{{ othermodel.cat = BigCat(name="simba") }}} But this will throw an error: {{{ othermodel.cat = Canine(name="fido") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/cdestigter/checkout/django/django/db/models/fields/related.py", line 405, in __set__ self.field.name, self.field.rel.to._meta.object_name)) ValueError: Cannot assign "<Canine: fido>": "OtherModel.cat" must be a "Feline" instance. }}} This *almost* works ;) In fact, it works everywhere except in the admin. I get these errors: {{{ Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.6/dist-packages/dandelion/geostore/admin.py", line 7, in <module> admin.autodiscover() File "/home/cdestigter/checkout/django/django/contrib/admin/__init__.py", line 29, in autodiscover import_module('%s.admin' % app) File "/home/cdestigter/checkout/django/django/utils/importlib.py", line 35, in import_module __import__(name) File "/usr/lib/python2.6/dist-packages/dandelion/datasources/admin.py", line 183, in <module> import_module(admin_module) File "/home/cdestigter/ch… nobody cdestigter   0 1 1 1 0 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
21273 2013-10-15 17:02:50 2014-03-13 11:00:04 2022-03-06 04:16:01.179053 Accepted new GIS Cleanup/optimization Normal dev   Add read only support for Oracle XE to django.contrib.gis django.contrib.gis.backends supports Oracle but does not support the spatial component of Oracle XE. Oracle XE has a more lenient licence than Oracle and may be useful for accessing legacy spatial data. Oracle XE may be accessed using cx_Oracle, but spatial data is not converted into a usable form. The spatial data stored in oracle is documented (search for 'oracle sdo_geometry'). The following is a short description of the point attribute - I will expand with other types asap. Example - Oracle spatial table named Floods with a spatial field geoloc: {{{ >>> from import_data.models import * >>> floods = Floods.objects.all() >>> f = floods[99] >>> g = f.geoloc >>> g <cx_Oracle.OBJECT object at 0xa02a3e0> >>> dir(g) ['__class__', '__delattr__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'type'] >>> gtype = str(int(g.__getattribute__('SDO_GTYPE'))) >>> print gtype 2001 >>> gdims = gtype[0] >>> gdims '2' >>> gtopo = gtype[1] >>> gtopo '0' >>> ggeomtype = gtype[2:] >>> ggeomtype '01' >>> gsrid = g.__getattribute__('SDO_SRID') >>> gsrid 82086.0 >>> gpoint_x = g.__getattribute__('SDO_POINT').X >>> gpoint_y = g.__getattribute__('SDO_POINT').Y >>> gpoint_z = g.__getattribute__('SDO_POINT').Z >>> print gpoint_x, gpoint_y, gpoint_z 162913.389524 340748.357977 None >>> g_ewkt = "SRID:%s:POINT(%f %f)" % (str(int(g.__getattribute__('SDO_SRID'))), g.__getattribute__('SDO_POINT').X, g.__getattribute__('SDO_POINT').Y) >>> g_ewkt 'SRID:82086:POINT(162913.389524 340748.357977)' }}} From the Oracle docs, this is a 2 dimensional (gdims), null topology (gtopo), POINT geometry, srid = 82086 (Irish Grid), with x and y co-ordinates and null z coordinates. Further information is stored in other attributes for more complex geometries - a very wide range is available. For a point, these may not necessarily be used. {{{ >>> print g.__getattribute__('SDO… nobody vinhussey   0 0 0 1 1 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
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
23076 2014-07-22 09:52:46 2021-03-15 21:01:06 2022-03-06 04:21:49.346314 Accepted new Database layer (models, ORM) Bug Normal dev   Cascaded deletion of polymorphic models fails Currently, when deleting polymorphic models (for example by using `django-polymorphic`), the `django.db.models.deletion.Collector` incorrectly assumes that all models are of the same type as the first model in the list. Then, it generates incorrect delete statements when polymorphic models are used which then result in an `IntegrityError` when the transaction is committed. This is a patch that applies to 1.6.x and master (see pull request [https://github.com/django/django/pull/2940 2940]) that fixes this issue and it is directly based on a patch submitted by Kronuz at the end of ticket #16128. nobody jernej@kos.mx   0 1 0 1 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
24218 2015-01-25 02:55:50 2018-07-03 18:16:24 2022-03-06 04:26:58.248227 Accepted new Database layer (models, ORM) New feature Normal dev   Use sub-query in ORM when distinct and order_by columns do not match This ticket is to propose a slight change in ORM - use subqueries when querying a model where {{{.distinct()}}} and {{{.order_by()}}} (or {{{.extra(order_by=())}}}) leftmost columns do not match. For example: {{{#!python Model.objects.all().distinct('foo').order_by('bar') }}} The above generates the following SQL: {{{#!sql SELECT DISTINCT ON ("app_model"."foo") <lots of columns here> FROM "app_model" ORDER BY "app_model"."bar" ASC; }}} I am not sure about all backends however the above syntax is not allowed in PostgreSQL which produces the following error: {{{#!sql ERROR: SELECT DISTINCT ON expressions must match initial ORDER BY expressions }}} Here are [http://www.postgresql.org/docs/9.0/static/sql-select.html#SQL-DISTINCT PostgreSQL docs] explaining why that is not allowed: DISTINCT ON ( expression [, ...] ) keeps only the first row of each set of rows where the given expressions evaluate to equal. [...] Note that the "first row" of each set is unpredictable unless ORDER BY is used to ensure that the desired row appears first. [...] The DISTINCT ON expression(s) must match the leftmost ORDER BY expression(s). This ticket proposes to use subqueries in such situations which would use SQL: {{{#!sql SELECT * FROM ( SELECT DISTINCT ON ("app_model"."foo") <lots of columns here> FROM "app_model" ) result ORDER BY "app_model"."bar" ASC; }}} The above is perfectly valid SQL and produces expected results (please note that {{{ORDER_BY}}} is in the outer query to guarantee that distinct results are correctly sorted). I created a simple proof-of-concept [https://gist.github.com/miki725/ce26d8b6ee2f3075884a patch] by overwriting few things in {{{SQLCompiler.as_sql()}}} which seems to work pretty well. The patch only creates subquery when the above dilema is encountered which should not have any negative side-effects on existing queries (since such queries were not allowed by SQL). The patch also works on the {{{.count()}}} queries since Django then strips any ordering h… nobody miki725 subquery distinct order_by 0 1 0 1 1 0
24472 2015-03-11 09:44:25 2021-02-09 12:05:14 2022-03-06 04:27:44.082395 Accepted new Database layer (models, ORM) New feature Normal dev   Define internal types explicitly for related fields For related fields internal type is not defined explicitly. For example, if I want to inherit these fields to add some minor changes, I will need to define internal type manually, because some of backend code is related on internal type of the field. Old pull request - https://github.com/django/django/pull/4002 We discussed here that is a good idea to have this feature in 1.9   coldmind   0 1 0 1 0 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
24581 2015-04-04 09:54:10 2015-04-04 11:45:28 2022-03-06 04:28:08.443769 Accepted new Database layer (models, ORM) Cleanup/optimization Normal 1.8   Explicitly raise an exception if ManyToManyField._get_m2m_attr fails to match In cases like #24513 it results in surprising error messages and useless tracebacks. nobody patrys   0 1 0 1 0 0
24686 2015-04-22 16:22:57 2020-12-27 13:47:33 2022-03-06 04:29:15.578408 Accepted new Migrations New feature Normal dev   Support for Moving a model between two Django apps An issue that I run into is that at some point one of my apps becomes so large that I decide to split the application into a number of separate logical units. Right now the Django migration system leaves me on my own to write a correct migration to support updating the db to reflect the new multi-app layout. There is an [http://stackoverflow.com/questions/25648393/how-to-move-a-model-between-two-django-apps-django-1-7 SO post] that attempts to outline a solution but I would suggest trying to detect these model moves and then auto-generating these migrations.   cancan101   0 1 0 1 1 0
24778 2015-05-10 18:19:33 2022-01-04 02:11:19 2022-03-06 04:32:34.815457 Someday/Maybe new Migrations New feature Normal dev   Data Migration from Fixture Providing data via fixtures has been deprecated. In the past, we used to execute the loaddata manually. After Django introduce migration, the recommended way to import data is to create an empty migration and use `RunPython` migration operations to load the data. This is a very common use case for data migration via fixture. We create the function just to call_command `loaddata`. http://stackoverflow.com/a/25981899/764592 In my opinion, instead of having to create the function, we can actually simplify this into a migration operation on its own. As follow: {{{ # Module: django.db.migrations.operations.base.special from django.core.management import call_command class LoadFixture(Operation): reduces_to_sql = False reversible = False def __init__(self, *fixtures): self.fixtures = fixtures def state_forwards(self, app_label, state): pass def database_forwards(self, app_label, schema_editor, from_state, to_state): for fixture in self.fixtures: call_command('loaddata', fixture, app_label=app_label) def database_backwards(self, app_label, schema_editor, from_state, to_state): pass … nobody 9gix   0 1 1 1 1 0
24810 2015-05-17 12:31:37 2021-11-09 17:21:16 2022-03-06 04:33:26.737922 Accepted new Database layer (models, ORM) New feature Normal dev   Reopen database connection automatically when no transaction is active This is a follow-up of #15802. When the database closes the connection, for instance because the database server was restarted, an exception will be raised the next time user code attempts to use the database. Django doesn't attempt to do anything about it. This is expected to result in at most one 500 error for each thread that serves requests, since database connections are thread-local. This doesn't sound horrific. After all the database was restarted while the website was serving requests. It can also cause management commands to crash, which isn't the end of the world either since management commands should fall into one of the following categories: - short-lived, idempotent and scheduled to run regularly - long-lived and supervised to run constantly - run manually If the connection was in autocommit mode and an operation fails because the database has closed the connection, theoretically, it's safe the reopen the connection and retry the operation. In that case, Django could continue to operate transparently instead of raising an exception. This may not be easy to implement. nobody aaugustin   0 1 0 1 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
25464 2015-09-25 08:58:47 2015-11-07 10:34:57 2022-03-06 04:41:15.270255 Accepted new Database layer (models, ORM) New feature Normal dev   Allow skipping IN clause on prefetch queries When using prefetch_related() on a large queryset, the prefetch query SQL can be inefficient. Consider this: {{{ Category.objects.filter(type=5).prefetch_related('items') }}} If 100.000 categories have type=5, then an IN clause with 100.000 Category IDs is generated to get the Item objects. Even with a custom queryset using a Prefetch() object, the IN clause is generated, even though it is A) redundant, B) sends a potentially multi-megabyte SQL statement over the wire for the database to process, C) may confuse the query planner to generate an inefficient execution plan, and D) doesn't scale: {{{ Category.objects.filter(type=5).prefetch_related(Prefetch('items', queryset=Item.objects.filter(category__type=5))) }}} Pull request https://github.com/django/django/pull/5356 adds the possibility to skip the IN clause in cases where we are sure that a better queryset will get (at least) the same items as the IN clause would: {{{ Category.objects.filter(type=5).prefetch_related(Prefetch('items', queryset=Item.objects.filter(category__type=5), filter_on_instances=False)) }}} In my tests, this speeds up prefetch_related() by 20x-50x on large querysets. nobody ecederstrand   0 1 0 1 1 0
25705 2015-11-07 23:59:35 2021-12-31 10:36:39 2022-03-06 04:42:00.239105 Accepted new Database layer (models, ORM) Cleanup/optimization Normal dev   Parameters are not adapted or quoted in Query.__str__ Now it is just string interpolation of the SQL template with parameters and in most cases produces invalid queries for the following reasons: - No quoting - No adaptation. So, some python objects will be used as is, not like their SQL equivalents Yes, there are situations, when output of `Query.__str__` is equal to actual query. But for debugging reasons, it will be better to see real query here. Also it is logical and expected behavior of this method - to show actual query.   Stranger6667   0 1 1 1 0 0
27064 2016-08-15 00:58:08 2020-07-13 17:08:11 2022-03-06 04:45:23.316368 Accepted new Migrations New feature Normal dev   Implement RenameIndex in a backwards compatible way In order to eventually deprecate `index_together` we need a way to deal with old projects that have unnamed indexes. This proves to be a non-trivial problem. Andrew and I came up with these things to consider. * `RenameIndex(model, new_name, old_name=None, old_fields=None)` where exactly one of `old_name` and `old_field` is given (`old_name ^ old_fields`) * If the old_name is given we use `RENAME INDEX` if available * Otherwise look at the state and drop existing indexes and create new the index with new name * On MySQL (or other DBs) that don't support `RENAME INDEX`, provide SQL query to look up index name from information_schema by field names and pass in to `DROP INDEX`. * If more than one index is found while identifying with field names, migrations must error out with an `AmbiguityError` * If the autodetector finds an old, unnamed index and a new, named one matching field signature, issue a `RenameIndex` operation * For backwards operations with unnamed old indexes, `RenameIndex` is a noop. nobody MarkusH   0 0 0 1 1 0
27080 2016-08-18 00:19:12 2018-12-27 16:53:22 2022-03-06 04:45:26.009552 Accepted assigned Migrations New feature Normal dev   `as_manager` on QuerySet should pass down `use_in_migrations` to new Manager instance When using the convenience method `as_manager` on a QuerySet the attribute `is_in_migrations` (https://docs.djangoproject.com/en/1.9/topics/migrations/#model-managers) is currently not passed down. This means that when creating a migration the `Manager`s which a created from `QuerySet`s won't be serialised into the migration. The current workaround would be to create Manager class from the QuerySet, thereby using the old approach where `QuerySet.as_manager` isn't used. orn688 leifdenby   0 1 1 1 0 0
27452 2016-11-06 11:30:06 2020-11-14 17:21:57 2022-03-06 04:46:18.255930 Accepted assigned contrib.postgres New feature Normal dev   Add Postgres serial field to contrib.postgres Since we have the beautiful `contrib.postgres` package now, we can add a couple more Postgres specific fields, that are not supported by MySQL but handy to all the Postgres fan boys. That being said, I guess it's a good idea to start with `Serial`. The PostgreSQL documentation: https://www.postgresql.org/docs/9.1/static/datatype-numeric.html describes the field as follows: The data types `serial` and `bigserial` are not true types, but merely a notational convenience for creating unique identifier columns (similar to the AUTO_INCREMENT property supported by some other databases). **Use Cases:** 1. Anywhere an automatic incrementing value is required, but a primary key is often (mis)used. 2. Providing additional (user controlled) auto-incrementing values. The primary benefit is that is isolates the primary key for the sole use of maintaining referential integrity. InvalidInterrupt codingjoe   0 1 0 1 1 0
27614 2016-12-18 19:50:14 2020-11-07 15:48:14 2022-03-06 04:46:41.409731 Accepted assigned Database layer (models, ORM) Cleanup/optimization Normal 1.10   Store the DB used in the state before calling Model._save_table() I was trying to figure out why when calling `.using` before `.create` the `self._state.db` was not available. I happen to want the result of that to use in the `pk` value, so right now I have to re fetch that information. As it turns out, the cause can be narrowed down to a single line. However, I'm not sure if it was ordered that way for a reason but here: https://github.com/django/django/blob/d2a26c1a90e837777dabdf3d67ceec4d2a70fb86/django/db/models/base.py#L831-L836 Since not every function call gets the `using` param passed to it, but most get the `instance` like when it wants to get a pk value prior to saving. I was wondering if it's possible to move that `self._state.db = using` up. mystmn JBKahn   0 0 0 1 0 0
28054 2017-04-07 15:05:33 2021-10-26 08:07:13 2022-03-06 04:47:49.519338 Accepted new Core (Management commands) Bug Normal 1.10   After #26052 runserver returns response body for HTTP HEAD requests For compliance with RFC 2616, section 4.3, response bodies must not be returned for HEAD requests. In #26052, the stripping of the response bodies was removed from Django in favour of letting the server perform the body removal, since the common servers (gunicorn, mod_wsgi etc) already do so. However it appears that runserver does not strip the body, contrary to: https://code.djangoproject.com/timeline?from=2016-04-23T20%3A26%3A34-05%3A00&precision=second As such, starting in Django 1.10 the responses from runserver for HEAD requests are no longer compliant with the spec. (In certain configurations this also results in "Broken pipe" error messages in runserver output, since compliant user agents expect to be able to terminate the connection after the headers are sent.) STR: 1) `mkvirtualenv django-test` 2) `pip install 'Django>1.10,<1.11'` 3) `django-admin startproject django-test` 4) `cd django-test` 5) `./manage.py runserver` 6) In another terminal, run `curl -iX HEAD http://127.0.0.1:8000/` 7) Observe response from curl Expected: {{{ HTTP/1.0 200 OK Date: Fri, 07 Apr 2017 14:56:39 GMT Server: WSGIServer/0.2 CPython/3.4.5 Content-Type: text/html X-Frame-Options: SAMEORIGIN }}} Actual: {{{ HTTP/1.0 200 OK Date: Fri, 07 Apr 2017 14:56:39 GMT Server: WSGIServer/0.2 CPython/3.4.5 Content-Type: text/html X-Frame-Options: SAMEORIGIN <!DOCTYPE html> <html lang="en"><head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <meta name="robots" content="NONE,NOARCHIVE"><title>Welcome to Django</title> ... }}} Tested with Python 2.7.13 and 3.4.5. Doesn't reproduce under Django 1.9.13. nobody edmorley runserver 0 1 1 1 0 0
28263 2017-06-01 09:59:22 2021-03-09 19:26:49 2022-03-06 04:48:19.241899 Accepted new Testing framework Bug Normal 1.11   TestCase breaks for databases that don't support savepoints {{{TestCase}}}s with more than one test fail with {{{ TransactionManagementError: An error occurred in the current transaction. You can't execute queries until the end of the 'atomic' block. }}} when {{{uses_savepoints = False}}} and {{{supports_transactions = True}}}. To reproduce this issue set {{{uses_savepoints = False}}} for any of the backends other than MySQL with MyISAM as MyISAM engine doesn't transactions as well. This setting can be set in any of the following files according to the database used. * {{{django/db/backends/postgresql/features.py}}} * {{{django/db/backends/mysql/features.py}}} * {{{django/db/backends/sqlite3/features.py}}} I feel this case is not handled in the implementation of {{{TestCase}}}. nobody eldos-dl   0 1 1 1 0 0
28369 2017-07-06 19:00:05 2019-12-09 04:59:10 2022-03-06 04:48:33.512836 Accepted assigned contrib.admin New feature Normal dev   Provide ModelAdmin hooks for reversing URLs Django admin could provide a hook for cases where there are additional parameters necessary to build an add or change url. Current hook "response_change" makes many hard-coded presumptions about how to reverse and add or change url. While its a nice hook to have for some cases, its so verbose that overriding it for this purpose is very hard. berabhishek yeago   0 1 0 1 1 0
28598 2017-09-14 18:55:52 2020-12-17 13:40:31 2022-03-06 04:49:05.757295 Accepted assigned Core (Mail) Cleanup/optimization Normal 1.11   BCC addresses are ignored in the console and file email backends Hi there, we noticed during development that the bcc header line is not printed in the console (and filebased since it inherits from console) EmailBackend ({{{django.core.mail.backends.{console|filebased}.EmailBackend}}}). It seems like this issue has been reported before, e.g. in #18582, however there was no specific solution. It looks like a design decision, however there is no documentation (that I found) about it. In my opinion, it would be nice to have the BCC line printed in those backends. As the documentation says, those backends are not intended for use in production, which makes it an ideal tool for development and testing. However that requires that the backend behaves just as a regular (smtp) backend would and display the email message exactly as it would have been sent. If you decide not to fix this, please add a note to the documentation to help developers avoid a sleepless night because they really can't get BCC to work in their mail function ;) Best, zngr jschneier zngr mail, bcc 0 1 1 1 0 0
28636 2017-09-26 09:15:01 2017-11-17 04:21:29 2022-03-06 04:49:11.470367 Accepted new Internationalization New feature Normal dev   Allow customizing the fallback language from the locale middleware **Problem**: The user's discovered language preference is only returned when found in `settings.LANGUAGES`. That's more than sufficient for the normal translation routine, but there seems to be no way (at least no DRY way) to find out a user's preference REGARDLESS of `settings.LANGUAGES`. **Suggestion**: It would be nice to have an easy way for finding out a languange preference from request, even if it's not listed in your supported languages. You could think of an optional flag, so that the preference from `get_language_from_request` is checked against `LANG_INFO` in the translation module rather than against `settings.LANGUAGES`. This would give you one of all available languages in the translation module. You could use that e.g. for comparing with `settings.LANGUAGE_CODE` and add a fallback for specific cases. nobody denisiko translation, internationalization, request 0 1 0 1 1 0
28785 2017-11-08 03:50:36 2021-06-08 08:22:14 2022-03-06 04:49:35.963582 Accepted assigned Migrations New feature Normal 1.11   Tracking migrations Migrations exist in django in two locations: 1. In the codebase under app_name/migrations 2. As a db entry in django_migrations I've come across the following scenario where I expected Django to give an error but it didn't not. Assume we have 4 migrations for an app, and migration 1 through 3 are applied. {{{ # Content of Postgres DB 32 | app_name | 0001_initial 33 | app_name | 0002_migration2 34 | app_name | 0003_migration3 }}} All migrations except 0001_initial.py were deleted including the folder pycache. We then run makemigrations {{{ # Contents of migration folder after makemigrations was ran. 0001_initial.py 0002_name.py __init__.py __pycache__ # Run makemigrations No Changes Detected # Output of showmigrations app_name [X] 0001_initial [X] 0002_name }}} Contents of Postgres django_migrations, however, remain unchanged still with an entry for a third migration. I expected an error in one of the following commands but received none: makemigrations, migrate, showmigrations. Also, migrate --fake app_name 0002_name does not lead to the deletion of 0003_migration3 entry in django_migrations manav014 ramezkabbani   0 1 1 1 0 0
29027 2018-01-16 08:42:34 2020-04-20 14:06:43 2022-03-06 04:50:12.582714 Accepted new File uploads/storage Bug Normal 1.11   file_move_safe() PermissionError with SELinux PermissionError on upload of large files (large enough to not use the in-memory file class) when SELinux is in enforce mode. The error happens after the file is copied to the destination folder. As seen in the trace below, when copystat is called from file_move_safe, shutil tries to set attributes with setxattr. But this is failing when SELinux is enabled. I noticed on temporarily disabling SELinux that the files which are successfully uploaded now have a context of 'httpd_tmp_t' as opposed to the context of 'httpd_sys_rw_content_t' which the directory is configured with. So, when SELinux is enabled, setxattr is failing when the context of the file is 'httpd_sys_rw_content_t'. {{{ Traceback (most recent call last): File "/home/portal/venv/lib/python3.6/site-packages/django/core/handlers/exception.py", line 41, in inner response = get_response(request) File "/home/portal/venv/lib/python3.6/site-packages/django/core/handlers/base.py", line 249, in _legacy_get_response response = self._get_response(request) File "/home/portal/venv/lib/python3.6/site-packages/django/core/handlers/base.py", line 187, in _get_response response = self.process_exception_by_middleware(e, request) File "/home/portal/venv/lib/python3.6/site-packages/django/core/handlers/base.py", line 185, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/home/portal/venv/lib/python3.6/site-packages/django/contrib/auth/decorators.py", line 23, in _wrapped_view return view_func(request, *args, **kwargs) File "/home/portal/project/assignments/views/views.py", line 270, in edit_answer instance.answerfile_set.create(file=upload, file_type=file) File "/home/portal/venv/lib/python3.6/site-packages/django/db/models/fields/related_descriptors.py", line 653, in create return super(RelatedManager, self.db_manager(db)).create(**kwargs) File "/home/portal/venv/lib/python3.6/site-packages/django/db/models/manager.py", line 85, in manager_method return… nobody bhargu selinux 0 1 0 1 0 0
29115 2018-02-05 17:47:09 2021-09-21 21:27:52 2022-03-06 04:50:26.566568 Accepted assigned contrib.admin New feature Normal dev   Allow rendering of admin forms with Jinja2 As previously [https://groups.google.com/forum/#!topic/django-developers/JS7VkBxMQa4 posted to the django-developers mailing list]: According to the documentation[1], "...django.contrib.admin doesn’t include Jinja2 templates for its widgets due to their usage of Django template tags." After some digging, though, it appears that the "spaceless" tag is the only one in use which is not readily available in Jinja2. And this is only used in django/contrib/admin/templates/admin/widgets/related_widget_wrapper.html. So, I was able to reimplement this template in Jinja2, minus the spaceless tag. On a few admin pages with large numbers of inlines, the load time was cut in half or better. But, of course, there was one more small catch. I had to use the "TemplateSetting" form renderer rather than the "Jinja2" form renderer, because I had no way to alter the Jinja2 environment for the form renderer. The environment I refer to in my settings, however, is pulled almost verbatim from the documentation for the Jinja2 backend[2]. I only had to add one thing: i18n. Which turns out to be fairly simple to do with Jinja2 + Django. I was even able to use the "gettext" and "ngettext" from django.utils.translation. So what I'm proposing here boils down to a few pieces: 1. Create jinja2 templates for the admin widgets. I already have one of these done, and the others look like it may be possible to simply copy them. 2. Document how to add i18n to the Jinja2 environment 3. Perhaps provide a default environment to Jinja2, providing both static and url, as currently documented in the example Jinja2 environment, along with i18n. This would provide a better out-of-the-box experience for users, including being able to set the FORM_RENDERER to Jinja2, and have the admin Just Work. smithdc1 tarkatronic   0 1 0 1 0 0
29257 2018-03-25 00:36:51 2020-07-04 00:22:00 2022-03-06 04:50:48.159162 Accepted new Database layer (models, ORM) Bug Normal 2.0   If creation of a db cursor fails, the resulting traceback is misleading When a schema is out of sync (eg. running tests for a project where a model has fields not present in the migration). The creation of a cursor involves a sql query which includes all of the field names. Creating that cursor will fail. However, the exception is currently caught by a try/except which always attempts to *close* the cursor. Closing the cursor is not try/excepted, which results in that particular query failing and a traceback that looks like "ERROR: cursor "_django_curs_140260213699904_6" does not exist". Patch: {{{ commit 7c7a1f53acbf7d94f0a9b360f973711a7c9fbfbd (HEAD -> refs/heads/master) Author: Jerome Leclanche <jerome@leclan.ch> Date: Tue Mar 20 09:57:26 2018 +0200 Raise outer exception when failing to close a cursor after an error diff --git a/django/db/models/sql/compiler.py b/django/db/models/sql/compiler.py index 1fdbd156b6..f96be3c4ea 100644 --- a/django/db/models/sql/compiler.py +++ b/django/db/models/sql/compiler.py @@ -1051,10 +1051,15 @@ class SQLCompiler: cursor = self.connection.cursor() try: cursor.execute(sql, params) - except Exception: + except Exception as e: # Might fail for server-side cursors (e.g. connection closed) - cursor.close() - raise + try: + cursor.close() + except Exception: + # If we got an error creating the cursor, then closing it + # will always fail. Raise the outer exception instead of the + # obscure "cursor _django_curs_xxxx does not exist". + raise e from None if result_type == CURSOR: # Give the caller the cursor to process and close. }}} nobody jleclanche   0 1 0 1 0 0
29381 2018-05-05 10:26:52 2018-05-17 14:39:52 2022-03-06 04:51:05.618566 Accepted new contrib.auth New feature Normal dev   Move some parts of `django.contrib.auth.models` to `django.contrib.auth.base_user` for reusability ---- This is more of an idea than bug but most of the time when need to use authentication without using `contrib.auth` one needs to rewrite some of the parts that can be reused if it were in base_user when the interface is similar to django.contrib.auth. I am mostly talking about update_last_login function and AnonymousUser when custom user is derived from AbstractBaseUser. May be create AnonymousBaseUser with parts that are compatible to AbstractBaseUser in `base_user.py` and use that as base class for AnonymousUser. Also, update_last_login function can be moved to `base_user.py` so that it can be reused. nobody sagarchalise   0 1 1 1 1 0
29522 2018-06-25 02:19:27 2019-04-19 11:20:03 2022-03-06 04:51:27.512624 Accepted assigned Core (Serialization) Cleanup/optimization Normal dev   Make Serializers easier to modify. **Use case** Three times now I've had need to modify the ORM serializers for project use. In some cases I've had to replicate large parts (if not most) of `django.core.serializers.python` in order to change 1 or 2 lines because certain calls to functions in `django.core.serializers.base` from the serializers are hardcoded. * Changing JSON serialization to output in alphabetical order (so that `dumpdata` doesn't reorder every field each time you run it) * Changing deserialization to use `_base_manager` instead of `_default_manager` (due to extra constraints on a custom manager) * Implementing fixes for #7202, #7350 before they were merged **Proposal** I propose that instead of calling the following functions directly, the serializer classes are modified to call an instance method of the same name that then calls the existing module-level functions. This would allow the ability to more easily override just one aspect of serializer functionality without having to replicate large swathes of code. I am not proposing to move these functions into the python serializer class directly because this may break compatibility with existing code that depends on the existing functions. * `django.core.serializers.base.build_instance` * `django.core.serializers.base.deserializer_m2m_values` * `django.core.serializers.base.deserializer_fk_values` * `django.core.serializers.python._get_model` (given that this is already an internal function, implementation can be pushed into the class directly) (It might also be nice if the `json` and `pyyaml` classes could also have `PythonDeserializer` be made a class attribute but that would involve turning the `Deserializer` function into a class and is not nearly as much code to override these as the functions above) If this sounds acceptable, I will submit a patch. EmadMokhtar levic   0 1 1 1 0 0
29717 2018-08-28 09:49:35 2018-08-30 00:53:06 2022-03-06 04:51:58.430478 Accepted new Database layer (models, ORM) New feature Normal 2.1   Provide a way for tests to run on an existing empty DB Periodically users ask in IRC for help running tests when the user they connect as can not create a DB. The reasons for this situation tend to be their DBA won't allow it, or their corporate policy doesn't permit it. Regardless, Django fails because when not using keepdb, it attempts to create the db _always_, and only catches "duplicate DB name" errors to indicate it already exists. However, Postgres checks for CREATE DB permissions _before_ checking if the DB exists, so Django sees it as a generic "DB creation problem" and bails. If we, instead, used the existing function [used by the keepdb logic] to test if the DB exists, we could smooth the path for users in the above situation. I've started a patch which is currently _very_ wrong, and is awaiting feedback as requested on the django-dev mailing list. https://github.com/django/django/pull/10349 nobody funkybob   0 1 1 1 1 0
29843 2018-10-12 09:16:07 2021-10-08 07:06:40 2022-03-06 04:52:19.118509 Accepted assigned contrib.auth Cleanup/optimization Normal dev   Create permissions using migration operations rather than using the post_migrate signal We have encountered this problem when deploying our app to a new database. The easiest way to demonstrate the problem is with this repository: https://github.com/PetterS/django-demo-app First clone the repo and execute {{{ pipenv install }}} Then in a clean repository: {{{ $ python manage.py migrate auth $ python manage.py migrate myapp }}} This fails with "django.contrib.auth.models.DoesNotExist: Permission matching query does not exist." Indeed, I can verify that the sqlite database does not contain any custom permissions. But showmigrations tells me that "0001_initial" and "0002_auto_20181012_1052" have been applied! {{{ $ python manage.py showmigrations ... myapp [X] 0001_initial [X] 0002_auto_20181012_1052 [ ] 0003_auto_20181012_1054 }}} On the other hand, in a clean repository the following succeeds: {{{ $ python manage.py migrate auth $ python manage.py migrate myapp 0001_initial $ python manage.py migrate myapp 0002_auto_20181012_1052 $ python manage.py migrate myapp 0003_auto_20181012_1054 $ python manage.py migrate myapp }}} So the result of the migrations adding the permission is not visible until after the migrate command finished, even if there are other migrations coming after. In a clean repository: {{{ $ python manage.py migrate auth $ python manage.py migrate myapp 0001_initial }}} "can_smell" is now a permission in the DB. I think this bug is pretty severe, since running migrate on a new DB will put the database in a state that is not very easy to recover from. The migrations show as applied, when in fact the permissions have not been created. arthurio PetterS contenttypes permissions post_migrate 0 1 1 1 1 0
30416 2019-04-27 09:56:25 2021-03-31 12:22:32 2022-03-06 04:53:54.097194 Accepted assigned Core (Management commands) Bug Normal 2.2   Runserver's reloading mechanism should restore terminal state completely Currently it only ensures that echo is on, but not that e.g. Ctrl-C works etc. This can be triggered when using pdb++, which uses pyrepl itself: it puts the terminal into raw state. If the reloader then kicks in while at the prompt this will not be restored (except for echo). Related issue, which mentions that a better mechanism would be good: https://code.djangoproject.com/ticket/15880 btw: pyrepl has no chance to restore itself: listening to SIGTERM is not possible in threads apparently, and e.g. `atexit` is also not triggered there. blueyed blueyed   0 1 0 1 0 0
30448 2019-05-06 03:18:15 2020-10-25 22:37:42 2022-03-06 04:53:58.928617 Accepted assigned Database layer (models, ORM) Bug Normal 2.2   close_if_unusable_or_obsolete should skip connections in atomic block for autocommit check Via https://github.com/django/channels/issues/1091#issuecomment-489488831 I have noticed that `close_if_unusable_or_obsolete` will close the DB connection used in tests, which has entered an atomic block (via `TestCase`). channel's `DatabaseSyncToAsync` calls `close_if_unusable_or_obsolete` here. The following patch might make sense: {{{ diff --git c/django/db/backends/base/base.py i/django/db/backends/base/base.py index 9fa03cc0ee..f9ca0f8464 100644 --- c/django/db/backends/base/base.py +++ i/django/db/backends/base/base.py @@ -497,7 +497,10 @@ def close_if_unusable_or_obsolete(self): if self.connection is not None: # If the application didn't restore the original autocommit setting, # don't take chances, drop the connection. - if self.get_autocommit() != self.settings_dict['AUTOCOMMIT']: + if ( + not self.in_atomic_block and + self.get_autocommit() != self.settings_dict["AUTOCOMMIT"] + ): self.close() return }}} blueyed blueyed   0 1 0 1 0 0
30581 2019-06-20 09:14:51 2021-07-12 11:32:58 2022-03-06 04:54:18.980317 Accepted assigned Database layer (models, ORM) New feature Normal 4.0   Allow constraints to be used for validation (in Python) Follow-up from #30547, where we documented how database constraints relate to validation. **Executive summary**: In general they don't. Instead you get an `IntegrityError` on `save()`. Except, `UniqueConstraint` is able to tie-in to the existing `validate_unique()` logic, so you will get a `ValidationError` on `full_clean()`. It would be **nice** if all constraints could (in principle) be used for Python-level validation, in addition to setting up the database constraint. (We might image `ModelForm`, say, being able to extract correct validation logic from the model definition, and so on.) Initial thought is that Python validators could be inferred from `Q` objects: {{{ CheckConstraint(check=Q(age__gte=18), name='age_gte_18') }}} Looks like it maps to a simple `lambda age: age > 18`, for example. More complex examples will cause issues. Discussion: * [https://github.com/django/django/pull/10796#discussion_r244216763 PR #10796 (comment)] * [https://github.com/django/django/pull/388#issuecomment-8863209 PR #388 (comment)] So we **might** be able to do **some** auto-generation but first goal here should (I guess) be an optional hook on `BaseConstraint` that **if implemented** can be picked up for use in validation. (Or similar.) I'll create this as Accepted, since existing discussions imply that. Gagaro carltongibson constraints, validation 0 1 1 1 1 0
31908 2020-08-19 15:37:47 2020-09-07 10:06:26 2022-03-06 04:57:49.802634 Accepted assigned Testing framework New feature Normal dev   Add parallel testing support to Oracle backend This was part of the original parallel test runner ticket that Aymeric Augustin worked on. It still remains a nice feature to have. Ahmad A. Hussein lothemar oracle, parallel, tests 0 1 1 1 1 0
32234 2020-12-01 05:46:15 2021-12-06 02:47:12 2022-03-06 04:58:39.718679 Accepted assigned Core (Management commands) Cleanup/optimization Normal 3.1   inspectdb should inform about composite keys. Since django does not support multiple multiple-column primary keys, there should be a warning that the inspectdb result does not match exactly the database [https://github.com/django/django/pull/13736 PR] mdamien mdamien   0 1 1 1 0 0
32797 2021-05-30 00:49:06 2021-08-27 00:37:47 2022-03-06 05:00:03.211861 Accepted new contrib.admin Bug Normal 3.2   model_ngettext incorrectly tries to translate already translated words `model_ngettext()` util function doesn't handle `gettext_lazy` objects as model's `verbose_name` and `verbose_name_plural`. `translation`'s module `ngettext()` function is intended to be called with not translated source strings, whereas `model_ngettext()` puts `verbose_name` and `verbose_name_plural`, which may be a `gettext_lazy` objects, as its arguments. Effectively it makes Django not use correct plural translations for verbose name for any language that has other plural rules then English for phrases * `Successfully deleted %(count)d %(items)s.` * and `%(count)s %(name)s were changed successfully.` in admin panel (they use `model_ngettext` function to render `items` and `name` respectively). Following test: {{{ Index: tests/admin_utils/tests.py IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== diff --git a/tests/admin_utils/tests.py b/tests/admin_utils/tests.py --- a/tests/admin_utils/tests.py (revision d270dd584e0af12fe6229fb712d0704c232dc7e5) +++ b/tests/admin_utils/tests.py (date 1622333679821) @@ -1,5 +1,6 @@ from datetime import datetime from decimal import Decimal +from unittest.mock import patch from django import forms from django.conf import settings @@ -8,7 +9,7 @@ from django.contrib.admin.utils import ( NestedObjects, display_for_field, display_for_value, flatten, flatten_fieldsets, help_text_for_field, label_for_field, lookup_field, - quote, + quote, model_ngettext, ) from django.db import DEFAULT_DB_ALIAS, models from django.test import SimpleTestCase, TestCase, override_settings @@ -16,7 +17,7 @@ from django.utils.safestring import mark_safe from .models import ( - Article, Car, Count, Event, EventGuide, Location, Site, Vehicle, + Article, Car, Count, Event, EventGuide, Location, Site, Vehicle, Foo, ) @@ -410,3 +411,9 @@ def test_quote(self): self.assertEqual(quote('something\nor\…   m-aciek i18n, gettext, ngettext 0 1 1 1 0 1
32798 2021-05-31 11:41:18 2021-10-07 12:03:00 2022-03-06 05:00:03.361104 Accepted assigned HTTP handling Bug Normal 3.2   StreamingHttpResponse raises SynchronousOnlyOperation in ASGI server When using a ASGI-compliant server, such as Daphne, StreamingHttpResponse's iterator will be executed in an asynchronous context, preventing database queries from being performed (raising SynchronousOnlyOperation). This is not expected behaviour, and appears not to be documented. *Steps to reproduce* 1. Create a simple project and app. Set-up for use with Channels. We are not going to use this component and the bug does seem to originate from Django itself, but Channels ensures that runserver is ASGI-compliant. 2. Create the following view: {{{ from django.contrib.contenttypes.models import ContentType from django.http import StreamingHttpResponse def test_view(request): def generate(): yield "hello\n" list(ContentType.objects.all()) yield "bye\n" return StreamingHttpResponse(generate(), content_type="text/plain") }}} 3. Open the page served by test_view 4. Observe the following trace: {{{ Exception inside application: You cannot call this from an async context - use a thread or sync_to_async. Traceback (most recent call last): File "venv/lib/python3.8/site-packages/channels/staticfiles.py", line 44, in __call__ return await self.application(scope, receive, send) File "venv/lib/python3.8/site-packages/channels/routing.py", line 71, in __call__ return await application(scope, receive, send) File "venv/lib/python3.8/site-packages/django/core/handlers/asgi.py", line 168, in __call__ await self.send_response(response, send) File "venv/lib/python3.8/site-packages/django/core/handlers/asgi.py", line 242, in send_response for part in response: File "channelstest/testapp/views.py", line 9, in generate list(ContentType.objects.all()) File "venv/lib/python3.8/site-packages/django/db/models/query.py", line 287, in __iter__ self._fetch_all() File "venv/lib/python3.8/site-packages/django/db/models/query.py", line 1303, in _fetch_all self._result_cache = list(self._iterable_class(self)) File "venv/lib/python3.… mbrown1413 ralphje ASGI, async 0 1 0 1 0 0
32915 2021-07-10 14:09:22 2022-02-02 06:43:25 2022-03-06 05:00:21.846999 Accepted assigned Core (Management commands) Bug Normal 3.2   ./manage runserver --nostatic still doesn't return a traceback Maybe its regression, related to: https://code.djangoproject.com/ticket/27522: {{{ > python manage.py runserver --nostatic usage: manage.py runserver [-h] [--ipv6] [--nothreading] [--noreload] [--version] [-v {0,1,2,3}] [--settings SETTINGS] [--pythonpath PYTHONPATH] [--traceback] [--no-color] [--force-color] [addrport] manage.py runserver: error: unrecognized arguments: --nostatic }}} {{{ > python manage.py runserver python manage.py runserver Traceback (most recent call last): File "/home/michael/venv/project/lib/python3.8/site-packages/django/core/management/base.py", line 354, in run_from_argv self.execute(*args, **cmd_options) File "/home/michael/venv/project/lib/python3.8/site-packages/django/core/management/commands/runserver.py", line 61, in execute super().execute(*args, **options) File "/home/michael/venv/project/lib/python3.8/site-packages/django/core/management/base.py", line 398, in execute output = self.handle(*args, **options) File "/home/michael/venv/project/lib/python3.8/site-packages/django/core/management/commands/runserver.py", line 68, in handle if not settings.DEBUG and not settings.ALLOWED_HOSTS: File "/home/michael/venv/project/lib/python3.8/site-packages/django/conf/__init__.py", line 82, in __getattr__ self._setup(name) File "/home/michael/venv/project/lib/python3.8/site-packages/django/conf/__init__.py", line 69, in _setup self._wrapped = Settings(settings_module) File "/home/michael/venv/project/lib/python3.8/site-packages/django/conf/__init__.py", line 170, in __init__ mod = importlib.import_module(self.SETTINGS_MODULE) File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1014, in _gcd_import File "<frozen importlib._bootstrap>", line 991, in _find_and_load File "<frozen importlib._bootstrap>", line 973, in _find_and_load… rohithpr mangelozzi   0 1 1 1 0 0
32948 2021-07-20 10:35:46 2021-12-10 07:03:50 2022-03-06 05:00:26.688776 Accepted assigned Database layer (models, ORM) Cleanup/optimization Normal dev   Optimise Q combination and inversion This is corollary to #32946 and #32940. Q is currently inconsistent with it's friends `WhereNode` and `Node` in that it doesn't use the `_new_instance` trick. Even using the `_new_instance` trick leaves some performance on the table vs just inlining the `__class__` switch, because it's an extra method call which affects both `_combine()` and `__invert__()`. The `_combine` method also has conditionals for what to do about an ''empty'' node being combined, either lhs or rhs. One side uses `deconstruct`, the other uses the shallow copy protocol (only since c8b659430556dca0b2fe27cf2ea0f8290dbafecd), which is unimplemented. If `__copy__` is not implemented, it ultimately falls back (after some branching checks) to the builtin `__reduce_ex__(4)` + `copy._reconstruct` which gives: {{{ In [3]: x = Q() In [4]: %timeit copy.copy(x) 2.2 µs ± 70.9 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each) In [5]: %timeit copy.copy(Q()) 3.52 µs ± 264 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each) }}} If we implement the necessary method like so: {{{ def __copy__(self): obj = self._new_instance() obj.__dict__ = self.__dict__.copy() return obj }}} we can reduce those numbers to: {{{ In [3]: x = Q() In [4]: %timeit copy.copy(x) 1.27 µs ± 6.19 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each) In [5]: %timeit copy.copy(Q()) 2.37 µs ± 28.7 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each) }}} we can then reduce the work further by not invoking `copy.copy()` at all, by setting the `copy = __copy__` attribute on the Q class. From there, we can avoid calling `self.deconstruct()` at all, instead calling `self.copy()` knowing that `self` has values, but `other` does not. Both are basically on-par with eachother speedwise, with deconstruct being faster on empty nodes (which `self` isn't) and copy being minimally faster when there's a different connector (eg: `OR`). For inverting, we can similarly change it to avoid the `Node.add()` call: {{{ de… ngnpope kezabelle   0 1 0 1 0 0
32969 2021-07-28 18:44:54 2021-09-06 08:52:16 2022-03-06 05:00:29.721324 Accepted assigned HTTP handling Bug Normal dev   Improve pickling of HttpResponse instances When pickling a HTTPResponse, rather than pickling all of its attributes just store what is needed for the creation of a new HttpResponse with the correct content, status code and headers. See related discussion on ticket #23895 and its PR. tigicion zatro   0 1 1 1 0 0
33450 2022-01-19 15:27:44 2022-02-11 07:06:20 2022-03-06 05:01:42.975492 Accepted assigned Database layer (models, ORM) Bug Normal 4.0   Integer primary key is wrongly casted to UUID when filtering GenericRelation on model with UUID primary key. Hi, at Read the Docs we have migrated from Django 2.2 to 3.2, and we encountered the following problem. In a model that makes use of a GenericForeignKey field, and it has a UUID field as its pk will result in Django casting the ID of the related model as UUID in some queries (the related model makes use of the default BigAutoField). I was able to reproduce this with the following models and using postgres as the DB backend. {{{#!python from django.db import models from django.contrib.contenttypes.models import ContentType from django.contrib.contenttypes.fields import ( GenericForeignKey, GenericRelation, ) import uuid class TTag(models.Model): id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False) content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE) object_id = models.PositiveIntegerField() content = GenericForeignKey() class TIntegration(models.Model): tags = GenericRelation(TTag, related_query_name='integration') }}} The problematic queries: {{{#!python integration = TIntegration.objects.create() tag = integration.tags.create() r = TTag.objects.filter(integration=integration) print(r.query) # The next error is raised if the query is evaluated # psycopg2.errors.UndefinedFunction: operator does not exist: bigint = uuid }}} The query will result in the following SQL {{{#!sql SELECT "core_ttag"."id", "core_ttag"."content_type_id", "core_ttag"."object_id" FROM "core_ttag" INNER JOIN "core_tintegration" ON ("core_ttag"."object_id" = "core_tintegration"."id" AND ("core_ttag"."content_type_id" = 7)) WHERE "core_tintegration"."id" = 00000000-0000-0000-0000-000000000001 }}} Note as `core_tintegration"."id"` is being casted as an UUID when it should be an integer (1). I was able to bisect the error to this commit https://github.com/django/django/commit/1afbc96a75bd1765a56054f57ea2d4b238af3f4d. Before that commit, the generated SQL is as follows: {{{#!sql SELECT "core_ttag"."id", "cor… jdboisvert stsewd   0 1 1 1 0 0
33509 2022-02-10 18:43:59 2022-02-11 05:13:56 2022-03-06 05:01:52.508772 Accepted assigned Migrations Cleanup/optimization Normal dev   Add SQL comment to describe deliberately no-op migration operations Currently when a field migration is a no-op, the operation description is output in SQL, but nothing else. This can be confusing as to which operations are no-ops. It could be clearer if we output an extra SQL comment when there are deliberately no statements to execute for a given migration operation. Take for example this output: {{{ BEGIN; -- -- Alter field name on Author -- ALTER ...; -- -- Alter field title on Book -- COMMIT; }}} The `Author.name` field has an operation applied, whilst `Book.title` needs no changes to the database. This isn't exactly clear from the output - is the `COMMIT` part of the `Book.title` change? It could be clearer as: {{{ BEGIN; -- -- Alter field name on Author -- ALTER ...; -- -- Alter field name on Author -- -- (no-op) COMMIT; }}} (Or perhaps more verbose wording, like "no SQL to execute") I think this can help especially when there are consecutive operations with no-op SQL: {{{ BEGIN; -- -- Alter field name on Author -- -- (no-op) -- -- Alter field name on Author -- -- (no-op) COMMIT; }}} (Inspired by #33470, where the OP suggested dropping such migration operation header comments.) adamchainz adamchainz   0 1 0 1 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
    );