Django: Ticket Queryhttps://code.djangoproject.com/query?status=assigned&status=new&order=status
The Web framework for perfectionists with deadlines.en-USDjangohttps://www.djangoproject.com/s/img/site/hdr_logo.gifhttps://code.djangoproject.com/query?status=assigned&status=new&order=status
Trac 1.2https://code.djangoproject.com/ticket/373
https://code.djangoproject.com/ticket/373#373: Add support for multiple-column primary keysFri, 19 Aug 2005 18:15:29 GMTJacob<p>
In the interest of being able to use Django as an admin interface for <em>any</em> db schema, it really should support multiple column primary keys.
</p>
<p>
Currently, you can "fake" it by declaring one of the keys to be primary in Django and adding a unique constraint to the model. You'd have to do without the auto-generated SQL that Django gives you, but if you're smart enough to know how and why to use multiple primary keys, you can probably write the schema by hand. Still, this is less than ideal.
</p>
<p>
This is likely to be very difficult.
</p>
Resultshttps://code.djangoproject.com/ticket/373#changeloghttps://code.djangoproject.com/ticket/1891
https://code.djangoproject.com/ticket/1891#1891: ForeignKey with m2m filter can duplicate foreign model entries in ModelForm/ModelChoiceFieldTue, 16 May 2006 10:41:36 GMTmattimustang@…<p>
My app has the following models similar to:
</p>
<div class="wiki-code"><div class="code"><pre>
PROXY_GROUPS <span class="o">=</span> <span class="p">(</span><span class="s1">'Terminal Server'</span><span class="p">,</span> <span class="s1">'Socks Proxy'</span><span class="p">,</span> <span class="s1">'Web Proxy'</span><span class="p">)</span>
<span class="k">class</span> <span class="nc">Group</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
name <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>maxlength<span class="o">=</span><span class="mi">32</span><span class="p">)</span>
<span class="k">class</span> <span class="nc">Asset</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
name <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>maxlength<span class="o">=</span><span class="mi">32</span><span class="p">)</span>
groups <span class="o">=</span> models<span class="o">.</span>ManyToManyField<span class="p">(</span>Group<span class="p">)</span>
<span class="k">class</span> <span class="nc">Proxy</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
asset <span class="o">=</span> models<span class="o">.</span>ForeignKey<span class="p">(</span>Asset<span class="p">,</span> limit_choices_to<span class="o">=</span><span class="p">{</span><span class="s1">'groups__name__in'</span><span class="p">:</span> PROXY_GROUPS<span class="p">,</span> <span class="s1">'distinct'</span><span class="p">:</span><span class="bp">True</span><span class="p">})</span>
port <span class="o">=</span> models<span class="o">.</span>PositiveIntegerField<span class="p">()</span>
</pre></div></div><p>
Which spews an error when I try to add a Proxy object in the admin. The error is something to do with 'distinct' not being a valid field (Sorry i can post the exact error later).
</p>
<p>
How can I achieve the equivalent to this in the current post-mr trunk?
</p>
<p>
From #django earlier today:
</p>
<pre class="wiki">malcolmt mattimustang_: I think you've found a bug. You're right, distinct has become a method on QuerySets, not a filter parameter now. So you may be temporarily stuck. Can you file a ticket so we don't forget to fix this somehow, please?
</pre>Resultshttps://code.djangoproject.com/ticket/1891#changeloghttps://code.djangoproject.com/ticket/3461
https://code.djangoproject.com/ticket/3461#3461: DatabaseWrapper should pass through args and kwargs to underlying database adapterThu, 08 Feb 2007 20:38:52 GMTJack Moffitt <metajack@…><p>
Currently the DatabaseWrapper (at least for the postgresql_psycopg2end) does not pass args and kwargs for cursor() calls to the underlying database adapter. This makes it impossible to use the adapter fully at the low level. For example, to use dict cursors in psycopg2 you have to pass a different cursor factory via the cursor_factory keyword argument to cursor(). The attached patch passes through args and kwargs for cursor() calls.
</p>
Resultshttps://code.djangoproject.com/ticket/3461#changeloghttps://code.djangoproject.com/ticket/4282
https://code.djangoproject.com/ticket/4282#4282: startproject should honor umaskSat, 12 May 2007 12:39:41 GMTtalex5+django@…<p>
Ticket <a class="closed ticket" href="https://code.djangoproject.com/ticket/1651" title="#1651: defect: [patch] django-admin.py should copy permissions of project_template files (closed: fixed)">#1651</a> fixed the problem of manage.py not being made executable by copying *all* the permission bits (not just the executable flags). This means that the user's umask doesn't work, e.g.:
</p>
<pre class="wiki">$ umask 077
$ touch foo
$ ls -l foo
-rw------- 1 talex talex 0 2007-05-12 13:27 foo
$ PYTHONPATH=trunk ./trunk/django/bin/django-admin.py startproject mysite
$ ls -l mysite/settings.py
-rw-r--r-- 1 talex talex 2804 2007-05-12 13:28 mysite/settings.py
</pre><p>
I discovered this whilst trying to make a Zero Install package for Django. Everything in the Zero Install cache is read-only, so startproject fails with:
</p>
<pre class="wiki"> File "/var/cache/0install.net/implementations/sha1new=262c95b5a7cc34f525408b675106e4e4ae3494cc/django/core/management.py", line 799, in startproject
fp = open(main_settings_file, 'w')
IOError: [Errno 13] Permission denied: '.../site/settings.py'
</pre><p>
Thanks,
</p>
Resultshttps://code.djangoproject.com/ticket/4282#changeloghttps://code.djangoproject.com/ticket/5711
https://code.djangoproject.com/ticket/5711#5711: Allow non-field attributes to be serializedTue, 09 Oct 2007 04:08:46 GMTvalankar@…<p>
It seems if I create a request set with extra(), the fields are not in the output generated by serialize().
</p>
Resultshttps://code.djangoproject.com/ticket/5711#changeloghttps://code.djangoproject.com/ticket/5899
https://code.djangoproject.com/ticket/5899#5899: Allow admin fieldsets to be collapsible but not initially collapsedThu, 08 Nov 2007 14:08:08 GMTIonut Ciocirlan <ionut.ciocirlan@…><p>
I want to use the collapse feature of the admin, but not have the field initially collapsed, so I made this little patch.
</p>
<p>
It adds a "collapsible" class that does just that. It also patches the documentation.
</p>
Resultshttps://code.djangoproject.com/ticket/5899#changeloghttps://code.djangoproject.com/ticket/6363
https://code.djangoproject.com/ticket/6363#6363: Login page is redisplayed without any message if AdminSite.has_permission() returns FalseFri, 11 Jan 2008 19:15:42 GMTMichel Sabchuk<p>
I found a bug when using the has_permission method of the AdminSite class to filter which users can access the admin page:
</p>
<pre class="wiki">class SuperuserAdminSite(admin.AdminSite):
def has_permission(self, request):
return super(SuperuserAdminSite, self).has_permission(request) and request.user.is_superuser
admin_site = SuperuserAdminSite()
</pre><p>
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?
</p>
Resultshttps://code.djangoproject.com/ticket/6363#changeloghttps://code.djangoproject.com/ticket/6376
https://code.djangoproject.com/ticket/6376#6376: Please don't force the usage of the 'django' gettext domainMon, 14 Jan 2008 13:59:11 GMTdennis@…<p>
I'm using django as a library in my non-web-based application. As such I prefer not to use the 'django' gettext domain but my own. I currently work around it with some symlinking trickery since being compatible with upstream django is more important than not having workarounds, but it would be great if django supported this. To illustrate what I mean, I've attached a simple and untested patch against current svn (rev 7020).
</p>
Resultshttps://code.djangoproject.com/ticket/6376#changeloghttps://code.djangoproject.com/ticket/7556
https://code.djangoproject.com/ticket/7556#7556: inspectdb fails in MySql if a table references a table outside the current schemaFri, 27 Jun 2008 15:32:35 GMTbrockweaver<p>
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 <code>schema1</code>:
</p>
<pre class="wiki">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`)
)
</pre><p>
For this situation, inspectdb will return something similar to this:
</p>
<pre class="wiki">_mysql_exceptions.ProgrammingError: (1146, "Table 'schema1.site' doesn't exist")
</pre><p>
So it tries to use <code>schema1.site</code> as the table to introspect instead of the appropriate <code>schema2</code>.<code>site</code> 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.
</p>
Resultshttps://code.djangoproject.com/ticket/7556#changeloghttps://code.djangoproject.com/ticket/8472
https://code.djangoproject.com/ticket/8472#8472: Add "Recent Actions" panel to app_index templateThu, 21 Aug 2008 15:58:44 GMTJulia<p>
This was a feature request and relates to the changeset in <a class="ext-link" href="http://code.djangoproject.com/ticket/1390"><span class="icon">​</span>#1390</a>. The goal is to produce specified results for the Recent Actions panel (sidebar) to only display logged actions for that particular model. For example, at Home &gt; Auth would only display logged actions for the apps pertaining to that model (e.g. User, Groups).
</p>
Resultshttps://code.djangoproject.com/ticket/8472#changeloghttps://code.djangoproject.com/ticket/8851
https://code.djangoproject.com/ticket/8851#8851: Add a default option to list_filter in the admin interfaceWed, 03 Sep 2008 18:18:29 GMTRiskable <riskable@…><p>
There should be a way to set a default list_filter in the admin interface. For example, if I had a model like this:
</p>
<div class="wiki-code"><div class="code"><pre>DECOM_CHOICES <span class="o">=</span> <span class="p">(</span>
<span class="p">(</span><span class="s1">'N'</span><span class="p">,</span> <span class="s1">'No'</span><span class="p">),</span>
<span class="p">(</span><span class="s1">'Y'</span><span class="p">,</span> <span class="s1">'Yes'</span><span class="p">),</span>
<span class="p">)</span>
<span class="k">class</span> <span class="nc">Host</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
hostname <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>max_length<span class="o">=</span><span class="mi">36</span><span class="p">,</span> unique<span class="o">=</span><span class="bp">True</span><span class="p">)</span>
decommissioned <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>max_length<span class="o">=</span><span class="mi">1</span><span class="p">,</span> choices<span class="o">=</span>DECOM_CHOICES<span class="p">,</span> default<span class="o">=</span><span class="s1">'N'</span><span class="p">)</span>
ip_address <span class="o">=</span> models<span class="o">.</span>IPAddressField<span class="p">()</span>
<span class="k">def</span> <span class="nf">__unicode__</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="k">return</span> <span class="bp">self</span><span class="o">.</span>hostname
<span class="k">class</span> <span class="nc">HostAdmin</span><span class="p">(</span>admin<span class="o">.</span>ModelAdmin<span class="p">):</span>
fieldsets <span class="o">=</span> <span class="p">[</span>
<span class="p">(</span><span class="s1">'Host Info'</span><span class="p">,</span> <span class="p">{</span><span class="s1">'fields'</span><span class="p">:</span> <span class="p">[</span><span class="s1">'hostname'</span><span class="p">,</span><span class="s1">'decommissioned'</span><span class="p">,</span><span class="s1">'ip_address'</span><span class="p">]}),</span>
list_display <span class="o">=</span> <span class="p">(</span><span class="s1">'hostname'</span><span class="p">,</span> <span class="s1">'ip_address'</span><span class="p">,</span> <span class="s1">'decommissioned'</span><span class="p">)</span>
list_filter <span class="o">=</span> <span class="p">(</span><span class="s1">'decommissioned'</span><span class="p">)</span>
admin<span class="o">.</span>site<span class="o">.</span>register<span class="p">(</span>Host<span class="p">,</span> HostAdmin<span class="p">)</span>
</pre></div></div><p>
I might want to make it so that by default only hosts that are not marked as decommissioned are displayed by default in the index. It would be nice if I could just pass an option to list_filter to set the a filter that is enabled by default. Perhaps something like this:
</p>
<div class="wiki-code"><div class="code"><pre>list_filter <span class="o">=</span> <span class="p">(</span><span class="s1">'decommissioned__exact=N'</span><span class="p">)</span> <span class="c1"># Matches the URL if you click on "No" in the filter list</span>
</pre></div></div><p>
...or perhaps...
</p>
<div class="wiki-code"><div class="code"><pre>list_filter <span class="o">=</span> <span class="p">(</span><span class="s1">'decommissioned__default'</span><span class="p">)</span> <span class="c1"># Have it choose the same default as specified in the model.</span>
</pre></div></div><p>
If there's already a simple way to do this I haven't found it and would appreciate an example.
</p>
<p>
Thanks!
</p>
Resultshttps://code.djangoproject.com/ticket/8851#changeloghttps://code.djangoproject.com/ticket/8936
https://code.djangoproject.com/ticket/8936#8936: Add view (read-only) permission to adminMon, 08 Sep 2008 01:10:41 GMTsimon<p>
Adrian and Jacob on stage at <a class="wiki" href="https://code.djangoproject.com/wiki/DjangoCon">DjangoCon</a>.
</p>
Resultshttps://code.djangoproject.com/ticket/8936#changeloghttps://code.djangoproject.com/ticket/8972
https://code.djangoproject.com/ticket/8972#8972: Add ability to delete selected vector features within the Geodjango/OpenLayers Admin map interfaceMon, 08 Sep 2008 17:35:43 GMTspringmeyer<p>
This feature has been needed for some time, and was recently requested. See: <a class="ext-link" href="http://groups.google.com/group/django-users/browse_thread/thread/36242edfd0d0281c?hl=en"><span class="icon">​</span>http://groups.google.com/group/django-users/browse_thread/thread/36242edfd0d0281c?hl=en</a>
</p>
<p>
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.
</p>
<p>
I've tested this so far when editing multipolygon data in the admin.
</p>
<p>
A known issue I'm hoping others may have a solution to:
</p>
<p>
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:
</p>
<pre class="wiki">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]);}
</pre>Resultshttps://code.djangoproject.com/ticket/8972#changeloghttps://code.djangoproject.com/ticket/9061
https://code.djangoproject.com/ticket/9061#9061: formsets with can_delete=True shouldn't add delete field to extra formsFri, 12 Sep 2008 18:47:59 GMTGabriel Farrell<p>
Current behavior of formsets with can_delete=True is to add a delete field to every form. This behavior differs from that expected, however (why would one want a delete option on an "add" form?), as well as that of the builtin admin. I've included a patch on formsets.py, but haven't bothered with patching tests yet.
</p>
Resultshttps://code.djangoproject.com/ticket/9061#changeloghttps://code.djangoproject.com/ticket/9249
https://code.djangoproject.com/ticket/9249#9249: Google Analytics' Cookies break CacheMiddleware when SessionMiddleware turns on Vary: CookieTue, 30 Sep 2008 02:55:17 GMTpixelcort<p>
When using Google Analytics on a Django project with CacheMiddleware and SessionMiddleware turned on, the Cookies that Google Analytics apparently change on each reload, invalidating the Vary: Cookie parameter that SessionMiddleware is setting.
</p>
<p>
There should be a way to define cookie prefixes, such as <code></code>'<span class="underline">utm'<code></code>, to ignore for cookie variation for caching.
</span></p>
Resultshttps://code.djangoproject.com/ticket/9249#changeloghttps://code.djangoproject.com/ticket/9373
https://code.djangoproject.com/ticket/9373#9373: "This field is required" error even on empty inlines formsets in the admin model page, when hiding a choice field of a custom form.Wed, 15 Oct 2008 20:41:25 GMTtyrion.mx@…<p>
I have a custom Form for one of my models (in the example SecondModel) that adds one choice field with an initial value.
If I use that model/form as an inline formset and I exclude the extra field using the "fields" attribute of the ModelAdmin, I got "This Field is required" on all the forms of the formset, including those who where left blank. Here a simple example:
</p>
<div class="wiki-code"><div class="code"><pre><span class="c1"># models.py</span>
<span class="kn">from</span> <span class="nn">django.db</span> <span class="kn">import</span> models
<span class="k">class</span> <span class="nc">FirstModel</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
a <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>max_length<span class="o">=</span><span class="mi">10</span><span class="p">)</span>
b <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>max_length<span class="o">=</span><span class="mi">10</span><span class="p">)</span>
<span class="k">class</span> <span class="nc">SecondModel</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
link <span class="o">=</span> models<span class="o">.</span>ForeignKey<span class="p">(</span>FirstModel<span class="p">)</span>
c <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>max_length<span class="o">=</span><span class="mi">10</span><span class="p">)</span>
<span class="c1"># admin.py</span>
<span class="kn">from</span> <span class="nn">django.contrib</span> <span class="kn">import</span> admin
<span class="kn">from</span> <span class="nn">bug.bugged</span> <span class="kn">import</span> models<span class="p">,</span> forms
<span class="k">class</span> <span class="nc">SecondAdmin</span><span class="p">(</span>admin<span class="o">.</span>TabularInline<span class="p">):</span>
model <span class="o">=</span> models<span class="o">.</span>SecondModel
form <span class="o">=</span> forms<span class="o">.</span>SecondForm
fields <span class="o">=</span> <span class="p">[</span><span class="s1">'c'</span><span class="p">]</span>
extra <span class="o">=</span> <span class="mi">3</span>
<span class="k">class</span> <span class="nc">FirstAdmin</span><span class="p">(</span>admin<span class="o">.</span>ModelAdmin<span class="p">):</span>
inlines <span class="o">=</span> <span class="p">[</span>SecondAdmin<span class="p">]</span>
admin<span class="o">.</span>site<span class="o">.</span>register<span class="p">(</span>models<span class="o">.</span>FirstModel<span class="p">,</span> FirstAdmin<span class="p">)</span>
<span class="c1"># forms.py</span>
<span class="kn">from</span> <span class="nn">django</span> <span class="kn">import</span> forms
<span class="kn">from</span> <span class="nn">bug.bugged</span> <span class="kn">import</span> models
DUMMY_CHOICES <span class="o">=</span> <span class="p">(</span>
<span class="p">(</span><span class="mi">0</span><span class="p">,</span> <span class="s1">'a'</span><span class="p">),</span>
<span class="p">(</span><span class="mi">1</span><span class="p">,</span> <span class="s1">'b'</span><span class="p">),</span>
<span class="p">(</span><span class="mi">2</span><span class="p">,</span> <span class="s1">'c'</span><span class="p">)</span>
<span class="p">)</span>
<span class="k">class</span> <span class="nc">SecondForm</span><span class="p">(</span>forms<span class="o">.</span>ModelForm<span class="p">):</span>
d <span class="o">=</span> forms<span class="o">.</span>IntegerField<span class="p">(</span>label<span class="o">=</span><span class="s1">'d'</span><span class="p">,</span> initial<span class="o">=</span><span class="mi">0</span><span class="p">,</span> widget<span class="o">=</span>forms<span class="o">.</span>Select<span class="p">(</span>choices<span class="o">=</span>DUMMY_CHOICES<span class="p">))</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
model <span class="o">=</span> models<span class="o">.</span>SecondModel
</pre></div></div><p>
The problem is <code>fields = ['c']</code>, commenting out that line I get no errors.
I guess, this is beacuse of the <code>has_changed</code> check, called by the <code>full_clean</code> method of <code>forms.Form</code>. It happens that <code>changed_data</code> compares the initial "d" value that had been set to 0 with the result of "field.widget.value_from_datadict(self.data,..." that is None because we have not a key for "d" in self.data. So changed_data will contain "d" even if the form has not been changed.
</p>
<p>
From django/forms/forms.py
</p>
<div class="wiki-code"><div class="code"><pre> prefixed_name <span class="o">=</span> <span class="bp">self</span><span class="o">.</span>add_prefix<span class="p">(</span>name<span class="p">)</span>
data_value <span class="o">=</span> field<span class="o">.</span>widget<span class="o">.</span>value_from_datadict<span class="p">(</span><span class="bp">self</span><span class="o">.</span>data<span class="p">,</span> <span class="bp">self</span><span class="o">.</span>files<span class="p">,</span> prefixed_name<span class="p">)</span>
<span class="k">if</span> <span class="ow">not</span> field<span class="o">.</span>show_hidden_initial<span class="p">:</span>
initial_value <span class="o">=</span> <span class="bp">self</span><span class="o">.</span>initial<span class="o">.</span>get<span class="p">(</span>name<span class="p">,</span> field<span class="o">.</span>initial<span class="p">)</span>
</pre></div></div>Resultshttps://code.djangoproject.com/ticket/9373#changeloghttps://code.djangoproject.com/ticket/9388
https://code.djangoproject.com/ticket/9388#9388: Year navigation in admin's date widgets' calendarFri, 17 Oct 2008 11:03:58 GMTFidel Ramos<p>
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.
</p>
<p>
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.
</p>
<p>
Javier de la Rosa will attach his patch later.
</p>
Resultshttps://code.djangoproject.com/ticket/9388#changeloghttps://code.djangoproject.com/ticket/9449
https://code.djangoproject.com/ticket/9449#9449: test runner repeatedly parsers fixturesSat, 25 Oct 2008 19:27:37 GMTTrevor Caira<p>
The django test runner calls loaddata for every test case which has fixtures. In projects which reuse the same fixtures for multiple test cases, running the test suite results in the wasteful repeated parsing of the same test fixtures, which is very slow. For my application, caching the result of fixture parsing results in an at least 7% speedup in the test suite.
</p>
Resultshttps://code.djangoproject.com/ticket/9449#changeloghttps://code.djangoproject.com/ticket/9602
https://code.djangoproject.com/ticket/9602#9602: Add admin.site._registry manipulation methodsFri, 14 Nov 2008 19:23:15 GMTRob Hudson<p>
This is a feature request...
</p>
<p>
Currently, one can unregister a model from the admin and register it again with a new ModelAdmin. The problem I'm anticipating is when 2 or more apps want to add ModelAdmin options to a Model and the last one wins.
</p>
<p>
Not to point out a specific 3rd party app, but this is an easily contrived example... If I have my own apps and one of them unregisters the User model's ModelAdmin and registers its own that, say, adds the <code>is_superuser</code> to the list_display. Then if I add the django-openid app that (currently) also unregisters the User model's ModelAdmin and registers its own that adds an inline to a ManyToManyField for the OpenID associations tied to that user. If django-openid is after my app in the INSTALLED_APPS list, I lose my list_display override. And if my app is after the django-openid app, I lose the OpenID associations inlines. (See: <a class="ext-link" href="http://code.google.com/p/django-openid/source/browse/trunk/django_openid/admin.py"><span class="icon">​</span>http://code.google.com/p/django-openid/source/browse/trunk/django_openid/admin.py</a>)
</p>
<p>
It's possible currently to write the unregistration/registration such that this doesn't happen, but it relies on pulling the ModelAdmin out of the "private" _registry dictionary in the admin.site class. For example:
</p>
<pre class="wiki">useradmin = admin.site._registry.get(User, None)
if useradmin:
useradmin.list_display = useradmin.list_display + ('is_superuser',)
else:
class MyUserAdmin(AuthUserAdmin):
list_display = ('username', 'email', 'first_name', 'last_name', 'is_staff', 'is_superuser')
admin.site.register(User, MyUserAdmin)
</pre><p>
I can think of a few ways of fixing this, from least involved to more involved:
</p>
<ol><li>At the very least I think it would be nice if the internal <code>_registry</code> dictionary didn't have the prepended underscore to signify that it is a private variable not to be touched, so one doesn't feel dirty doing something like this.
</li></ol><ol start="2"><li>I think it would be a bit cleaner if there were methods to lookup, get, and update this dict and keep it as a private dict. For example, something like <code>admin.site.get_model_admin(User)</code>?
</li></ol><ol start="3"><li>Along with 2, provide methods to update common ModelAdmin options, like <code>list_display</code>. This one is definitely venturing into debatable area, but something like <code>useradmin.list_display.add('is_superuser')</code> takes much away from this feeling so "monkey patchy".
</li></ol>Resultshttps://code.djangoproject.com/ticket/9602#changeloghttps://code.djangoproject.com/ticket/9739
https://code.djangoproject.com/ticket/9739#9739: Admin does not correctly prefill DataTimeField from URLTue, 02 Dec 2008 16:13:38 GMTgilhad<p>
I was not able to format URL for Admin interface to prefill DateTimeField with given value.
</p>
<p>
It worked in 0.96, but does not work in 1.0 ( I used ../admin/MyApp/MyTable/add/?box=359&amp;datum_date=2008-12-01&amp;datum_time=17:30:27)
</p>
<p>
After some looking on source code and testing i find a solution:
</p>
<ul><li>in /django/contrib/admin/options.py before line 520 add
<pre class="wiki"> if isinstance(f, models.DateTimeField):
initial[k] = initial[k].split(",")
</pre></li></ul><ul><li>use this format: <a class="ext-link" href="https://../admin/MyApp/MyTable/add/?box=359&amp;datum=2008-12-01,17:30:27"><span class="icon">​</span>https://../admin/MyApp/MyTable/add/?box=359&amp;datum=2008-12-01,17:30:27</a>
</li></ul><p>
For reference - the model of MyTable is such :
</p>
<pre class="wiki">class MyTable(models.Model):
box = models.ForeignKey(Boxes)
datum = models.DateTimeField(null=True, blank=True)
</pre><p>
(plus some other insignificant fields.
The "datum" field should be prefilled with some date, which is computed by long way (not simple now()) and the use must be able to edit it BEFORE saving it)
</p>
<hr />
<p>
The problem arises from DateTimeField be treated by MultiWidget, but not properly broken when got by URL (GET)
</p>
<hr />
<p>
Patch:
</p>
<pre class="wiki">--- options.py.old 2008-12-01 19:56:34.000000000 +0100
+++ options.py 2008-12-01 19:40:34.000000000 +0100
@@ -517,6 +517,8 @@
continue
if isinstance(f, models.ManyToManyField):
initial[k] = initial[k].split(",")
+ if isinstance(f, models.DateTimeField):
+ initial[k] = initial[k].split(",")
form = ModelForm(initial=initial)
for FormSet in self.get_formsets(request):
formset = FormSet(instance=self.model())
</pre>Resultshttps://code.djangoproject.com/ticket/9739#changeloghttps://code.djangoproject.com/ticket/10609
https://code.djangoproject.com/ticket/10609#10609: Permissions on admin actionsTue, 24 Mar 2009 16:08:28 GMTleitjohn<p>
Often one would not want an option to appear in the actions select box in the changelist. For instance, you may not want a user who can't delete to see "delete_selected".
</p>
<p>
I propose that we enable the admin to use the auth decorators (permission_required, etc).
</p>
<pre class="wiki">Index: options.py
===================================================================
--- options.py (revision 10163)
+++ options.py (working copy)
@@ -423,7 +423,11 @@
for klass in [self.admin_site] + self.__class__.mro()[::-1]:
for action in getattr(klass, 'actions', []):
func, name, description = self.get_action(action)
- actions[name] = (func, name, description)
+
+ # check permission
+ test = getattr(func, "test_func", None)
+ if test == None or test(request.user):
+ actions[name] = (func, name, description)
return actions
</pre>Resultshttps://code.djangoproject.com/ticket/10609#changeloghttps://code.djangoproject.com/ticket/10686
https://code.djangoproject.com/ticket/10686#10686: Add class name interpolation in Meta.permissions codenamesWed, 01 Apr 2009 04:03:19 GMTfaldridge<p>
I've got a patch for a slight behavior modification that I needed and that might be useful for others, and I wanted to collect some thoughts on it before writing up the regression tests and documentation changes.
</p>
<p>
Twice now, I've come across a situation where the default Django behavior for inheriting permissions is inappropriate for my security model.
</p>
<p>
Here's the situation: I have a permission on an abstract base model class that I want all child classes to inherit, and I want to then append specific permission(s) to one or more of the children.
</p>
<p>
Example:
</p>
<div class="wiki-code"><div class="code"><pre><span class="k">class</span> <span class="nc">MyAppBaseModel</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
abstract <span class="o">=</span> <span class="bp">True</span>
permissions <span class="o">=</span> <span class="p">((</span><span class="s2">"view_</span><span class="si">%(class)s</span><span class="s2">"</span><span class="p">,</span> <span class="s2">"Can view </span><span class="si">%(class)s</span><span class="s2">"</span><span class="p">),)</span>
<span class="k">class</span> <span class="nc">ChildModel</span><span class="p">(</span>MyAppBaseModel<span class="p">):</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
permissions <span class="o">=</span> <span class="p">((</span><span class="s2">"foobar_childmodel"</span><span class="p">,</span> <span class="s2">"Can foobar childmodel"</span><span class="p">),)</span>
</pre></div></div><p>
Two problems arise:
</p>
<ol><li> Although permissions currently may be inherited, the Options class does not currently implement %(class)s replacement like the RelatedField class does, so my permissions end up actually being stored in the database with %(class)s in the name and codename.
</li><li> The way Meta attributes are currently processed in the ModelBase metaclass causes inherited permissions to be completely replaced if any explicit permissions are defined on the child class. So instead of can_view and can_foobar on ChildModel, I only get can_foobar.
</li></ol><p>
This patch changes Django's behavior such that any explicit child class permissions would be appended to the inherited ones, rather than completely replacing them.
</p>
<p>
Also, I've added a backwards-compatible flag to the Meta options, 'inherit_permissions'. This flag would only be required in the case that one wanted Django's current behavior which is to discard base class permissions when explicit permissions are declared on the child class.
</p>
<p>
Example:
</p>
<div class="wiki-code"><div class="code"><pre><span class="k">class</span> <span class="nc">MyAppBaseModel</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
abstract <span class="o">=</span> <span class="bp">True</span>
permissions <span class="o">=</span> <span class="p">((</span><span class="s2">"view_</span><span class="si">%(class)s</span><span class="s2">"</span><span class="p">,</span> <span class="s2">"Can view </span><span class="si">%(class)s</span><span class="s2">"</span><span class="p">),)</span>
<span class="k">class</span> <span class="nc">ChildModel</span><span class="p">(</span>MyAppBaseModel<span class="p">):</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
permissions <span class="o">=</span> <span class="p">((</span><span class="s2">"foobar_childmodel"</span><span class="p">,</span> <span class="s2">"Can foobar childmodel"</span><span class="p">),)</span>
inherit_permissions <span class="o">=</span> <span class="bp">False</span>
</pre></div></div><p>
This would result in ChildModel only having the can_foobar permission (Django's current behavior). If you wanted to inherit/append the view_class
permission instead (proposed behavior), you could set the attribute to True or leave it out entirely.
</p>
<p>
This, of course, assumes that my desired behavior is what most other people would want. I suspect, but am not certain that this is the case.
</p>
<p>
Though a small change, I believe it requires a design decision.
</p>
<p>
Thanks!
</p>
Resultshttps://code.djangoproject.com/ticket/10686#changeloghttps://code.djangoproject.com/ticket/10944
https://code.djangoproject.com/ticket/10944#10944: Site app should be able to make absolute URLs.Tue, 28 Apr 2009 02:35:03 GMTJeremy Dunck<p>
I wish Site instances could make (real) absolute URLs (e.g. http.../path/) based on a given relative path like /path/. And a template tag to make it nicer from templates, too:
{% site_url ... %} or similar.
</p>
<p>
Can I have a pony? I'll write the patch if I can have a pony.
</p>
Resultshttps://code.djangoproject.com/ticket/10944#changeloghttps://code.djangoproject.com/ticket/11505
https://code.djangoproject.com/ticket/11505#11505: Django's TestCase should reset the cacheSun, 19 Jul 2009 14:49:12 GMTandrewfong<p>
In between test cases, the cache should be flushed in order to prevent one test case from polluting another, similar to how the database is currently flushed (or transactions rolled back) in Django's test case.
</p>
<p>
This will be easier to implement if <a class="closed ticket" href="https://code.djangoproject.com/ticket/11503" title="#11503: Cache backend should expose a flush method (closed: duplicate)">#11503</a> is complete
</p>
Resultshttps://code.djangoproject.com/ticket/11505#changeloghttps://code.djangoproject.com/ticket/11580
https://code.djangoproject.com/ticket/11580#11580: Unable to query TextField against oracle nclob 10Gr4Tue, 28 Jul 2009 19:14:20 GMTMark Anderson<p>
I have tried <span class="underline">icontains and </span>regex against a TextField on an oracle database and get the following error:
</p>
<p>
DatabaseError: ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at line 1
</p>
<p>
The code was ported directly over from mysql where the i_contains query worked. The column was created as an NCLOB. I can query against other fields fine.
</p>
<p>
Environment:
</p>
<p>
Request Method: GET
Request URL: <a class="ext-link" href="http://django/eis/banobj/search/?q=class"><span class="icon">​</span>http://django/eis/banobj/search/?q=class</a>
Django Version: 1.1 rc 1 SVN-11348
Python Version: 2.4.3
Installed Applications:
['django.contrib.auth',
</p>
<blockquote>
<p>
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'eis.banobj',
'django.contrib.admin',
'django.contrib.admindocs',
'eis.ldapauth',
'eis.emailLogs']
</p>
</blockquote>
<p>
Installed Middleware:
('django.middleware.common.CommonMiddleware',
</p>
<blockquote>
<p>
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware')
</p>
</blockquote>
<p>
Template error:
In template /opt/django/eis/templates/banobj/arealist.html, error at line 17
</p>
<blockquote>
<p>
Caught an exception while rendering: ORA-06502: PL/SQL: numeric or value error: character string buffer too small
</p>
</blockquote>
<p>
ORA-06512: at line 1
</p>
<blockquote>
<p>
7 : {% block content %}
</p>
</blockquote>
<blockquote>
<p>
8 : &lt;h1&gt; {{heading}} &lt;/h1&gt;
</p>
</blockquote>
<blockquote>
<p>
9 : &lt;table border=1&gt;
</p>
</blockquote>
<blockquote>
<p>
10 : &lt;tr&gt;
</p>
</blockquote>
<blockquote>
<p>
11 : &lt;th&gt;Banner Object&lt;/th&gt;
</p>
</blockquote>
<blockquote>
<p>
12 : &lt;th&gt;Ready For Testing&lt;/th&gt;
</p>
</blockquote>
<blockquote>
<p>
13 : &lt;th&gt;Tested&lt;/th&gt;
</p>
</blockquote>
<blockquote>
<p>
14 : &lt;th&gt;Primary User&lt;/th&gt;
</p>
</blockquote>
<blockquote>
<p>
15 : &lt;th&gt;Object Type&lt;/th&gt;
</p>
</blockquote>
<blockquote>
<p>
16 : &lt;/tr&gt;
</p>
</blockquote>
<blockquote>
<p>
17 : {% for obj in obj_list %}
</p>
</blockquote>
<blockquote>
<p>
18 : &lt;tr bgcolor="{% cycle rowcolors %}"&gt;
</p>
</blockquote>
<blockquote>
<p>
19 : &lt;td&gt;&lt;a href="/eis/banobj/wiki/{{ obj.id }}/"&gt;{{ obj.name|upper }}&lt;/a&gt;&lt;/td&gt;
</p>
</blockquote>
<blockquote>
<p>
20 : &lt;td&gt;{% if obj.prod_svn %}
</p>
</blockquote>
<blockquote>
<p>
21 : &lt;img src="/media/img/admin/icon-yes.gif"&gt;
</p>
</blockquote>
<blockquote>
<p>
22 : {% else %}
</p>
</blockquote>
<blockquote>
<p>
23 : &lt;img src="/media/img/admin/icon-no.gif"&gt;
</p>
</blockquote>
<blockquote>
<p>
24 : {% endif %}&lt;/td&gt;
</p>
</blockquote>
<blockquote>
<p>
25 : &lt;td&gt;{% if obj.user_tested %}
</p>
</blockquote>
<blockquote>
<p>
26 : &lt;img src="/media/img/admin/icon-yes.gif"&gt;
</p>
</blockquote>
<blockquote>
<p>
27 : {% else %}
</p>
</blockquote>
<p>
Traceback:
File "/usr/lib/python2.4/site-packages/django/core/handlers/base.py" in get_response
</p>
<ol start="92"><li> response = callback(request, *callback_args, <strong>callback_kwargs)
</strong></li></ol><p>
File "/usr/lib/python2.4/site-packages/django/contrib/auth/decorators.py" in <span class="underline">call</span>
</p>
<ol start="78"><li> return self.view_func(request, *args, <strong>kwargs)
</strong></li></ol><p>
File "/opt/django/eis/banobj/views.py" in search
</p>
<ol start="172"><li> context_instance=RequestContext(request))
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/shortcuts/<span class="underline">init</span>.py" in render_to_response
</p>
<ol start="20"><li> return HttpResponse(loader.render_to_string(*args, <strong>kwargs), </strong>httpresponse_kwargs)
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/loader.py" in render_to_string
</p>
<ol start="108"><li> return t.render(context_instance)
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/<span class="underline">init</span>.py" in render
</p>
<ol start="178"><li> return self.nodelist.render(context)
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/<span class="underline">init</span>.py" in render
</p>
<ol start="779"><li> bits.append(self.render_node(node, context))
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/debug.py" in render_node
</p>
<ol start="71"><li> result = node.render(context)
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/loader_tags.py" in render
</p>
<ol start="97"><li> return compiled_parent.render(context)
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/<span class="underline">init</span>.py" in render
</p>
<ol start="178"><li> return self.nodelist.render(context)
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/<span class="underline">init</span>.py" in render
</p>
<ol start="779"><li> bits.append(self.render_node(node, context))
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/debug.py" in render_node
</p>
<ol start="71"><li> result = node.render(context)
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/loader_tags.py" in render
</p>
<ol start="24"><li> result = self.nodelist.render(context)
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/<span class="underline">init</span>.py" in render
</p>
<ol start="779"><li> bits.append(self.render_node(node, context))
</li></ol><p>
File "/usr/lib/python2.4/site-packages/django/template/debug.py" in render_node
</p>
<ol start="81"><li> raise wrapped
</li></ol><p>
Exception Type: TemplateSyntaxError at /banobj/search/
Exception Value: Caught an exception while rendering: ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at line 1
</p>
<p>
Original Traceback (most recent call last):
</p>
<blockquote>
<p>
File "/usr/lib/python2.4/site-packages/django/template/debug.py", line 71, in render_node
</p>
<blockquote>
<p>
result = node.render(context)
</p>
</blockquote>
<p>
File "/usr/lib/python2.4/site-packages/django/template/defaulttags.py", line 126, in render
</p>
<blockquote>
<p>
len_values = len(values)
</p>
</blockquote>
<p>
File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 81, in <span class="underline">len</span>
</p>
<blockquote>
<p>
self._result_cache = list(self.iterator())
</p>
</blockquote>
<p>
File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 238, in iterator
</p>
<blockquote>
<p>
for row in self.query.results_iter():
</p>
</blockquote>
<p>
File "/usr/lib/python2.4/site-packages/django/db/models/sql/query.py", line 287, in results_iter
</p>
<blockquote>
<p>
for rows in self.execute_sql(MULTI):
</p>
</blockquote>
<p>
File "/usr/lib/python2.4/site-packages/django/db/models/sql/query.py", line 2383, in &lt;lambda&gt;
</p>
<blockquote>
<p>
result = iter((lambda: cursor.fetchmany(GET_ITERATOR_CHUNK_SIZE)),
</p>
</blockquote>
<p>
File "/usr/lib/python2.4/site-packages/django/db/backends/oracle/base.py", line 469, in fetchmany
</p>
<blockquote>
<p>
return tuple([self._rowfactory(r)
</p>
</blockquote>
</blockquote>
<p>
DatabaseError: ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at line 1
</p>
Resultshttps://code.djangoproject.com/ticket/11580#changeloghttps://code.djangoproject.com/ticket/11854
https://code.djangoproject.com/ticket/11854#11854: Add support of PostGIS's Azimuth functionWed, 09 Sep 2009 11:05:57 GMTChristian Karrié<p>
Hi, I would like to see the azimuth function in the gis component.
</p>
<p>
Thank you very much.
</p>
Resultshttps://code.djangoproject.com/ticket/11854#changeloghttps://code.djangoproject.com/ticket/11927
https://code.djangoproject.com/ticket/11927#11927: Allow manage.py dumpdata to dump YAML in block styleTue, 22 Sep 2009 13:54:20 GMTsampablokuper<p>
Using
</p>
<pre class="wiki">python manage.py dumpdata --format=yaml
</pre><p>
produces output in <a class="ext-link" href="http://pyyaml.org/wiki/PyYAMLDocumentation#Dictionarieswithoutnestedcollectionsarenotdumpedcorrectly"><span class="icon">​</span>flow style</a>. That's OK for automated processing, but it isn't anything like as human-readable as block style YAML. For people who, like me, need to edit the fixtures manually, it would be very useful to be able to do something like:
</p>
<pre class="wiki">python manage.py dumpdata --format=yaml --flowstyle=false
</pre>Resultshttps://code.djangoproject.com/ticket/11927#changeloghttps://code.djangoproject.com/ticket/11929
https://code.djangoproject.com/ticket/11929#11929: manage.py dumpdata outputs YAML in unhelpful orderTue, 22 Sep 2009 16:28:43 GMTsampablokuper<p>
The <a class="ext-link" href="http://docs.djangoproject.com/en/dev/howto/initial-data/"><span class="icon">​</span>docs</a> suggest providing initial YAML data in the following format:
</p>
<pre class="wiki">- model: myapp.person
pk: 1
fields:
first_name: John
last_name: Lennon
</pre><p>
but the manage.py dumpdata outputs YAML in the following form:
</p>
<pre class="wiki">- fields: {first_name: John, last_name: Lennon}
model: myapp.person
pk: 1
</pre><p>
The fact that this is flow rather than block style YAML is the subject of <a class="ext-link" href="http://code.djangoproject.com/ticket/11927"><span class="icon">​</span>#11927</a>, but there's another problem, which is that rather than putting the model and PK first (which is most human-readable), dumpdata outputs the fields first.
</p>
Resultshttps://code.djangoproject.com/ticket/11929#changeloghttps://code.djangoproject.com/ticket/11964
https://code.djangoproject.com/ticket/11964#11964: Add the ability to use database-level CHECK CONSTRAINTSTue, 29 Sep 2009 06:54:51 GMTMatthew Schinckel<p>
I mentioned adding database level CHECK CONSTRAINTS in a post on django-developers.
</p>
<p>
<a class="ext-link" href="http://groups.google.com/group/django-developers/browse_thread/thread/38937992972c7808"><span class="icon">​</span>http://groups.google.com/group/django-developers/browse_thread/thread/38937992972c7808</a>
</p>
<p>
Attached to this ticket is a patch that provides the functionality listed in the first post of this thread. This is not complete: it only allows simple constraints, and is missing a complete test suite.
</p>
Resultshttps://code.djangoproject.com/ticket/11964#changeloghttps://code.djangoproject.com/ticket/12075
https://code.djangoproject.com/ticket/12075#12075: Add wsgiorg.routing args supportThu, 22 Oct 2009 16:06:12 GMTGustavo Narea<p>
The <a class="ext-link" href="http://wsgi.readthedocs.org/en/latest/specifications/routing_args.html"><span class="icon">​</span>wsgiorg.routing_args</a> 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.
</p>
<p>
It's currently not supported in Django - But it will with the attached patch.
</p>
<p>
<em>[edit] fixed broken link.</em>
</p>
Resultshttps://code.djangoproject.com/ticket/12075#changeloghttps://code.djangoproject.com/ticket/12090
https://code.djangoproject.com/ticket/12090#12090: Show admin actions on the edit pages tooMon, 26 Oct 2009 16:19:44 GMTFlorian Apolloner<p>
Currently the workflow for comment moderation might look like this (without knowing the comment moderation admin actions ;)):
</p>
<ul><li>Look at the overview page
</li><li>If in doubt open the comment in a new page
</li><li>if it's spam go back to the previous page, select it and execute the admin action
</li></ul><p>
We could redisplay the admin actions box in the detail views (where they of course would only effect the current object) to prevent the unneeded roundtrip.
</p>
Resultshttps://code.djangoproject.com/ticket/12090#changeloghttps://code.djangoproject.com/ticket/12227
https://code.djangoproject.com/ticket/12227#12227: PREPEND_WWW breaks the test clientMon, 16 Nov 2009 19:40:40 GMTAndy Baker<p>
With PREPEND_WWW set to true the test client will always give a 301 status_code:
</p>
<pre class="wiki"> &gt;&gt;&gt; from django.test.client import Client
&gt;&gt;&gt; c = Client()
&gt;&gt;&gt; r = c.get('/admin/', follow=True)
&gt;&gt;&gt; r.status_code
301
&gt;&gt;&gt; r.redirect_chain
[('http://www.testserver/admin/', 301), ('http://www.testserver/admin/', 301)]
</pre>Resultshttps://code.djangoproject.com/ticket/12227#changeloghttps://code.djangoproject.com/ticket/12410
https://code.djangoproject.com/ticket/12410#12410: add support for St_Line_Locate_Point to geodjango postgis backendSun, 20 Dec 2009 17:06:16 GMTIanWard<p>
Here's a patch that adds a line_locate_point method to the GeoQuerySet class, allowing a calculation of the closest point along a LineString to a point field. The value returned is a float between 0 and 1. This is useful for estimating addresses and ordering points given a LineString reference.
</p>
Resultshttps://code.djangoproject.com/ticket/12410#changeloghttps://code.djangoproject.com/ticket/12416
https://code.djangoproject.com/ticket/12416#12416: Improve KML SerializationMon, 21 Dec 2009 10:37:49 GMTjbronn<p>
Currently, there are several problems with the way KML is generated inside GeoDjango:
</p>
<ol><li>Now that 3D is supported, there is no way to specify the following element tags, which are important to displaying them in Google Earth: <code>&lt;altitudeMode&gt;</code>, <code>&lt;extrude&gt;</code>, and <code>&lt;tessellate&gt;</code>.
</li></ol><ol start="2"><li>A Z value of 0 needs to be omitted for geometries that are purely 2D (this primarily affects the <code>GEOSGeometry.kml</code> property)
</li></ol><ol start="3"><li>Allow specification of an <code>id</code> for geometries, so that styling rules may be easily applied by the user.
</li></ol><ol start="4"><li>For polygons: "the <code>&lt;coordinates&gt;</code> for polygons must be specified in counterclockwise order. Polygons follow the "right-hand rule," which states that if you place the fingers of your right hand in the direction in which the coordinates are specified, your thumb points in the general direction of the geometric normal for the polygon." <a class="ext-link" href="http://code.google.com/apis/kml/documentation/kmlreference.html#polygon"><span class="icon">​</span>KML Reference</a>. I'm not sure about implementing this within the 'dumb' <code>kml</code> properties of <code>GEOSGeometry</code> and <code>OGRGeometry</code>, rather <code>GeoQueryset.kml</code> should wrap <code>ST_AsKml</code> in the necessary routines, e.g., <code>ST_Reverse(ST_ForceRHR(ST_AsKml(the_geom)))</code>.
</li></ol><p>
Attached is an initial idea for a <code>write_kml</code> routine.
</p>
Resultshttps://code.djangoproject.com/ticket/12416#changeloghttps://code.djangoproject.com/ticket/12498
https://code.djangoproject.com/ticket/12498#12498: Add multi-field validatorsMon, 04 Jan 2010 02:20:04 GMTjkocherhans<p>
Multi-field validator functionality was taken out of the model-validation branch in <a class="changeset" href="https://code.djangoproject.com/changeset/12078/">[12078]</a>. Add it back in.
</p>
<p>
See <a class="ext-link" href="http://groups.google.com/group/django-developers/browse_thread/thread/d4a4bf8607f4b8a"><span class="icon">​</span>this thread</a> on django-developers for more details.
</p>
<p>
There's also a more extensive and older <a class="ext-link" href="http://groups.google.com/group/django-developers/browse_thread/thread/436307e426844ae0/f2fa0647b97569ad"><span class="icon">​</span>discussion</a> that I missed. Thank you mrts for pointing it out.
</p>
Resultshttps://code.djangoproject.com/ticket/12498#changeloghttps://code.djangoproject.com/ticket/12566
https://code.djangoproject.com/ticket/12566#12566: admin action templates cannot be overriden on a per-app basisSun, 10 Jan 2010 05:49:54 GMTBen Jackson<p>
For example, if you want to customize the 'actions' dropdown menu you might think you could copy in <code>actions.html</code> and modify it. However, it is rendered in <code>change_list.html</code> by calling the <code>admin_actions</code> templatetag. Those templatetags use <code>register.inclusion_tag</code> which does not search for application- or model-specific versions of a template.
</p>
<p>
You can't even work around it by overriding callers like <code>change_list.html</code> without also overriding the templatetag (copying it and changing the template name).
</p>
Resultshttps://code.djangoproject.com/ticket/12566#changeloghttps://code.djangoproject.com/ticket/12772
https://code.djangoproject.com/ticket/12772#12772: Allow loading template tags by fully qualified python module pathThu, 04 Feb 2010 12:19:03 GMTPatryk Zawadzki<p>
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.
</p>
<p>
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.
</p>
<p>
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).
</p>
<p>
Also: "Explicit is better than implicit." :)
</p>
Resultshttps://code.djangoproject.com/ticket/12772#changeloghttps://code.djangoproject.com/ticket/13559
https://code.djangoproject.com/ticket/13559#13559: Need a contextprocessor for current siteTue, 18 May 2010 12:36:25 GMTtonnzor<p>
If you use Sites app you would need to use current site instance in your templates. For that purpose there should be a ContextProcessor in django.contrib.sites application.
</p>
<p>
The code is quite simple, but it makes no sense to create and store it in user's application:
</p>
<pre class="wiki">from django.contrib.sites.models import Site
def current_site(request):
return {'SITE': Site.objects.get_current()}
</pre><p>
I can provide a patch if needed.
</p>
Resultshttps://code.djangoproject.com/ticket/13559#changeloghttps://code.djangoproject.com/ticket/13564
https://code.djangoproject.com/ticket/13564#13564: Provide class attributes for form fieldsWed, 19 May 2010 05:01:19 GMTh3<p>
I work a lot with Django forms and I'm also working on grappelli and I've come to find that there's one thing that is cruelly missing from django's forms..
</p>
<p>
Meaningful class names on form inputs.
</p>
<p>
As now if I want to change the class name of an input I either have to write the forms explicitly or do something like this for *every* forms:
</p>
<pre class="wiki">
from django import forms
from django.forms import widgets
class MyForm(forms.Form):
title = forms.CharField(required=True, widget=widgets.TextInput(attrs={
'class': 'charfield required'
}))
</pre><p>
Whereas it would be easy to simply use the field type's name to generate a meaningful class;
</p>
<pre class="wiki">
&lt;input type="text" value="" class="django-charfield django-required" /&gt;
</pre><p>
The "required" is not crucial, but would be really useful for JavaScript enhanced validation.
That said, just a class hinting the field type would be a 100% improvement.
</p>
<p>
Finally, it's not just for JavaScript. It would also be useful for CSS styling. For example when
I use a PositiveInteger field I never need it to be the same width as a Char field. It would
be nice to be able to style them without having to write many lines of Python or HTML codes.
</p>
Resultshttps://code.djangoproject.com/ticket/13564#changeloghttps://code.djangoproject.com/ticket/13570
https://code.djangoproject.com/ticket/13570#13570: SMTP backend should try harder to figure out the local host nameWed, 19 May 2010 17:22:26 GMTJacob<p>
Django's SMTP backend sets the <code>local_hostname</code> argument to <code>smtplib.SMTP</code> by calling <code>socket.getfqdn()</code> (via <code>django.core.mail.utils.DNS_NAME</code>, which caches that result). <code>smtplib</code> itself uses a slightly more robust method (see <code>smtplib</code> around line 245) if <code>local_hostname</code> isn't given.
</p>
<p>
In certain circumstances this can mean that sending mail through <code>smtplib</code> directly works, but sending it via <code>django.core.mail</code> fails.
</p>
<p>
We could solve this by just passing <code>local_hostname=None</code>, but that'd result in a DNS lookup every time we send email, which is silly (and which is why we're caching it in the first place).
</p>
<p>
So, <code>DNS_NAME</code> should use similar logic to <code>smtplib</code> to try harder to get the DNS hostname.
</p>
Resultshttps://code.djangoproject.com/ticket/13570#changeloghttps://code.djangoproject.com/ticket/13659
https://code.djangoproject.com/ticket/13659#13659: Make the request accessible in callables used in ModelAdmin.list_displayFri, 28 May 2010 16:05:59 GMTSebastian Noack<p>
Its a nice feature of the dajngo admin that you can use names of model or model admin methods and plain callables in ModelAdmin.list_display. But I want show content in my custom column dependant on the logged in user. This isn't possible at the moment. But I have written a patch that passes the request object to the given callable or method, when it has the needs_request attribute and it is True.
</p>
Resultshttps://code.djangoproject.com/ticket/13659#changeloghttps://code.djangoproject.com/ticket/13750
https://code.djangoproject.com/ticket/13750#13750: ImageField accessing height or width and then data results in "I/O operation on closed file"Sat, 12 Jun 2010 22:34:14 GMTROsborne<p>
If you have a simple model with an ImageField, the following code will fail with a "I/O operation on closed file":
</p>
<pre class="wiki">instance = MyClass.objects.get(...)
w = instance.image.width
h = instance.image.height
original = Image.open(instance.image)
</pre><p>
The work around is to reopen the file:
</p>
<pre class="wiki">instance = MyClass.objects.get(...)
w = instance.image.width
h = instance.image.height
instance.image.open()
original = Image.open(instance.image)
</pre><p>
Note this is different than the issue of the 2nd read() returning empty strings for two reasons:
</p>
<ol><li>You can not seek(0), the file is closed.
</li></ol><ol start="2"><li>Needing to reopen in this case is unexpected.
</li></ol>Resultshttps://code.djangoproject.com/ticket/13750#changeloghttps://code.djangoproject.com/ticket/13841
https://code.djangoproject.com/ticket/13841#13841: Allow context processors access to current version of contextSun, 27 Jun 2010 16:25:49 GMTMitar<p>
Allow context processors access to current version of context so that they can change values and not just override them. This can be easily done with another argument, context, and also backwards compatible. Functions would only get additional argument if they are defined to get two arguments and whatever they would return would override that in the context.
</p>
Resultshttps://code.djangoproject.com/ticket/13841#changeloghttps://code.djangoproject.com/ticket/13896
https://code.djangoproject.com/ticket/13896#13896: Change language to dynamic attribute in syndication feed generatorTue, 06 Jul 2010 08:30:09 GMTjedie<p>
In my project, the language is dynamic and not hardcoded in settings. IMHO there is no way to change the language in syndication feed generator without a hack.
</p>
<p>
Change language to dynamic attribute in syndication feed generator:
</p>
<div class="wiki-code"><div xmlns="http://www.w3.org/1999/xhtml" class="diff">
<ul class="entries">
<li class="entry">
<h2>
<a>django/contrib/syndication/views.py</a>
</h2>
<table class="trac-diff inline" summary="Differences" cellspacing="0">
<colgroup><col class="lineno" /><col class="lineno" /><col class="content" /></colgroup>
<thead>
<tr>
<th title="File django/contrib/syndication/views.py (revision 13426)">
</th>
<th title="File django/contrib/syndication/views.py (working copy)">
</th>
<td><em></em> </td>
</tr>
</thead>
<tbody class="unmod">
<tr>
<th>104</th><th>104</th><td class="l"><span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; subtitle = self.__get_dynamic_attr('subtitle', obj),</span></td>
</tr><tr>
<th>105</th><th>105</th><td class="l"><span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; link = link,</span></td>
</tr><tr>
<th>106</th><th>106</th><td class="l"><span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; description = self.__get_dynamic_attr('description', obj),</span></td>
</tr>
</tbody><tbody class="mod">
<tr class="first">
<th>107</th><th> </th><td class="l"><span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; language<del>&nbsp;= settings.LANGUAGE_CODE.decode(</del>),</span></td>
</tr>
<tr class="last">
<th> </th><th>107</th><td class="r"><span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; language<ins>=self.__get_dynamic_attr('language', obj, settings.LANGUAGE_CODE.decode()</ins>),</span></td>
</tr>
</tbody><tbody class="unmod">
<tr>
<th>108</th><th>108</th><td class="l"><span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; feed_url = add_domain(current_site.domain,</span></td>
</tr><tr>
<th>109</th><th>109</th><td class="l"><span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; self.__get_dynamic_attr('feed_url', obj) or request.path),</span></td>
</tr><tr>
<th>110</th><th>110</th><td class="l"><span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; author_name = self.__get_dynamic_attr('author_name', obj),</span></td>
</tr>
</tbody>
</table>
</li>
</ul>
</div></div>Resultshttps://code.djangoproject.com/ticket/13896#changeloghttps://code.djangoproject.com/ticket/13910
https://code.djangoproject.com/ticket/13910#13910: Add generator version of Template.render(Context)Thu, 08 Jul 2010 04:07:27 GMTRon Panduwana<p>
We already can make a streaming HttpResponse by passing a generator to it. This patch adds a "stream()" method to the Template class that returns a string generator that renders the template node-by-node suitable for passing to such HttpResponse. This also includes a shortcut function "stream_to_response()" -- the streaming version of render_to_response().
</p>
Resultshttps://code.djangoproject.com/ticket/13910#changeloghttps://code.djangoproject.com/ticket/14035
https://code.djangoproject.com/ticket/14035#14035: Cannot access POST after request.encoding was set to a custom valueFri, 30 Jul 2010 15:43:03 GMTPiotr Czachur<p>
Issue happens for multipart/form-data and WSGi handler.
</p>
<pre class="wiki">#Django trunk r13353.
class DetectEncodingMiddleware(object):
def process_request(request):
# Lets say we define data encoding in POST param called "enc"
enc = request.POST['enc'] # request._load_post_and_files()
request.encoding = enc # request._set_encoding(): del self._post
request.POST # request._load_post_and_files() # raise AttributeError("You cannot set the upload handlers after the upload has been processed.");
</pre><p>
This issue is related: <a class="closed ticket" href="https://code.djangoproject.com/ticket/12522" title="#12522: Bug: Unable to get request.POST after request.get_raw_post_data (closed: duplicate)">#12522</a>
</p>
Resultshttps://code.djangoproject.com/ticket/14035#changeloghttps://code.djangoproject.com/ticket/14094
https://code.djangoproject.com/ticket/14094#14094: Cannot define CharField with unlimited lengthWed, 11 Aug 2010 13:59:39 GMTmillerdev<p>
Model validation throws an error on CharField with a null max_length:
</p>
<div class="wiki-code"><div class="code"><pre><span class="k">class</span> <span class="nc">Test</span><span class="p">(</span>Model<span class="p">):</span>
char_field <span class="o">=</span> CharField<span class="p">(</span>max_length<span class="o">=</span><span class="bp">None</span><span class="p">)</span>
</pre></div></div><p>
<strong>
One or more models did not validate:<br />
test.test: "char_field": CharFields require a "max_length" attribute that is a positive integer.
</strong>
</p>
<p>
CharField should allow max_length=None, which intuitively means there is no maximum length. This is a perfectly valid use case. Postgres, for example, supports varchar/text columns without a length limit, but Django appears to have no way to define such a column in a model class.
</p>
<p>
The model validation code looks like this (<a class="ext-link" href="http://code.djangoproject.com/browser/django/tags/releases/1.2.1/django/core/management/validation.py#L40"><span class="icon">​</span>django/core/management/validation.py:40</a>):
</p>
<div class="wiki-code"><div class="code"><pre> <span class="k">if</span> <span class="nb">isinstance</span><span class="p">(</span>f<span class="p">,</span> models<span class="o">.</span>CharField<span class="p">):</span>
<span class="k">try</span><span class="p">:</span>
max_length <span class="o">=</span> <span class="nb">int</span><span class="p">(</span>f<span class="o">.</span>max_length<span class="p">)</span>
<span class="k">if</span> max_length <span class="o">&lt;=</span> <span class="mi">0</span><span class="p">:</span>
e<span class="o">.</span>add<span class="p">(</span>opts<span class="p">,</span> <span class="s1">'"</span><span class="si">%s</span><span class="s1">": CharFields require a "max_length" attribute that is a positive integer.'</span> <span class="o">%</span> f<span class="o">.</span>name<span class="p">)</span>
<span class="k">except</span> <span class="p">(</span><span class="ne">ValueError</span><span class="p">,</span> <span class="ne">TypeError</span><span class="p">):</span>
e<span class="o">.</span>add<span class="p">(</span>opts<span class="p">,</span> <span class="s1">'"</span><span class="si">%s</span><span class="s1">": CharFields require a "max_length" attribute that is a positive integer.'</span> <span class="o">%</span> f<span class="o">.</span>name<span class="p">)</span>
</pre></div></div><p>
It should be changed to something this:
</p>
<div class="wiki-code"><div class="code"><pre> <span class="k">if</span> <span class="nb">isinstance</span><span class="p">(</span>f<span class="p">,</span> models<span class="o">.</span>CharField<span class="p">)</span> <span class="ow">and</span> f<span class="o">.</span>max_length <span class="ow">is</span> <span class="ow">not</span> <span class="bp">None</span><span class="p">:</span>
<span class="o">...</span>
</pre></div></div><p>
The FileField does not happen to throw this error because it is not a derivative of CharField. However, the SQL generated for FileField is not correct when max_length=None, so that would need to be addressed as well.
</p>
Resultshttps://code.djangoproject.com/ticket/14094#changeloghttps://code.djangoproject.com/ticket/14204
https://code.djangoproject.com/ticket/14204#14204: Take advantage of SQLite support for FK constraintsWed, 01 Sep 2010 02:19:58 GMTRamiro Morales<p>
SQLite3 3.6.19 from Oct 14 2009 adds support for enforcing these constraints. See <a class="ext-link" href="http://www.sqlite.org/foreignkeys.html"><span class="icon">​</span>http://www.sqlite.org/foreignkeys.html</a>
</p>
<p>
Creating this ticket to track this feature, with an initial implementation patch to get feedback. Will also open a django-dev thread.
</p>
Resultshttps://code.djangoproject.com/ticket/14204#changeloghttps://code.djangoproject.com/ticket/14317
https://code.djangoproject.com/ticket/14317#14317: numberformat.format produces wrong resultsMon, 20 Sep 2010 19:45:13 GMTAnssi Kääriäinen<p>
The problem:
</p>
<pre class="wiki">&gt;&gt;&gt; from django.utils.numberformat import format
&gt;&gt;&gt; print format(0.000000001, ',', 2)
1e-10,2
</pre><p>
It can be fixed with using '%.2f' % number (the format string can be constructed dynamically), and then replacing the decimal separator and doing the grouping if needed. As a bonus, it is faster that way.
</p>
Resultshttps://code.djangoproject.com/ticket/14317#changeloghttps://code.djangoproject.com/ticket/14336
https://code.djangoproject.com/ticket/14336#14336: list_display should be able to contain sortable references to annotated fieldsThu, 23 Sep 2010 21:24:23 GMTPaul McLanahan<p>
Overriding the <code>queryset</code> method of a <code>ModelAdmin</code> should be an easy way to annotate the <code>QuerySet</code> used in the admin list view for a model. My use case is that I have two <code>IntegerField</code>s containing counts of various things, but what I'd like to be able to display and sort by in the admin list view is the sum of these two fields. This can best be explained by an example:
</p>
<div class="wiki-code"><div class="code"><pre><span class="c1"># Given this model</span>
<span class="k">class</span> <span class="nc">Article</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
title <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>max_length<span class="o">=</span><span class="mi">255</span><span class="p">)</span>
num_a <span class="o">=</span> models<span class="o">.</span>PositiveIntegerField<span class="p">()</span>
num_b <span class="o">=</span> models<span class="o">.</span>PositiveIntegerField<span class="p">()</span>
<span class="c1"># Want ModelAdmin like...</span>
<span class="k">class</span> <span class="nc">ArticleAdmin</span><span class="p">(</span>admin<span class="o">.</span>ModelAdmin<span class="p">):</span>
list_display <span class="o">=</span> <span class="p">(</span><span class="s1">'title'</span> <span class="s1">'total_nums'</span><span class="p">)</span>
<span class="k">def</span> <span class="nf">queryset</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> request<span class="p">):</span>
qs <span class="o">=</span> <span class="nb">super</span><span class="p">(</span>ArticleAdmin<span class="p">,</span> <span class="bp">self</span><span class="p">)</span><span class="o">.</span>queryset<span class="p">(</span>request<span class="p">)</span>
<span class="k">return</span> qs<span class="o">.</span>extra<span class="p">(</span>select<span class="o">=</span><span class="p">{</span><span class="s1">'total_nums'</span><span class="p">:</span><span class="s1">'num_a + num_b'</span><span class="p">})</span>
</pre></div></div><p>
This fails at model validation with a <code>ImproperlyConfigured</code> exception in <code>django.contrib.admin.validation.validate</code> because the model has no 'total_nums' field, which we know. But the model validation mechanism has no access to the instance of the <code>ModelAdmin</code>, and therefore no access to the queryset to be able to check for any extras or annotations.
</p>
<p>
I tried fixing this and would have submitted a patch, but I failed in the time I had. However, there is a workaround I discovered and am using, but it seems silly. You change <code>ArticleAdmin</code> to the following:
</p>
<div class="wiki-code"><div class="code"><pre><span class="k">class</span> <span class="nc">ArticleAdmin</span><span class="p">(</span>admin<span class="o">.</span>ModelAdmin<span class="p">):</span>
list_display <span class="o">=</span> <span class="p">(</span><span class="s1">'title'</span> <span class="s1">'total'</span><span class="p">)</span>
<span class="k">def</span> <span class="nf">total</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> obj<span class="p">):</span>
<span class="k">return</span> obj<span class="o">.</span>total_nums
total<span class="o">.</span>admin_order_field <span class="o">=</span> <span class="s1">'total_nums'</span>
<span class="k">def</span> <span class="nf">queryset</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> request<span class="p">):</span>
qs <span class="o">=</span> <span class="nb">super</span><span class="p">(</span>ArticleAdmin<span class="p">,</span> <span class="bp">self</span><span class="p">)</span><span class="o">.</span>queryset<span class="p">(</span>request<span class="p">)</span>
<span class="k">return</span> qs<span class="o">.</span>extra<span class="p">(</span>select<span class="o">=</span><span class="p">{</span><span class="s1">'total_nums'</span><span class="p">:</span><span class="s1">'num_a + num_b'</span><span class="p">})</span>
</pre></div></div><p>
This seems overly verbose and a little hacky, but it does work. I'd say that makes this ticket non-urgent, though I do wonder how many developers gave up before discovering this technique.
</p>
Resultshttps://code.djangoproject.com/ticket/14336#changeloghttps://code.djangoproject.com/ticket/14370
https://code.djangoproject.com/ticket/14370#14370: Adding support for Autocomplete in contrib.adminThu, 30 Sep 2010 23:36:44 GMTGermano Gabbianelli<p>
I've tried to implement Autocomplete for contrib.admin using jQuery UI Autocomplete.<br />
Here's the code: <a class="ext-link" href="http://bitbucket.org/tyrion/django"><span class="icon">​</span>http://bitbucket.org/tyrion/django</a> <br />
Here's a live demo: <a class="ext-link" href="http://djangoac.tyrion.mx/admin/"><span class="icon">​</span>http://djangoac.tyrion.mx/admin/</a> (login with test/test).
(It supports both ForeignKey and ManyToMany).
</p>
<p>
I don't know if I should attach the complete patch here. It's kinda big (I included jquery-ui), however you can see it online at <a class="ext-link" href="http://bitbucket.org/tyrion/django/changeset/04488ec05e92"><span class="icon">​</span>http://bitbucket.org/tyrion/django/changeset/04488ec05e92</a> ).
</p>
<p>
Now it's implemented using an "autocomplete_fields" attribute which is a dict (field:related_fields):
</p>
<div class="wiki-code"><div class="code"><pre><span class="k">class</span> <span class="nc">MyModelAdmin</span><span class="p">(</span>admin<span class="o">.</span>ModelAdmin<span class="p">):</span>
autocomplete_fields <span class="o">=</span> <span class="p">{</span><span class="s1">'user'</span><span class="p">:</span> <span class="p">(</span><span class="s1">'username'</span><span class="p">,</span> <span class="s1">'email'</span><span class="p">)}</span>
</pre></div></div><p>
But because I've been asked:
</p>
<pre class="wiki">&lt;jezdez&gt; tyrion-mx: what about making the autocomplete_fields a dict of dicts, to be able to specify additional options for the autocompletion, e.g. number of search results or a custom label function?
</pre><p>
I've written this patch (for my code) <a class="ext-link" href="http://dpaste.com/hold/251220/"><span class="icon">​</span>http://dpaste.com/hold/251220/</a>
that let's you control the "value" (what is displayed in the input), "label" (what is displayed in the dropdown) and "limit" (max number of results) properties.
</p>
<p>
With it a modeladmin could look something like this:
</p>
<div class="wiki-code"><div class="code"><pre><span class="k">class</span> <span class="nc">DummyAdmin</span><span class="p">(</span>admin<span class="o">.</span>ModelAdmin<span class="p">):</span>
autocomplete_fields <span class="o">=</span> <span class="nb">dict</span><span class="p">(</span>
user1 <span class="o">=</span> <span class="nb">dict</span><span class="p">(</span>
fields <span class="o">=</span> <span class="p">(</span><span class="s1">'username'</span><span class="p">,</span> <span class="s1">'email'</span><span class="p">),</span>
value <span class="o">=</span> <span class="s1">'username'</span><span class="p">,</span>
limit <span class="o">=</span> <span class="mi">10</span><span class="p">,</span>
<span class="p">),</span>
friends <span class="o">=</span> <span class="nb">dict</span><span class="p">(</span>
fields <span class="o">=</span> <span class="p">(</span><span class="s1">'username'</span><span class="p">,</span> <span class="s1">'email'</span><span class="p">),</span>
label <span class="o">=</span> <span class="s1">u'</span><span class="si">%(first_name)s</span><span class="s1"> </span><span class="si">%(last_name)s</span><span class="s1">'</span><span class="p">,</span>
value <span class="o">=</span> <span class="s1">'email'</span><span class="p">,</span>
<span class="p">),</span>
<span class="p">)</span>
</pre></div></div><p>
In that case "value" and "label" can be either a function, a fieldname or a string like <code>u'%(username)s "%(email)s"'</code>.
</p>
Resultshttps://code.djangoproject.com/ticket/14370#changeloghttps://code.djangoproject.com/ticket/14761
https://code.djangoproject.com/ticket/14761#14761: URL resolving / reversing design doesn't allow alternate specsTue, 23 Nov 2010 06:21:30 GMTsamuel337<p>
Django's URL resolution system is currently based on regexps and is represented by the RegexURLPattern class. There are cases where it would be preferable to subclass this and allow alternate ways of specifying URL patterns that ultimately compile down to regexps.
</p>
<p>
Right now, this works for URL resolving as during resolution, the resolve method on the RegexURLPattern class is called, and hence subclasses can modify that behaviour. It however, <strong>doesn't</strong> work for URL reversal, because the resolver class generates the possible matches itself, instead of calling a method on RegexURLPattern or its subclasses as is the case with URL resolution.
</p>
<p>
The attached patch simply refactors urlresolvers.py so the resolver calls a method on RegexURLPattern to get possible matches. It passes all the URL tests in Django, is completely backwards-compatible and introduces no new issues or quirks.
</p>
<p>
I don't believe any new tests are required, and because the new method on RegexURLPattern is marked private (hence subject to change), no new docs are required either. This should stay as an unsupported way to extend Django's URL system until it is fully revamped (support disjunctives, URI templates etc.).
</p>
<p>
The relevant thread on django-developers is here - <a class="ext-link" href="http://groups.google.com/group/django-developers/browse_thread/thread/c94b551ebd57fbe6/65d79a336fef04b2"><span class="icon">​</span>http://groups.google.com/group/django-developers/browse_thread/thread/c94b551ebd57fbe6/65d79a336fef04b2</a>
</p>
Resultshttps://code.djangoproject.com/ticket/14761#changeloghttps://code.djangoproject.com/ticket/15279
https://code.djangoproject.com/ticket/15279#15279: Inheritance of fields from a single abstract base class through multiple abstract classes causes errors.Fri, 11 Feb 2011 20:28:38 GMTmelinath<p>
Assume the following models in <code>app</code>:
</p>
<div class="wiki-code"><div class="code"><pre><span class="kn">from</span> <span class="nn">django.db</span> <span class="kn">import</span> models
<span class="k">class</span> <span class="nc">Orange</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
<span class="k">pass</span>
<span class="k">class</span> <span class="nc">BaseClass</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
field <span class="o">=</span> models<span class="o">.</span>ForeignKey<span class="p">(</span>Orange<span class="p">)</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
abstract <span class="o">=</span> <span class="bp">True</span>
<span class="k">class</span> <span class="nc">Parent1</span><span class="p">(</span>BaseClass<span class="p">):</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
abstract<span class="o">=</span><span class="bp">True</span>
<span class="k">class</span> <span class="nc">Parent2</span><span class="p">(</span>BaseClass<span class="p">):</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
abstract<span class="o">=</span><span class="bp">True</span>
<span class="k">class</span> <span class="nc">Child</span><span class="p">(</span>Parent1<span class="p">,</span> Parent2<span class="p">):</span>
<span class="k">pass</span>
</pre></div></div><p>
Currently, this definition will raise the following errors during model validation:
</p>
<div class="wiki-code"><div class="code"><pre>Unhandled exception in thread started by &lt;bound method Command.inner_run of &lt;django.core.management.commands.runserver.Command object at 0x101470490&gt;&gt;
Traceback <span class="o">(</span>most recent call last<span class="o">)</span>:
File <span class="s2">"..../django/core/management/commands/runserver.py"</span>, line 88, in inner_run
self.validate<span class="o">(</span><span class="nv">display_num_errors</span><span class="o">=</span>True<span class="o">)</span>
File <span class="s2">"..../django/core/management/base.py"</span>, line 253, in validate
raise CommandError<span class="o">(</span><span class="s2">"One or more models did not validate:\n%s"</span> % error_text<span class="o">)</span>
django.core.management.base.CommandError: One or more models did not validate:
app.child: Accessor <span class="k">for</span> field <span class="s1">'field'</span> clashes with related field <span class="s1">'Orange.child_set'</span>. Add a related_name argument to the definition <span class="k">for</span> <span class="s1">'field'</span>.
app.child: Accessor <span class="k">for</span> field <span class="s1">'field'</span> clashes with related field <span class="s1">'Orange.child_set'</span>. Add a related_name argument to the definition <span class="k">for</span> <span class="s1">'field'</span>.
</pre></div></div><p>
Using the <code> %(app_label)s_%(class)s_related </code> syntax only makes things worse:
</p>
<div class="wiki-code"><div class="code"><pre>Unhandled exception in thread started by &lt;bound method Command.inner_run of &lt;django.core.management.commands.runserver.Command object at 0x10146e4d0&gt;&gt;
Traceback <span class="o">(</span>most recent call last<span class="o">)</span>:
File <span class="s2">"..../django/core/management/commands/runserver.py"</span>, line 88, in inner_run
self.validate<span class="o">(</span><span class="nv">display_num_errors</span><span class="o">=</span>True<span class="o">)</span>
File <span class="s2">"..../django/core/management/base.py"</span>, line 253, in validate
raise CommandError<span class="o">(</span><span class="s2">"One or more models did not validate:\n%s"</span> % error_text<span class="o">)</span>
django.core.management.base.CommandError: One or more models did not validate:
app.child: Accessor <span class="k">for</span> field <span class="s1">'field'</span> clashes with related field <span class="s1">'Orange.app_child_related'</span>. Add a related_name argument to the definition <span class="k">for</span> <span class="s1">'field'</span>.
app.child: Reverse query name <span class="k">for</span> field <span class="s1">'field'</span> clashes with related field <span class="s1">'Orange.app_child_related'</span>. Add a related_name argument to the definition <span class="k">for</span> <span class="s1">'field'</span>.
app.child: Accessor <span class="k">for</span> field <span class="s1">'field'</span> clashes with related field <span class="s1">'Orange.app_child_related'</span>. Add a related_name argument to the definition <span class="k">for</span> <span class="s1">'field'</span>.
app.child: Reverse query name <span class="k">for</span> field <span class="s1">'field'</span> clashes with related field <span class="s1">'Orange.app_child_related'</span>. Add a related_name argument to the definition <span class="k">for</span> <span class="s1">'field'</span>.
</pre></div></div><p>
Instead of causing errors, it seems like the field should only be inherited once from BaseClass. My patch handles this as follows: On each field instance, track the class it was originally declared for and the first non-abstract class that it shows up in. Then, when a field is being added to a class, check to make sure that it only gets added if it isn't a "duplicate". (The patch will incidentally also need to move the get_FIELD_display method declaration into cls._meta.add_field.)
</p>
Resultshttps://code.djangoproject.com/ticket/15279#changeloghttps://code.djangoproject.com/ticket/15648
https://code.djangoproject.com/ticket/15648#15648: Allow QuerySet.values_list() to return a namedtupleSat, 19 Mar 2011 14:13:17 GMTPaul Miller<p>
Python 2.6 supports named tuples. Information about field names is stored in the tuple class, so there's no overhead like in dictionaries.
I propose to use them in querysets instead of values() / values_list().
</p>
<div class="wiki-code"><div class="code"><pre>qs <span class="o">=</span> Items<span class="o">.</span>objects<span class="o">.</span>filter<span class="p">(</span><span class="o">...</span><span class="p">)</span><span class="o">.</span>namedtuples<span class="p">(</span><span class="s1">'title'</span><span class="p">,</span> <span class="s1">'amount'</span><span class="p">,</span> <span class="s1">'price'</span><span class="p">)</span>
<span class="k">for</span> item <span class="ow">in</span> qs<span class="p">:</span>
<span class="k">print</span> item<span class="o">.</span>title<span class="p">,</span> item<span class="o">.</span>amount
total <span class="o">+=</span> item<span class="o">.</span>amount <span class="o">*</span> item<span class="o">.</span>price
</pre></div></div><p>
Patch:
</p>
<div class="wiki-code"><div class="code"><pre><span class="kn">from</span> <span class="nn">itertools</span> <span class="kn">import</span> imap
<span class="kn">from</span> <span class="nn">collections</span> <span class="kn">import</span> namedtuple
<span class="c1"># python 2.5 doesn't support named tuples, so we can use this http://code.activestate.com/recipes/500261/</span>
<span class="kn">from</span> <span class="nn">django.db.models.query</span> <span class="kn">import</span> ValuesQuerySet
<span class="k">class</span> <span class="nc">NamedTuplesQuerySet</span><span class="p">(</span>ValuesQuerySet<span class="p">):</span>
<span class="k">def</span> <span class="nf">iterator</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="c1"># get field names </span>
extra_names <span class="o">=</span> <span class="bp">self</span><span class="o">.</span>query<span class="o">.</span>extra_select<span class="o">.</span>keys<span class="p">()</span>
field_names <span class="o">=</span> <span class="bp">self</span><span class="o">.</span>field_names
aggregate_names <span class="o">=</span> <span class="bp">self</span><span class="o">.</span>query<span class="o">.</span>aggregate_select<span class="o">.</span>keys<span class="p">()</span>
names <span class="o">=</span> extra_names <span class="o">+</span> field_names <span class="o">+</span> aggregate_names
<span class="c1"># create named tuple class</span>
tuple_cls <span class="o">=</span> namedtuple<span class="p">(</span><span class="s1">'</span><span class="si">%s</span><span class="s1">Tuple'</span> <span class="o">%</span> <span class="bp">self</span><span class="o">.</span>model<span class="o">.</span>__name__<span class="p">,</span> names<span class="p">)</span>
results_iter <span class="o">=</span> <span class="bp">self</span><span class="o">.</span>query<span class="o">.</span>get_compiler<span class="p">(</span><span class="bp">self</span><span class="o">.</span>db<span class="p">)</span><span class="o">.</span>results_iter<span class="p">()</span>
<span class="c1"># wrap every string with our named tuple</span>
<span class="k">return</span> imap<span class="p">(</span>tuple_cls<span class="o">.</span>_make<span class="p">,</span> results_iter<span class="p">)</span>
</pre></div></div><div class="wiki-code"><div class="code"><pre><span class="kn">from</span> <span class="nn">django.db.models.query</span> <span class="kn">import</span> QuerySet
<span class="k">def</span> <span class="nf">namedtuples</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="o">*</span>fields<span class="p">):</span>
<span class="k">return</span> <span class="bp">self</span><span class="o">.</span>_clone<span class="p">(</span>klass<span class="o">=</span>NamedTuplesQuerySet<span class="p">,</span> setup<span class="o">=</span><span class="bp">True</span><span class="p">,</span> _fields<span class="o">=</span>fields<span class="p">)</span>
QuerySet<span class="o">.</span>namedtuples <span class="o">=</span> namedtuples
</pre></div></div>Resultshttps://code.djangoproject.com/ticket/15648#changeloghttps://code.djangoproject.com/ticket/15727
https://code.djangoproject.com/ticket/15727#15727: Add support for Content-Security-Policy (CSP) to coreThu, 31 Mar 2011 13:16:57 GMTdb.pub.mail@…<p>
out of the box support for CSP would totally rock!
See <a class="ext-link" href="https://developer.mozilla.org/en/Security/CSP/Introducing_Content_Security_Policy"><span class="icon">​</span>https://developer.mozilla.org/en/Security/CSP/Introducing_Content_Security_Policy</a> for more information on what CSP is about.
</p>
Resultshttps://code.djangoproject.com/ticket/15727#changeloghttps://code.djangoproject.com/ticket/15855
https://code.djangoproject.com/ticket/15855#15855: cache_page decorator bypasses any Vary headers set in middlewareTue, 19 Apr 2011 19:44:57 GMTCarl Meyer<p>
A number of common response middlewares in Django (gzip, sessions, locale, csrf) add to the Vary header on responses, which is checked both by Django's caching system and upstream HTTP caches to determine what requests can safely be served that cached response. Getting the Vary header correct can be quite important, as failure to include it can mean upstream caches show session-private content to users who should not see it.
</p>
<p>
Since view decorators run on the outgoing response first, before response middleware, the cache_page decorator caches the response before any of the mentioned response middlewares have a chance to add their Vary headers. This means two things: 1) the cache key used won't include the headers the response ought to vary on, and Django may later serve that response to users who really shouldn't get it, and 2) when that cached response is later served to a user, it still won't include the Vary header that it should have, and thus may also be cached wrongly by an upstream HTTP cache.
</p>
<p>
I can't see a reasonable way of fixing this that maintains the current semantics of the cache_page decorator. The only option I've come up with is to require all users of full-response caching to always include the <code>UpdateCacheMiddleware</code> in their MIDDLEWARE_CLASSES (in its recommended spot at the top of the list, thus last in response processing), and only do the actual caching there. We'd then have to provide some way to say "don't cache pages unless they are marked" (a setting? ugh), and then the cache_page decorator would just mark the response for later caching (which would override the global don't-cache flag).
</p>
Resultshttps://code.djangoproject.com/ticket/15855#changeloghttps://code.djangoproject.com/ticket/16027
https://code.djangoproject.com/ticket/16027#16027: Include app_label in ContentType.__unicode__Sat, 14 May 2011 22:43:48 GMTJakub Roztočil<p>
When there are multiple models with same name in your project and you use the amazing content types framework, then selects for foreign keys to ContentType contain indistinguishable items. To fix this, the app_label needs to be included in ContentType's <span class="underline">unicode</span>.
</p>
Resultshttps://code.djangoproject.com/ticket/16027#changeloghttps://code.djangoproject.com/ticket/16043
https://code.djangoproject.com/ticket/16043#16043: Specialization cache should be filled/shared with parent object cache (multitable inheritance)Tue, 17 May 2011 12:54:36 GMTPiotr Czachur<p>
Here is some multi-table inheritance example:
</p>
<pre class="wiki">class Owner(models.Model):
nick = models.CharField(max_length=100)
class Car(models.Model):
owner = models.ForeignKey(Owner)
some_id = models.CharField(max_length=100)
class MiniMorris(Car):
mini_type = models.CharField(max_length=1)
</pre><pre class="wiki">
- model: auto.Owner
pk: 1
fields:
nick: Homer
- model: auto.Car
pk: 1
fields:
owner: 1
some_id: 'minii A'
- model: auto.MiniMorris
pk: 1
fields:
mini_type: 'e'
</pre><pre class="wiki">&gt;&gt;&gt; c = Car.objects.select_related('owner').get(pk=1)
&gt;&gt;&gt; # SELECT "auto_car"."id", "auto_car"."owner_id", "auto_car"."some_id", "auto_owner"."id", "auto_owner"."nick" FROM "auto_car" INNER JOIN "auto_owner" ON ("auto_car"."owner_id" = "auto_owner"."id") WHERE "auto_car"."id" = 1
&gt;&gt;&gt; c.owner
&lt;Owner: Owner object&gt;
&gt;&gt;&gt; # No SQL, cache hit.
&gt;&gt;&gt; m = c.minimorris
&gt;&gt;&gt; # SELECT "auto_car"."id", "auto_car"."owner_id", "auto_car"."some_id", "auto_minimorris"."car_ptr_id", "auto_minimorris"."mini_type" FROM "auto_minimorris" INNER JOIN "auto_car" ON ("auto_minimorris"."car_ptr_id" = "auto_car"."id") WHERE "auto_minimorris"."car_ptr_id" = 1
&gt;&gt;&gt; # SQL is fine, we need to obtain this specialization
&gt;&gt;&gt; m.owner
&lt;Owner: Owner object&gt;
&gt;&gt;&gt; # SELECT "auto_owner"."id", "auto_owner"."nick" FROM "auto_owner" WHERE "auto_owner"."id" = 1
&gt;&gt;&gt; # Redundant SQL. This could be obtained from cache.
</pre><p>
SQL issued by "m.owner" is redundant as owner is already cached in parent object.
</p>
Resultshttps://code.djangoproject.com/ticket/16043#changeloghttps://code.djangoproject.com/ticket/16149
https://code.djangoproject.com/ticket/16149#16149: Allow disabling choices in a <select>Fri, 03 Jun 2011 14:53:43 GMTJody McIntyre<p>
We need to be able to disable choices in a &lt;select&gt;, which is done by setting the disabled attribute on the &lt;option&gt; tag, for example:
<code>&lt;option value="bananas" disabled="disabled"&gt;Bananas&lt;/option&gt;</code>
</p>
<p>
Currently we're doing this by subclassing the Select widget:
<a class="ext-link" href="http://djangosnippets.org/snippets/2453/"><span class="icon">​</span>http://djangosnippets.org/snippets/2453/</a>
</p>
<p>
It would be nice if the built in Select widget supported this. One way would be to replace the existing render_option method with what I've written, and I can prepare a patch if desired, but this approach changes the format of the "choices" data structure to something that won't be understood by other widgets. Perhaps these widgets should be improved too, but I don't want to do this unless the patch has a chance of being accepted.
</p>
Resultshttps://code.djangoproject.com/ticket/16149#changeloghttps://code.djangoproject.com/ticket/16176
https://code.djangoproject.com/ticket/16176#16176: Overwriting a property with field during model inheritance.Wed, 08 Jun 2011 17:16:03 GMTczepiel.artur@…<p>
Documentation says (in <a class="ext-link" href="https://docs.djangoproject.com/en/1.3/topics/db/models/#field-name-hiding-is-not-permitted"><span class="icon">​</span>https://docs.djangoproject.com/en/1.3/topics/db/models/#field-name-hiding-is-not-permitted</a> paragraph) that:
</p>
<p>
This restriction only applies to attributes which are Field instances. Normal Python attributes can be overridden if you wish. It also only applies to the name of the attribute as Python sees it: if you are manually specifying the database column name, you can have the same column name appearing in both a child and an ancestor model for multi-table inheritance (they are columns in two different database tables).
</p>
<p>
However.. I came up today with setup like this:
</p>
<pre class="wiki"> 1 from django.db import models
2
3 # Create your models here.
4
5 class SomeTestModel(models.Model):
6 some_field = models.CharField(max_length=100)
7
8 class Meta:
9 abstract = True
10
11 @property
12 def other_field(self):
13 return "[OTHER] %s" % self.some_field
14
15
16
17 class OtherModel(SomeTestModel):
18 other_field = models.CharField(max_length=100)
19
20
21 class AndMoreOther(SomeTestModel):
22 not_important_field = models.CharField(max_length=100)
</pre><p>
And then if you do:
</p>
<pre class="wiki">&gt;&gt;&gt; from testapp.models import *
&gt;&gt;&gt; o = OtherModel()
Traceback (most recent call last):
File "&lt;console&gt;", line 1, in &lt;module&gt;
File "/home/arturstudio/PROJEKTY/tempdjango/inh/src/django/django/db/models/base.py", line 357, in __init__
setattr(self, field.attname, val)
AttributeError: can't set attribute
</pre><p>
Since my models where a lot bigger and more complicate, it took me almost all day to figure out that the problem was a @property from a base model, and my suggestion is that there should be at least a warning somewhere (during model's <span class="underline">init</span> perhaps) that could be more precise about why attribute couldn't been set. (or attribute to which object (either Model or Field).
</p>
<p>
I tried it on 1.2 and 1.4 pre-alpha SVN-16338
</p>
<p>
To reproduce you just need to put the models.py from above in some app.
</p>
Resultshttps://code.djangoproject.com/ticket/16176#changeloghttps://code.djangoproject.com/ticket/16260
https://code.djangoproject.com/ticket/16260#16260: Ability to change dismissRelatedLookupPopup on custom callback functionWed, 15 Jun 2011 01:40:13 GMTAlex Kamedov<p>
The best solution for some cases for customizing admin is put some links with showRelatedObjectLookupPopup javascript function on admin changelist, but after user choose the object, custom javascript function must be called instead of dismissRelatedLookupPopup javascript function.
</p>
<p>
Execution of dismissRelatedLookupPopup is hard coded in python code now. The easiest way to implement use case described higher is adding new GET argument "_callback" to changelist view.
</p>
Resultshttps://code.djangoproject.com/ticket/16260#changeloghttps://code.djangoproject.com/ticket/16521
https://code.djangoproject.com/ticket/16521#16521: Provide keyboard shortcuts in adminTue, 26 Jul 2011 13:56:40 GMTcoolRR<p>
Please provide keyboard shortcuts in Django's admin. They could be GMail-style (j and k for going up and down the item lists, / to search, etc.) or anything else, as long as they work.
</p>
Resultshttps://code.djangoproject.com/ticket/16521#changeloghttps://code.djangoproject.com/ticket/16872
https://code.djangoproject.com/ticket/16872#16872: Add touch support to the geographic adminSat, 17 Sep 2011 20:08:58 GMTjbronn<p>
OpenLayers 2.11 added support for touch events, it would be nice to be able to edit geometries inside the admin from mobile devices, e.g., the iPad and Android tablets.
</p>
Resultshttps://code.djangoproject.com/ticket/16872#changeloghttps://code.djangoproject.com/ticket/17208
https://code.djangoproject.com/ticket/17208#17208: Dogfood class-based views in contrib.adminSat, 12 Nov 2011 09:22:11 GMTmelinath<p>
This is something that I believe was discussed at <a class="wiki" href="https://code.djangoproject.com/wiki/DjangoCon">DjangoCon</a>, as well as in the django-dev mailing list and on IRC. It would be good to do a) on principle, b) to make the admin views easier to extend, and c) to potentially find and correct issues in the generic class-based views.
</p>
<p>
Naturally, any solution would need to be backwards-compatible.
</p>
Resultshttps://code.djangoproject.com/ticket/17208#changeloghttps://code.djangoproject.com/ticket/17379
https://code.djangoproject.com/ticket/17379#17379: Don't deactivate translations by default in management commandsSun, 11 Dec 2011 19:22:13 GMTChris Chambers<p>
I see the rationale in <code>django.management.core.base</code>, but this is unexpected behaviour for <code>./manage.py shell</code>, for example - particularly if you're running with a <code>LANGUAGE_CODE</code> like 'en-gb' as there's no visual feedback/documentation to illustrate that l10n/i18n are off. Granted, this won't make affect many people, but it can cause all kinds of debugging woes.
</p>
<p>
I'd like to suggest the simple fix of either:
</p>
<ol><li>forcing <code>translation.activate(settings.LANGUAGE_CODE)</code> during the <code>./manage.py shell</code> command.
</li><li>Adding some visual feedback/documentation if this turns out to be impractical for whatever reason.
</li></ol>Resultshttps://code.djangoproject.com/ticket/17379#changeloghttps://code.djangoproject.com/ticket/17461
https://code.djangoproject.com/ticket/17461#17461: Document presumed order of foreign keys on intermediate M2M modelSun, 25 Dec 2011 12:36:12 GMTflytwokites@…<p>
When defining a many-to-many relationship from a model to itself and using an intermediary model,
</p>
<pre class="wiki">class User(models.Model):
name = models.CharField(max_length=100)
followers = models.ManyToManyField('self', through='Relationship', symmetrical=False)
def __unicode__(self):
return self.name
class Relationship(models.Model):
target = models.ForeignKey('User', related_name='r1')
follower = models.ForeignKey('User', related_name='r2')
created_at = models.DateTimeField(auto_now_add=True)
</pre><p>
It seems that django determine 'from field' and 'to field' by it's definition order,
the first field always used as 'from field' and the second field always used as 'to field'.
So I MUST put <code>target</code> field defintion above the <code>follower</code> field.
</p>
<p>
I checked the document but can not found any infomation to confirm it,
I think the document should clearly explained the rule.
</p>
Resultshttps://code.djangoproject.com/ticket/17461#changeloghttps://code.djangoproject.com/ticket/17508
https://code.djangoproject.com/ticket/17508#17508: DateDetailView should accept less specific dates, ie Year/Month or just YearFri, 06 Jan 2012 12:22:31 GMTAndrewIngram<p>
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:
</p>
<p>
/2012/
/2012/jan/
/2012/jan/06/
/2012/jan/06/blog-entry-name/
</p>
<p>
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.
</p>
<p>
In my case my URL structure is as follows, I don't use DayArchive at all:
</p>
<p>
/2012/
/2012/jan/
/2012/jan/blog-entry-name/
</p>
<p>
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.
</p>
<p>
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.
</p>
Resultshttps://code.djangoproject.com/ticket/17508#changeloghttps://code.djangoproject.com/ticket/17688
https://code.djangoproject.com/ticket/17688#17688: No m2m_changed signal sent to when referenced object is deletedTue, 14 Feb 2012 22:18:26 GMTjblaine@…<pre class="wiki">class Topping(models.Model):
name = models.CharField()
class Pizza(models.Model):
name = models.CharField()
toppings = models.ManyToManyField(Topping, null=true, blank=true)
</pre><p>
And this data established using those models:
</p>
<pre class="wiki"> TOPPING
id=1, name="Pepperoni"
id=2, name="Onion"
id=3, name="Mushroom"
PIZZA
id=1, name="foopizza"
toppings=1,2,3
</pre><ol><li>Deleting any Topping object (for example, deleting id=1, name="Pepperoni") also removes it from foopizza.toppings. <strong>GOOD</strong>
</li></ol><ol start="2"><li>No m2m_changed signal is sent when 1 (above happens). <strong>BAD?</strong>
</li></ol>Resultshttps://code.djangoproject.com/ticket/17688#changeloghttps://code.djangoproject.com/ticket/17905
https://code.djangoproject.com/ticket/17905#17905: Admin documentation lists all models, even for users without access to certain applicationsThu, 15 Mar 2012 13:20:41 GMTchriscohoat<p>
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.
</p>
<p>
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.
</p>
Resultshttps://code.djangoproject.com/ticket/17905#changeloghttps://code.djangoproject.com/ticket/17943
https://code.djangoproject.com/ticket/17943#17943: Too many open file descriptors while using memcacheTue, 20 Mar 2012 21:34:27 GMTm.gajda@…<p>
Hi all,
</p>
<p>
I am using Django 1.3.1 with memcached server under Linux (PLD distro). Django application is run with runfcgi command (maxspare set to 20). After switching to Django 1.3.1 (from line 1.2.x) I encountered very strange behaviour -- the app became crashing after some time.
</p>
<p>
What I have discovered is very large number of open socket connections made by the Django app to the memcached server (lsof show hundrets of open descriptors). After some time the app process had been killed by the system, due to exceeded number of opened file descriptors.
</p>
<p>
Look at Google pointed me to the ticket <a class="closed ticket" href="https://code.djangoproject.com/ticket/15324" title="#15324: memcached cache backend creating new connection for every action (closed: fixed)">#15324</a>. Since that patch has been incorporated in the Django 1.3.1, I have started digging into memcached Django wrapper over the pyton-memcached module (django.core.cache.backends.memcached). What I found is that Django app run in multithreaded mode creates new cache object for every thread. This is probably good information, since it has allowed avoid difficult race conditions. What is sad - after closing/releasing the thread, the cache object is somehow not deleted properly. I mean it seems that it does not clean up all gathered resources properly. This lasts with large number of opened file descriptors in the memcached case.
</p>
<p>
I have added simple patch fixing said behaviour. It works quite well for me, thus I assume I could be considered to be improved and somehow merged with the Django sources. I have not created any tests, I am sorry for that.
</p>
Resultshttps://code.djangoproject.com/ticket/17943#changeloghttps://code.djangoproject.com/ticket/18283
https://code.djangoproject.com/ticket/18283#18283: FileField should not reuse FieldFilesMon, 07 May 2012 17:17:13 GMTSayane<p>
A simple example:
</p>
<pre class="wiki">old_image = mymodel.image
old_image.open()
try:
mymodel.image = do_something_with_image(old_image)
finally:
old_image.close()
mymodel.save() # transaction manager is in auto commit mode
old_image.delete()
</pre><p>
<strong>Expected behavior:</strong>
</p>
<p>
New file is commited to disk and database, old file is removed.
</p>
<p>
<strong>Actual behavior:</strong>
</p>
<p>
New file is commited to disk and database, then this new file is removed from disk.
</p>
<p>
That's because FileField (or to be more precise: FileDescriptor class) is re-using FieldFile objects instead of creating new FieldFile for every new instance of a file. This leads to unexpected results and data loss (like in example).
</p>
Resultshttps://code.djangoproject.com/ticket/18283#changeloghttps://code.djangoproject.com/ticket/18763
https://code.djangoproject.com/ticket/18763#18763: Shortcut to get users by permissionMon, 13 Aug 2012 21:47:49 GMTshelldweller<p>
In my apps I often need to get the list of users who have a specific permission. But it seems there is no shortcut to do this in Django itself (unless I'm missing something obvious). And getting users by permission is slightly more complicated than may appear at first sight because user permission can be set at user level or at group level, and also we need to pay special attention to superusers.
</p>
<p>
So I usually end up doing something like this:
</p>
<pre class="wiki">from django.contrib.auth.models import User
from django.db.models import Q
def get_users_by_permission_q(permission_name, include_superusers=True):
""" Returns the Q object suitable for querying users by permission. If include_superusers
is true (default) all superusers will be also included. Otherwise
only users with explicitely set permissions will be included. """
(appname, codename) = permission_name.split(".")
query = \
Q(user_permissions__codename=codename, user_permissions__content_type__app_label=appname) | \
Q(groups__permissions__codename=codename, groups__permissions__content_type__app_label=appname)
if include_superusers:
query |= Q(is_superuser=True)
# The above query may return multiple instances of User objects if user
# has overlapping permissions. Hence we are using a nested query by unique
# user ids.
return {'pk__in': User.objects.filter(query).distinct().values('pk')}
def get_users_by_permission(permission_name, include_superusers=True):
""" Returns the queryset of User objects with the given permission. Permission name
is in the form appname.permission similar to the format
required by django.contrib.auth.decorators.permission_required
"""
return User.objects.filter( get_users_by_permission_q(permission_name, include_superusers) )
</pre><p>
And them in my models.py:
</p>
<pre class="wiki">class MyModel:
my_fk_field = models.ForeignKey(User, limit_choices_to=dict(is_active=True, \
*get_users_by_permission_q("myapp.change_my_model", False)))
</pre><p>
Or in my views:
</p>
<pre class="wiki">users = get_users_by_permission("myapp.change_my_model")
</pre><p>
It would be nice to have something like this in django/contrib/auth/utils.py
</p>
<p>
If this proposal gets accepted I can contribute a patch.
</p>
Resultshttps://code.djangoproject.com/ticket/18763#changeloghttps://code.djangoproject.com/ticket/18855
https://code.djangoproject.com/ticket/18855#18855: persist a socket across reloads of the dev serverSat, 25 Aug 2012 15:45:33 GMTDan LaMotte<p>
Using livereload (livereload.com) with Django becomes painful when updating a file immediately results in reloading the webpage AND the Django dev server. There is a short period of time when the dev server is not listening as it is busy reloading (frequently hit when using livereload).
</p>
<p>
This is exacerbated with larger projects as reload time is longer.
</p>
<p>
This has been an itch I've wanted to scratch for a long time. Hopefully, this will be accepted so others can benefit from it also. Helps plenty even with users hitting Reload manually on their browser.
</p>
Resultshttps://code.djangoproject.com/ticket/18855#changeloghttps://code.djangoproject.com/ticket/18887
https://code.djangoproject.com/ticket/18887#18887: LineString array method (property) returns different data type without and with NumPy installedFri, 31 Aug 2012 08:51:43 GMTmal<p>
Apparently LineString (and probably other geometry types) return data in different types depending on whether NumPy is installed.
</p>
<p>
Simple test case (reproducible in Django 1.3, 1.3.1 and 1.4.1).
</p>
<p>
Clean virtual env with only Django installed (and ipython).
First - no NumPy installed.
</p>
<pre class="wiki">In [1]: from django.contrib.gis.geos import LineString
In [2]: line = LineString((0, 0), (3, 3))
In [3]: line.array
Out[3]: [(0.0, 0.0), (3.0, 3.0)]
</pre><p>
Now - install NumPy and try again.
</p>
<pre class="wiki">In [1]: from django.contrib.gis.geos import LineString
In [2]: line = LineString((0, 0), (3, 3))
In [3]: line.array
Out[3]:
array([[ 0., 0.],
[ 3., 3.]])
</pre><p>
[(0.0, 0.0), (3.0, 3.0)] =! array(<a class="missing wiki"> 0., 0.],[ 3., 3.?</a>)
</p>
<p>
This is rather serious issue.
</p>
Resultshttps://code.djangoproject.com/ticket/18887#changeloghttps://code.djangoproject.com/ticket/18914
https://code.djangoproject.com/ticket/18914#18914: Add a way to add items to the admin's object tools using Python codeThu, 06 Sep 2012 13:17:02 GMTmcrute<p>
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.
</p>
Resultshttps://code.djangoproject.com/ticket/18914#changeloghttps://code.djangoproject.com/ticket/19227
https://code.djangoproject.com/ticket/19227#19227: Reorganize method flowchart for class based generic views to treeFri, 02 Nov 2012 10:27:18 GMTshoul@…<p>
It would be nice to have a tree that build up the flowchart.
</p>
Resultshttps://code.djangoproject.com/ticket/19227#changeloghttps://code.djangoproject.com/ticket/19235
https://code.djangoproject.com/ticket/19235#19235: Admin actions displayed as buttons instead of drop-down listSat, 03 Nov 2012 16:05:15 GMTMarijonas<p>
My suggestion is to show admin actions as buttons when the number of actions is small (eg. less than 4, but configurable).
Pros:
</p>
<ul><li>UI would be sleeker;
</li><li>Easier to discover custom actions (removes the need to click the combobox only to find out what actions are available);
</li><li>Reduces the number of clicks needed from three (expand, pick, Go) to one;
</li><li>Drop-down menu would be shown if there are many actions, so the UI would not be cluttered with buttons.
</li></ul><p>
How it could look:
<a style="padding:0; border:none" href="https://code.djangoproject.com/attachment/ticket/19235/old.png"><img src="https://code.djangoproject.com/raw-attachment/ticket/19235/old.png" /></a>
<a style="padding:0; border:none" href="https://code.djangoproject.com/attachment/ticket/19235/new.png"><img src="https://code.djangoproject.com/raw-attachment/ticket/19235/new.png" /></a>
</p>
Resultshttps://code.djangoproject.com/ticket/19235#changeloghttps://code.djangoproject.com/ticket/19255
https://code.djangoproject.com/ticket/19255#19255: BaseGenericInlineFormSet runs validation methods before linking form instances to their related objectTue, 06 Nov 2012 09:24:36 GMTBouke Haarsma<p>
Given this model:
</p>
<pre class="wiki">class Model(models.Model):
content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
object = generic.GenericForeignKey()
def clean(self):
assert self.object_id
assert self.object
</pre><p>
and this admin:
</p>
<pre class="wiki">class ModelInline(generic.GenericStackedInline):
model = Model
</pre><p>
When saving a new <code>Model</code>, the assertion will fail. The object will not be linked, nor will the object_id be available to the clean function. This is because the fields are excluded from the formset and the values are set through the generic InlineAdmin, see this excerpt:
</p>
<pre class="wiki">generic.py:412
def save_new(self, form, commit=True):
# Avoid a circular import.
from django.contrib.contenttypes.models import ContentType
kwargs = {
self.ct_field.get_attname(): ContentType.objects.get_for_model(self.instance).pk,
self.ct_fk_field.get_attname(): self.instance.pk,
}
new_obj = self.model(**kwargs)
return save_instance(form, new_obj, commit=commit)
</pre><p>
To hack around this issue, the forms and formsets involved should not cache the validation result. The clean function should then validate the value if it is present (the second time when cleaning). The hack is quite ugly and requires a lot of coding. It should be possible to easily validate the newly related-to foreign key object.
</p>
Resultshttps://code.djangoproject.com/ticket/19255#changeloghttps://code.djangoproject.com/ticket/19515
https://code.djangoproject.com/ticket/19515#19515: Increase the max_length of Redirect.old_path/new_pathMon, 24 Dec 2012 17:40:33 GMTs.shanabrook@…<p>
In <code>django.contrib.redirects</code> the the <code>old_path</code> and <code>new_path</code> have <code>max_length=200</code>. This presents problems when either of the paths has a longer length than 200. <code>URLField</code> used to have a <code>max_length=200</code>, but this was resolved <a class="changeset" href="https://code.djangoproject.com/changeset/1477/">[1477]</a> and isn't even applicable, since the path fields use <code>CharField</code>s, not <code>URLfield</code>s.
</p>
<p>
I would recommend a <code>max_length=2000</code>. URL's with a length over 2000 are <a class="ext-link" href="http://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url"><span class="icon">​</span>not as well supported</a>. However since <a class="ext-link" href="https://docs.djangoproject.com/en/dev/ref/databases/#character-fields"><span class="icon">​</span>database enforcement of CharFields in MySQL is limited to 255 characters</a>, the fields have to be also changed to <code>TextField</code>s.
</p>
Resultshttps://code.djangoproject.com/ticket/19515#changeloghttps://code.djangoproject.com/ticket/19528
https://code.djangoproject.com/ticket/19528#19528: CachedFilesMixin does not rewrite rules for css selector with pathThu, 27 Dec 2012 12:48:07 GMTmike@…<p>
Using CachedFilesMixin we'll have paths like this
<code>&lt;img alt="True" src="/media/static/admin/img/icon-yes.0596085e212f.gif"&gt;</code>
after template rendering, but an unmodified selector:
<code>img[src$="admin/img/icon-yes.gif"]</code> in processed stylesheet.
</p>
<p>
This happens because CachedFilesMixin.patterns does not contain a rule like this <code>"""(img\[src[\^\$\*]{0,1}=\s*["']\s*(.*?)["'])"""</code> to match against and actually can not deal with <code>^=|$=|*=</code> operators. I am not sure how such paths can be properly processed, though.
</p>
Resultshttps://code.djangoproject.com/ticket/19528#changeloghttps://code.djangoproject.com/ticket/19580
https://code.djangoproject.com/ticket/19580#19580: Unify reverse foreign key and m2m unsaved model queryingTue, 08 Jan 2013 19:24:27 GMTAnssi Kääriäinen<p>
Currently when querying unsaved reverse relations the behavior differs.
</p>
<p>
Using model:
</p>
<pre class="wiki">class Foo(models.Model):
fk = models.ForeignKey('self', related_name='fk_rev')
m2m = models.ManyToManyField('self')
</pre><p>
and test case:
</p>
<pre class="wiki">print(Foo().fk_rev.all())
print(Foo().m2m.all())
</pre><p>
We get [] from the first filter, but an error
</p>
<pre class="wiki">ValueError: "&lt;Foo: Foo object&gt;" needs to have a value for field "from_foo" before this many-to-many relationship can be used.
</pre><p>
from the second filter.
</p>
<p>
So, m2m fields can't be filtered if the object isn't saved, but reverse fk fields can be filtered.
</p>
<p>
There is a (slightly stale) patch for <a class="closed ticket" href="https://code.djangoproject.com/ticket/17541" title="#17541: Bug: Unexpected ForeignKey Behavior with self.pk == None (closed: fixed)">#17541</a> which makes fk fields and m2m fields work consistently. The changes in behavior are:
</p>
<pre class="wiki">* Nullable many-to-many and foreign key relations will return an empty
queryset when the relation field is null. For many-to-many this was
previously an error (no change for foreign keys).
* Trying to add objects to a foreign key relation when the relation field
is null is now an error (no change for m2m).
* Trying to use a relation of any kind when the object isn't saved is now
an error (no change for m2m).
</pre><p>
I think we can squeeze these changes in as bug-fixes. These are slight backwards compatibility changes, but to me it seems that almost always the changes will be visible only in code that isn't working as intended. If these are seen as something likely breaking working code, then I don't see any way to make the APIs consistent.
</p>
<p>
The <a class="closed ticket" href="https://code.djangoproject.com/ticket/17541" title="#17541: Bug: Unexpected ForeignKey Behavior with self.pk == None (closed: fixed)">#17541</a> patch is available from: <a class="ext-link" href="https://github.com/akaariai/django/compare/ticket_17541"><span class="icon">​</span>https://github.com/akaariai/django/compare/ticket_17541</a>
</p>
Resultshttps://code.djangoproject.com/ticket/19580#changeloghttps://code.djangoproject.com/ticket/19755
https://code.djangoproject.com/ticket/19755#19755: Incremental filterWed, 06 Feb 2013 14:13:35 GMTpaulox@…<p>
Would be a good feature to have filter's value that change incrementally when user select one of them.
</p>
<p>
I try to explain with an example:
</p>
<pre class="wiki">class Person(models.Model):
name = models.CharField()
hair_color = models.CharField()
eye_color = models.CharField()
class PersonAdmin(admin.ModelAdmin):
list_filter = ["hair_color", "eye_color"]
</pre><p>
At first I'll see all hair color and eye color values in the filter.
</p>
<p>
When I select an hair color value from the filter I'll see only person with that hair color.
</p>
<p>
I would view in the eye color filter only distinct values of eye colors of person that have hair color I selected from the filter.
</p>
Resultshttps://code.djangoproject.com/ticket/19755#changeloghttps://code.djangoproject.com/ticket/19898
https://code.djangoproject.com/ticket/19898#19898: Document why/when of class-based viewsSat, 23 Feb 2013 18:41:29 GMTSteven Cummings<p>
The documentation for class-based views is getting better, but it's missing an introductory discussion of why and when you use them. Specifically, the goals of such a narrative should be:
</p>
<ul><li>Practical context for choosing CBVs vs. FBVs
<ul><li>Usage patterns appropriate to class-based views
</li><li>List of helpful, concrete decision points from the above discussion
</li></ul></li></ul><p>
Hopefully this can be something that people point to for diffusing absolutist arguments for CBVs or FBVs, and the community can start to agree when each is right (a bit of a grandiose goal, yes, but it should be possible).
</p>
<p>
New documentation that may arise out of the above needs:
</p>
<ul><li>How to test class-based views (and comparison with testing FBVs)
</li></ul><p>
Ticket <a class="assigned ticket" href="https://code.djangoproject.com/ticket/19227" title="#19227: Cleanup/optimization: Reorganize method flowchart for class based generic views to tree (assigned)">#19227</a> aims to provide visualizations code flows in class-based views and so may interact with some of the changes made on this ticket.
</p>
Resultshttps://code.djangoproject.com/ticket/19898#changeloghttps://code.djangoproject.com/ticket/20081
https://code.djangoproject.com/ticket/20081#20081: Minimize the risk of SECRET_KEY leaksMon, 18 Mar 2013 21:08:53 GMTJacob<p>
<strong>Paul:</strong>
</p>
<p>
We should consider generating it on the fly something like the way Horizon does:
<a class="ext-link" href="https://github.com/openstack/horizon/blob/master/horizon/utils/secret_key.py"><span class="icon">​</span>https://github.com/openstack/horizon/blob/master/horizon/utils/secret_key.py</a>
</p>
<p>
The things we lose when the secret key changes (sessions and password reset links IIRC) are generally per-deployment specific anyway. There's still a lot of bikeshedding to be found behind that issue (should production servers have the ability to write this file), but it's not a bad approach for those same users who commit their secret keys to their public github repos.
</p>
<p>
<strong>Jacob:</strong>
</p>
<p>
Oh this is neat! So basically when the server starts up it writes out
a secret key file if it one doesn't already exist? I like it, seems
like a really good thing to do in core. Security-by-default and all
that.
</p>
<p>
How does this handle multiple web servers, though? Seems like if you
weren't careful you'd end up with differing secrets across your web
nodes, bad news. Couldn't we do something similar but store the key in
the database? That seems like it wouldn't be any more or less secure
than the filesystem, and would solve N=1 problems.
</p>
<p>
<strong>Paul:</strong>
</p>
<p>
Yeah, the multiple servers deployment its downside and the reason I originally objected to including it in Horizon. What it does is bump the user-facing issue (you have to deal with and understand a secret key) a bit further along the line. I'd be willing to guess that a majority of Django sites that leak the secret key fall into the N=1 category, or would do the correct thing WRT secret key if it weren't so easy to commit to the repo and was a specific action they had to take when N &gt; 1. The downside of course is that there will always be a learning curve.
</p>
<p>
I'm -1 on storing the key in the database - databases tend to be easier to compromise than file systems, and people tend to be lazy about the security of their DB backups.
</p>
Resultshttps://code.djangoproject.com/ticket/20081#changeloghttps://code.djangoproject.com/ticket/20122
https://code.djangoproject.com/ticket/20122#20122: Pluralize filter sometimes returns singular form instead of an empty string for invalid inputsSun, 24 Mar 2013 09:05:12 GMTAymeric Augustin<p>
Filters are documented to return either their input unchanged, or the empty string, whatever makes most sense, when they're used incorrectly. The <code>pluralize</code> filter returns the empty string in such cases, for instance when it receives more than two forms (singular, plural).
</p>
<p>
However, it returns the singular form instead of the empty string when it's passed an object that isn't a number, a string or a list.
</p>
<p>
Failing test case:
</p>
<pre class="wiki">--- a/tests/defaultfilters/tests.py
+++ b/tests/defaultfilters/tests.py
@@ -622,6 +622,9 @@ class DefaultFiltersTests(TestCase):
self.assertEqual(pluralize(2,'y,ies'), 'ies')
self.assertEqual(pluralize(0,'y,ies,error'), '')
+ def test_pluralize_error(self):
+ self.assertEqual(pluralize(object, 'y,ies'), '')
+
def test_phone2numeric(self):
self.assertEqual(phone2numeric_filter('0800 flowers'), '0800 3569377')
</pre><p>
I understand that the implementation is crafted to avoid <code>isinstance</code> checks, but in this case we really want different logic depending on the type of the input. I think the filter should be rewritten with the following pseudo-code:
</p>
<pre class="wiki">if the value is a number:
return singular if value is 1 else plural
if the value is a string:
return singular if value is '1' else plural
if the value has a length (needs a try/except TypeError):
return singular if length is 1 else plural
return ''
</pre><p>
I discovered this while working on <a class="closed ticket" href="https://code.djangoproject.com/ticket/16723" title="#16723: Bug: Pluralize filter shouldn't pluralize decimal/float values between 1 and 2 (closed: invalid)">#16723</a>.
</p>
Resultshttps://code.djangoproject.com/ticket/20122#changeloghttps://code.djangoproject.com/ticket/20205
https://code.djangoproject.com/ticket/20205#20205: PositiveIntegerfield does not handle empty values wellFri, 05 Apr 2013 16:26:37 GMTanonymous<p>
When using a model PositiveIntegerField with blank=True and null=True, <em> (empty string) is not allowed as a blank response value. An extra manual step seems needlessly necessary to convert an empty string (say, received from a form) to convert to python None value. Shouldn't this be fixed in to_get_prep_value()? This is usually not the case for CharFields, TextFields or some of the other model fields. Here is the exception:
</em></p>
<pre class="wiki">Exception Value:
invalid literal for int() with base 10: ''
Exception Location: .../django/db/models/fields/__init__.py in get_prep_value, line 991
</pre><p>
It seems an update to IntegerField's get_prep_value or to_python may help.
</p>
Resultshttps://code.djangoproject.com/ticket/20205#changeloghttps://code.djangoproject.com/ticket/20238
https://code.djangoproject.com/ticket/20238#20238: Support multiple open connections in LiveServerTestCaseWed, 10 Apr 2013 19:17:19 GMTjwxiao@…<p>
Run a selenium test with LiveServerTestCase. Django starts StoppableWSGIServer. The StoppableWSGIServer is not multithread support. When the codes to be tested call urllib.urlopen to the same server (ie: StoppableWSGIServer) the selenium test will hang and fail because of time-out.
</p>
Resultshttps://code.djangoproject.com/ticket/20238#changeloghttps://code.djangoproject.com/ticket/20287
https://code.djangoproject.com/ticket/20287#20287: BaseContext (and it's subclasses) lack emulation of dictionary items()Thu, 18 Apr 2013 19:52:24 GMTKeryn Knight <django@…><p>
Given the Context usually behaves like a dictionary (though underlying it is obviously also a stack), I was somewhat surprised that it has no <code>items()</code> nor <code>iteritems()</code> methods that would allow it to be iterated as one might expect to, though it does have an <code>__iter__()</code> method, which could probably be used if this has any merit.
</p>
Resultshttps://code.djangoproject.com/ticket/20287#changeloghttps://code.djangoproject.com/ticket/20313
https://code.djangoproject.com/ticket/20313#20313: AnonymousUser should follow custom User implementationWed, 24 Apr 2013 12:49:57 GMTthinkingpotato@…<p>
Introducing custom User classes opened a few new options for handling authorization logic, e.g.:
</p>
<pre class="wiki">self.request.user.has_purchased(object)
</pre><p>
or as @akaariai mentioned:
</p>
<pre class="wiki">request.user.has_role_in_org(some_org)
</pre><p>
Without being able to define custom AnonymousUser class that follows User implementation this will not work.
</p>
<p>
There are some ideas on how to solve that, and the ones discussed are:
</p>
<ul><li>defining <code>anonymous_user_class</code> on <code>UserClass</code> (@akaariai)
</li><li>merging <code>User</code> and <code>AnonymousUser</code> (@apollo13)
</li></ul><p>
The current dirty patch uses the same approach as with <code>get_user_model()</code>:
</p>
<ul><li>django.contrib.auth.get_anonymous_model
</li><li>django.conf.global_settings.AUTH_ANONYMOUS_MODEL
</li></ul><p>
and changes in:
</p>
<ul><li>django.contrib.auth.context_processors
</li><li>django.db.models.sql.where.WhereNode
</li></ul>Resultshttps://code.djangoproject.com/ticket/20313#changeloghttps://code.djangoproject.com/ticket/20347
https://code.djangoproject.com/ticket/20347#20347: Add an absolute_max parameter to formset_factoryFri, 03 May 2013 12:07:19 GMTCarsten Fuchs<p>
The documentation at <a class="ext-link" href="https://docs.djangoproject.com/en/1.5/topics/forms/formsets/#limiting-the-maximum-number-of-forms"><span class="icon">​</span>https://docs.djangoproject.com/en/1.5/topics/forms/formsets/#limiting-the-maximum-number-of-forms</a> seems to indicate (if I understood it correctly) that the purpose of the <code>max_num</code> parameter is to prevent that someone sends a manipulated, excessively large value in the hidden form field that states the number of (extra) forms that are submitted, whereas it is not (directly) related to the number of forms that are <em>actually</em> POSTed, or initialized via parameter <code>initials</code>.
</p>
<p>
However, following the example at that page, with <code>MyInitials</code> being a list of e.g. 1500 initial values and <code>request.POST</code> containing more than 1500 formsets:
</p>
<div class="wiki-code"><div class="code"><pre><span class="o">&gt;&gt;&gt;</span> ArticleFormSet <span class="o">=</span> formset_factory<span class="p">(</span>ArticleForm<span class="p">,</span> extra<span class="o">=</span><span class="mi">0</span><span class="p">)</span>
<span class="o">&gt;&gt;&gt;</span> formset1 <span class="o">=</span> ArticleFormSet<span class="p">(</span>initial<span class="o">=</span>MyInitials<span class="p">)</span>
<span class="o">&gt;&gt;&gt;</span> formset2 <span class="o">=</span> ArticleFormSet<span class="p">(</span>request<span class="o">.</span>POST<span class="p">)</span>
</pre></div></div><p>
Now, accessing <code>formset1.forms[1000]</code> throws an IndexError exception.
</p>
<p>
The <code>max_num</code> is at its default value of 1000, but in the above context, it is not expected that <code>formset1</code> or <code>formset2</code> is reduced to <code>max_num</code> forms -- I'd have expected each to have the full number of forms as initialized.
</p>
<p>
Related thread at django-users: <a class="ext-link" href="http://thread.gmane.org/gmane.comp.python.django.user/152946"><span class="icon">​</span>http://thread.gmane.org/gmane.comp.python.django.user/152946</a>
</p>
Resultshttps://code.djangoproject.com/ticket/20347#changeloghttps://code.djangoproject.com/ticket/20372
https://code.djangoproject.com/ticket/20372#20372: using registration/logged_out.html template overrides admin logoutTue, 07 May 2013 16:41:18 GMTtomerz@…<p>
Hi
</p>
<p>
I created registration/login.html and registration/logged_out.html templates to handle my site login/logout using the provided auth views login/logout. While the admin app login using admin/login.html, it logouts using registration/logged_out.html. So, having my own registration/logged_out.html overrides that of the admin app.
</p>
Resultshttps://code.djangoproject.com/ticket/20372#changeloghttps://code.djangoproject.com/ticket/20423
https://code.djangoproject.com/ticket/20423#20423: Template renderer does not parse numeric variablesThu, 16 May 2013 20:50:12 GMTantonio@…<p>
Currently a Variable is defined, according to the django template <a class="ext-link" href="https://docs.djangoproject.com/en/dev/ref/templates/api/"><span class="icon">​</span>manual</a>, as :
</p>
<p>
Variable names consist of any combination of alphanumeric characters and the underscore ("_").
</p>
<p>
If a variable is composed of numbers only, it will not get its context data correctly, coming across as an int. This patch assigns the appropriate context data to the Variable class when it encounters an integer.
</p>
<p>
Here's the current behavior:
</p>
<p>
from django.template.base import Template
from django.template.base import Context
t = Template("{{ 123 }}")
t.render(Context())
</p>
<p>
u'123'
</p>
<p>
t = Template("{{ foo }}")
t.render(Context({"foo":"bar"}))
</p>
<p>
u'bar'
</p>
Resultshttps://code.djangoproject.com/ticket/20423#changeloghttps://code.djangoproject.com/ticket/20434
https://code.djangoproject.com/ticket/20434#20434: Have a template tag grammar instead of handling token/parser for every tag, and make it possible to introspect the grammar.Sat, 18 May 2013 10:40:16 GMTjonathanslenders<p>
Right now, if people use @register.simpletag (or assignment_tag/inclusion_tag), a compiled parser function will be registered in the library.tags mapping.
</p>
<p>
This however, is insufficient, if you need to do some introspection on the available template tags. I'd like to know for instance which template tags in module X are an instance of simpletag and would thus create a SimpleNode.
</p>
<p>
Right now, we are unable to accurately build a real AST from the template without manually defining which templatetags behave in which way. This is also required for AST transformations, like template compression and such.
</p>
<p>
I guess, it would be great to encourage people to always use @register.simpletag or anything that uses the built-in Node classes of Django. We can't force that, but it has a lot of advantages.
</p>
Resultshttps://code.djangoproject.com/ticket/20434#changeloghttps://code.djangoproject.com/ticket/20456
https://code.djangoproject.com/ticket/20456#20456: Easier unit testing for class-based viewsSun, 19 May 2013 09:57:25 GMTBenoît Bryon<p>
When django users create class-based views, they create custom code. Testing this code matters. Writing unit tests for the custom code (and only for the custom code) is important.
</p>
<p>
As of Django 1.5, the easiest way to test class-based views is using the builtin test client. But it performs integration tests, i.e. involves middlewares, URL resolvers, decorators...
It is also quite easy to use django.test.RequestFactory and as_view() classmethod. But, since as_view() returns a function, the tests can only check the response. It means the class-based views are tested as a system.
</p>
<p>
It seems that writing unit tests is possible, i.e. we can write unit tests for class-based views methods.
There is at least one technique which was presented at <a class="wiki" href="https://code.djangoproject.com/wiki/DjangoCon">DjangoCon</a> Europe 2013 Warsaw:
</p>
<ul><li><a class="ext-link" href="http://tech.novapost.fr/static/images/slides/djangocon-europe-2013-unit-test-class-based-views.html"><span class="icon">​</span>http://tech.novapost.fr/static/images/slides/djangocon-europe-2013-unit-test-class-based-views.html</a>
</li><li><a class="ext-link" href="http://tech.novapost.fr/django-unit-test-your-views-en.html"><span class="icon">​</span>http://tech.novapost.fr/django-unit-test-your-views-en.html</a>
</li></ul><p>
The recipe mentioned above seems to work (to be confirmed). But wouldn't be better if the recipe was documented in Django's documentation (<a class="ext-link" href="https://docs.djangoproject.com/en/1.5/topics/testing/advanced/"><span class="icon">​</span>https://docs.djangoproject.com/en/1.5/topics/testing/advanced/</a> I guess) and tools (setup_view) were builtin Django?
</p>
<p>
Note: perhaps, it would be even better if setup_view() is not a standalone function but is a method of View class. Something like as_view(), but which returns an instance.
</p>
Resultshttps://code.djangoproject.com/ticket/20456#changeloghttps://code.djangoproject.com/ticket/20487
https://code.djangoproject.com/ticket/20487#20487: oracle: case mixup causes ORA-00918: column ambiguously defined errorThu, 23 May 2013 14:50:54 GMTCharlie.Tang@…<p>
a model's fields, which have a common related model, led to the issue.
</p>
<p>
Here is an example:
</p>
<pre class="wiki">class Institution(models.Model):
name = models.CharField('full name', max_length=50)
class Personel(models.Model):
institution = models.ForeignKey(Institution)
class Protocol(models.Model):
Institution = models.ForeignKey('Institution', blank=True, null=True)
class StudyAssignment(models.Model):
personel = models.ForeignKey(Personel)
protocol = models.ForeignKey(Protocol)
</pre><p>
which generated sql
</p>
<pre class="wiki">SELECT *
FROM
( SELECT ROWNUM AS "_RN", "_SUB".*
FROM
( SELECT "STUDY_ASSIGNMENT"."ID", "STUDY_ASSIGNMENT"."PERSONEL_ID", "STUDY_ASSIGNMENT"."PROTOCOL_ID", "PERSONEL"."ID" AS Col3
, "PERSONEL"."INSTITUTION_ID"
, "INSTITUTION"."ID" AS Col5, "INSTITUTION"."NAME", "PROTOCOL"."ID" AS Col7
, "PROTOCOL"."INSTITUTION_ID"
, T5."ID" AS Col9, T5."NAME" AS Col10
FROM "STUDY_ASSIGNMENT"
INNER JOIN "PERSONEL" ON ("STUDY_ASSIGNMENT"."PERSONEL_ID" = "PERSONEL"."ID")
INNER JOIN "INSTITUTION" ON ("PERSONEL"."INSTITUTION_ID" = "INSTITUTION"."ID")
INNER JOIN "PROTOCOL" ON ("STUDY_ASSIGNMENT"."PROTOCOL_ID" = "PROTOCOL"."ID")
INNER JOIN "INSTITUTION" T5 ON ("PROTOCOL"."INSTITUTION_ID" = T5."ID")
ORDER BY "STUDY_ASSIGNMENT"."ID" DESC
) "_SUB"
WHERE ROWNUM &lt;= 21
)
WHERE "_RN" &gt; 0;
</pre><p>
To call model StudyAssignment through django admin. Both <strong>"PERSONEL"."INSTITUTION_ID"</strong><em></em> and <strong>"PROTOCOL"."INSTITUTION_ID"</strong> led to the issue.
</p>
Resultshttps://code.djangoproject.com/ticket/20487#changeloghttps://code.djangoproject.com/ticket/20629
https://code.djangoproject.com/ticket/20629#20629: Admonitions in custom User model documentation may be scaring off usersThu, 20 Jun 2013 00:12:05 GMTRussell Keith-Magee<p>
<a class="ext-link" href="https://groups.google.com/d/msg/django-users/0DuvxCdxKQ4/P6qsO7mtL5AJ"><span class="icon">​</span>Evan Stone on django-users</a> indicated that he was initially hesitant to use custom User models because the documentation made it sound like it was going to be painful. Specifically, he identified the following pieces of documentation:
</p>
<ol><li>"Think carefully before handling information not directly related to authentication in your custom User Model."
</li></ol><ol start="2"><li>"It may be better to store app-specific user information in a model that has a relation with the User model. That allows each app to specify its own user data requirements without risking conflicts with other apps...."
</li></ol><ol start="3"><li>"One limitation of custom User models is that installing a custom User model will break any proxy model extending User. ..."
</li></ol><p>
and
</p>
<ol start="4"><li>"Another limitation of custom User models is that you can’t use django.contrib.auth.get_user_model() as the sender or target of "
</li></ol><p>
Points 1 and 2 are asking users to consider an architectural question -- do you need a custom user model at all? If you actually *are* using a username-based login system, and you just want to track some extra information about the user, the right approach may *not* be to create a custom user model.
</p>
<p>
Points 3 and 4 are pointing out known limitations. Proxy models are a problem because they use subclassing, and they will be subclassing the wrong class; signals are a problem because at the point the signal is registered, there's no guarantee that the User model has been correctly defined. There's not much we can do about (3); (4) is something that should get cleaned up when we eventually land app refactor.
</p>
<p>
The points made by the documentation are all valid, but could perhaps be made in less threatening or alarmist tones, or clarified so that they don't seem like such big problems.
</p>
Resultshttps://code.djangoproject.com/ticket/20629#changeloghttps://code.djangoproject.com/ticket/20712
https://code.djangoproject.com/ticket/20712#20712: staticfiles and serving post-processed files through development serverSun, 07 Jul 2013 04:46:45 GMTMitar<p>
<a class="ext-link" href="https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/"><span class="icon">​</span>staticfiles app</a> allows custom storage. I have implemented a storage which <a class="ext-link" href="https://github.com/wlanslovenija/nodewatcher/blob/98525b82e410989c033301f755b1e180b7947662/nodewatcher/core/frontend/staticfiles/storage.py"><span class="icon">​</span>automatically compiles .scss files into .css files</a>. The issue that such post-processed files are not served when using staticfiles development server. I have to override <code>runserver</code> with core one to be able to serve the files I collect manually.
</p>
<p>
I think it would be useful to support such use cases as it would open window for further integration of static files (like bundling JavaScript into one and so on). While some are useful just for production, some are necessary while development as well.
</p>
Resultshttps://code.djangoproject.com/ticket/20712#changeloghttps://code.djangoproject.com/ticket/20749
https://code.djangoproject.com/ticket/20749#20749: Add validation for type of Field.choices argumentsMon, 15 Jul 2013 16:35:37 GMTellisd23@…<p>
If I have a model like so:
</p>
<pre class="wiki">class Program(models.Model):
STATUS_CHOICES = (
(1, 'Inactive'),
(2, 'Active'),
)
status = models.CharField(choices=STATUS_CHOICES)
</pre><p>
And I try get_status_display(), I will get '1' or '2' as the output rather than 'Inactive' or 'Active'. Django silently coerces the type of the choices upon saving, but does not give an indicator upon retrieval that the choice was not found. _get_FIELD_display in db/models/base.py attempts to pull the value from the choices, but since python does not see int and str keys as equivalent, it does not find the value; instead, it defaults to the value in the database.
</p>
<p>
The end-user solution is to make sure all types are correct, but this could cause confusion for a newbie since this is all done without warning.
</p>
<p>
I see a few possible solutions:
</p>
<blockquote>
<p>
1) warn the user when creating a choice field that is not of the same type as the model.
2) warn the user when get_FOO_display is called but no value is found.
3) coerce the keys to strings before attempting to retrieve in get_FOO_display. I'm not sure if this would have other implications.
</p>
</blockquote>
Resultshttps://code.djangoproject.com/ticket/20749#changeloghttps://code.djangoproject.com/ticket/20752
https://code.djangoproject.com/ticket/20752#20752: Error signals are not reliable, especially when dealing with database errorsMon, 15 Jul 2013 19:45:47 GMTtal@…<p>
In core.handlers.base, unhandled exceptions are processed as such:
</p>
<pre class="wiki"> 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())
</pre><p>
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):
</p>
<pre class="wiki"> for receiver in self._live_receivers(_make_id(sender)):
response = receiver(signal=self, sender=sender, **named)
responses.append((receiver, response))
return responses
</pre><p>
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.
</p>
<p>
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
</p>
<pre class="wiki">def _rollback_on_exception(**kwargs):
from django.db import transaction
for conn in connections:
try:
transaction.rollback_unless_managed(using=conn)
except DatabaseError:
pass
</pre><p>
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.
</p>
<p>
Thoughts?
</p>
Resultshttps://code.djangoproject.com/ticket/20752#changeloghttps://code.djangoproject.com/ticket/20757
https://code.djangoproject.com/ticket/20757#20757: A more Object-Oriented URLResolverWed, 17 Jul 2013 17:58:09 GMTFlavio Curella<p>
Currently, the <code>RegexURLResolver</code> is populated using tuples.
</p>
<p>
Because of that, code that tries to inspect the resolver will end up containg awkward indexing like this (semplified code for clarity's sake):
</p>
<pre class="wiki">def get_urlformat(urlname):
"""
Given a URL name, returns the URL as a string suitable for string.format.
Example::
urlpatterns = patterns('',
url(r'^extra/(?P&lt;extra&gt;\w+)/$', empty_view, name="named-url2"),
)
&gt;&gt;&gt; get_urlformat('named-url2')
'extra/%(extra)s/'
"""
resolver = get_resolver()
return resolver.reverse_dict[urlname][0][0][0]
</pre><p>
My proposal is to replace tuples with a tuple-like object whose elements can be accessed by using attribute names. That way, the above method could become:
</p>
<pre class="wiki">def get_urlformat(urlname):
"""
Given a URL name, returns the URL as a string suitable for string.format.
Example::
urlpatterns = patterns('',
url(r'^extra/(?P&lt;extra&gt;\w+)/$', empty_view, name="named-url2"),
)
&gt;&gt;&gt; get_urlformat('named-url2')
'extra/%(extra)s/'
"""
resolver = get_resolver()
urlbit = resolver.reverse_dict[urlname].urlbits[0]
return urlbit.format
</pre><p>
I realize this is mostly aesthetic, and there could be performance implications since the URLResolver is probably the most hit codepath, so I appreciate every kind of opinion.
</p>
<p>
The attached patch is still a draft, it definitely needs more extensive test coverage, but it's a start to get the idea.
</p>
Resultshttps://code.djangoproject.com/ticket/20757#changelog