Django: Ticket Queryhttps://code.djangoproject.com/query?status=new&status=assigned&status=reopened&keywords=~nfa-someday&order=type
The Web framework for perfectionists with deadlines.en-USDjangohttps://www.djangoproject.com/s/img/site/hdr_logo.gifhttps://code.djangoproject.com/query?status=new&status=assigned&status=reopened&keywords=~nfa-someday&order=type
Trac 1.2.2https://code.djangoproject.com/ticket/2901
https://code.djangoproject.com/ticket/2901#2901: Enable admin log display to be restricted to a specific siteWed, 11 Oct 2006 16:20:57 GMTChristopher Lenz <cmlenz@…><p>
The admin log currently only provides way to show changes across all sites. For a project with multiple sites, it'd be very nice to be able to tell the admin log template tag to only show changes to objects that either aren't associated with any site, or associated with the current (or some other specific) site.
</p>
<p>
This requires the <code>django_admin_log</code> table to be extended with a nullable <code>site_id</code> column, which would require appropriate upgrade instructions ala:
</p>
<pre class="wiki">BEGIN;
ALTER TABLE django_admin_log
ADD site_id integer NULL REFERENCES django_site (id);
COMMIT;
</pre><p>
The patch adds a method called <code>get_for_obj</code> to the <code>SiteManager</code> class, which attempts to find the site a given object is related with (either through a many-to-many, or a many-to-one relation). This function is reused in the <code>django.views.defaults.shortcut</code> function, which needs the same thing.
</p>
Resultshttps://code.djangoproject.com/ticket/2901#changeloghttps://code.djangoproject.com/ticket/4848
https://code.djangoproject.com/ticket/4848#4848: Allow inline fields to be "mixed in" with the models' own fieldsWed, 11 Jul 2007 17:59:05 GMTleifbyron<p>
In newforms-admin, it would be quite helpful to be able to specify both a models' fields and its inline models' fields in the fields tuple of the options class. This would allow inline model fields to be "mixed in" with the models' own fields on the model's admin page. There are many situations where this would be preferable to the current situation -- always having inline model fields rendered below the models' own fields.
</p>
<p>
I suggested this feature in the Django-developers group, and Adrian suggested that I open a ticket.
</p>
<p>
<a class="ext-link" href="http://groups.google.com/group/django-developers/browse_thread/thread/c54d026eb46ad375/93bebf102281bb41#93bebf102281bb41"><span class="icon">​</span>http://groups.google.com/group/django-developers/browse_thread/thread/c54d026eb46ad375/93bebf102281bb41#93bebf102281bb41</a>
</p>
Resultshttps://code.djangoproject.com/ticket/4848#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/6933
https://code.djangoproject.com/ticket/6933#6933: You cannot search with spaces if search_fields is declared with "^"Mon, 31 Mar 2008 21:52:58 GMTMartín Conte Mac Donell <Reflejo@…><p>
That is. When search_fields is declared to "starts with" you cannot perform queries with spaces.
</p>
<p>
File contrib/admin/views/main.py; Line 326:
</p>
<pre class="wiki">for bit in self.query.split():
or_queries = [models.Q(**{construct_search(field_name): bit}) for field_name in self.search_fields]
other_qs = QuerySet(self.model)
(...)
qs = qs &amp; other_qs
</pre><p>
So, if for example i'm looking for "Hey dud" query will be:
</p>
<pre class="wiki">qs.filter(field__startswith="Hey") &amp; qs.filter(field__startswith("dud"))
</pre>Resultshttps://code.djangoproject.com/ticket/6933#changeloghttps://code.djangoproject.com/ticket/5372
https://code.djangoproject.com/ticket/5372#5372: Cache inline ForeignKey optionsSun, 09 Sep 2007 21:36:10 GMTanonymousResultshttps://code.djangoproject.com/ticket/5372#changeloghttps://code.djangoproject.com/ticket/5518
https://code.djangoproject.com/ticket/5518#5518: Capitalized verbose names for modelsMon, 17 Sep 2007 01:01:45 GMTPetr Marhoun <petr.marhoun@…><p>
There is a difference between models and forms, now the preferred format is:
</p>
<div class="wiki-code"><div class="code"><pre><span class="k">class</span> <span class="nc">Contact</span><span class="p">(</span>models<span class="o">.</span>Model<span class="p">):</span>
email <span class="o">=</span> models<span class="o">.</span>CharField<span class="p">(</span>verbose_name<span class="o">=</span>_<span class="p">(</span><span class="s1">'email'</span><span class="p">))</span>
<span class="k">class</span> <span class="nc">ContactForm</span><span class="p">(</span>forms<span class="o">.</span>Form<span class="p">):</span>
email <span class="o">=</span> forms<span class="o">.</span>CharField<span class="p">(</span>label<span class="o">=</span>_<span class="p">(</span><span class="s1">'Email'</span><span class="p">))</span>
</pre></div></div><p>
Why is once 'email' and once 'Email'? I think it is quite
inconsistent.
</p>
<p>
But it is specially bad for translators. Example: I have a model with
ten fields. I use form_for_model and form_for_instance. I realize that
I need a form with seven fields from model and some new fields. So I
have to translate the fields again - gettext doesn't know that 'email'
is similar to 'Email'.
</p>
<p>
I think it should be possible (not necessary) to use capitalized
verbose names in models. It means to uncapitalized some words in admin
</p>
<ul><li>but it is possible, I do it in my personal branch.
</li></ul><p>
I thought that this kind of change should be sent to django-developers mailing list first. But there was no answer so there is a ticket.
</p>
<p>
Ticket <a class="closed ticket" href="https://code.djangoproject.com/ticket/5426" title="#5426: [newforms-admin] - uncapfirst tag and utility function (closed: wontfix)">#5426</a> is precondition for it.
</p>
<p>
I would like to create patch - if you think that it can be applied.
</p>
Resultshttps://code.djangoproject.com/ticket/5518#changeloghttps://code.djangoproject.com/ticket/6396
https://code.djangoproject.com/ticket/6396#6396: Remove customization-unfriendly admin template tagsWed, 16 Jan 2008 19:33:17 GMTkorpios<p>
The admin interface makes use of various template tags that are opaque, and make customization difficult.
</p>
<p>
An example from <code>admin/change_list.html</code>:
</p>
<pre class="wiki">{% block result_list %}{% result_list cl %}{% endblock %}
</pre><p>
This calls an <code>inclusion_tag</code> called <code>result_list</code> that is used exactly once in the admin (i.e., here); that <code>inclusion_tag</code> drops in some extra context variables before rendering <code>admin/change_list_results.html</code>. This doesn't work with the common <code>[app_label]/[object_name]/template.html</code> magic, since <code>inclusion_tag</code> sets the template names upon registration. If there's a good reason for using a template tag here, I'm not seeing it. <code>:)</code>
</p>
<p>
The attached patch pulls the template code from <code>change_list_results.html</code> into <code>change_list.html</code>, and updates the latter's context with the extra context variables from the former. I intend to start yanking out similar uses of one-off template tags as I come across them in the admin, so I'll be dropping updated patches on this ticket as I go along.
</p>
<p>
The rearranging of the functions <code>result_headers</code>, etc., is to avoid some circular import nastiness; I dropped them after <code>ChangeList</code>, which seems to make the most sense.
</p>
Resultshttps://code.djangoproject.com/ticket/6396#changelog