Django: Ticket Queryhttps://code.djangoproject.com/query?status=!closed&cc=~jezdez&order=cc
The Web framework for perfectionists with deadlines.en-USDjangohttps://www.djangoproject.com/s/img/site/hdr_logo.gifhttps://code.djangoproject.com/query?status=!closed&cc=~jezdez&order=cc
Trac 1.0.2https://code.djangoproject.com/ticket/7497
https://code.djangoproject.com/ticket/7497#7497: AppAdmin class for customizing app listing in admin indexWed, 18 Jun 2008 18:03:33 GMTmrts<p>
See <a class="ext-link" href="http://code.djangoproject.com/wiki/DjangoSpecifications/NfAdmin/FlexibleAppHandling"><span class="icon">​</span>http://code.djangoproject.com/wiki/DjangoSpecifications/NfAdmin/FlexibleAppHandling</a> for details.
</p>
<p>
This <strong>supplements</strong> the <tt>app</tt> directive.
</p>
<p>
As discussed with <tt>brosner</tt> and <tt>jkocherhans</tt> in #django-dev:
</p>
<pre class="wiki">&lt;brosner&gt; it looks reasonable, but haven't spent much time thinking about it
&lt;jkocherhans&gt; mrts: I think this is clearly backwards incompatible with the current nfa api and has to go in pre 1.0 if it goes in at all
&lt;jkocherhans&gt; I'm a big -1 on the order attribute and -0 on models (maybe just a different syntax), but the other stuff seems reasonable
&lt;mrts&gt; jkocherhans: what's wrong with ordering?
&lt;jkocherhans&gt; it just feels like the wrong place to specify it
&lt;jkocherhans&gt; it's a global issue, and an issue any particular app should handle
&lt;mrts&gt; my use case: I have a lot of functionality exposed to somewhat dumb users
&lt;mrts&gt; and they have trouble finding the right bits in the admin interface
ordering is only used in context of admin index
I would like to put the important apps to top and collapse the rest
&lt;jkocherhans&gt; exactly. what should 3rd party apps put there? therein lies my objection.
&lt;mrts&gt; well, I'd say decouple admin from models (as nfa already does) and don't specify any admin options at all -- users are free to customize things with AppAdmin
&lt;jkocherhans&gt; I guess not if using a AppAdmin class is optional. I was originally thinking it would replace model registration with an admin site.
&lt;mrts&gt; jkocherhans: yeah, that's what I kinda meant... it looks more coherent this way
jkocherhans: and it may solve some of the issues register() currently has
&lt;jkocherhans&gt; mrts: I'm gonna have to let it sit for awhile. I'm trying to think of what else an AdminApp class would do besides being a coathanger for a few attributes, nothing is coming to mind.
&lt;mrts&gt; jkocherhans: but jezdez has a point -- it would also provide easy bridging for app instances
</pre><p>
Example syntax follows.
</p>
<pre class="wiki">class BarModelAdmin(admin.ModelAdmin):
description = 'A bar is a bar is a bar'
...
class FooAppAdmin(admin.AppAdmin):
app = settings.INSTALLED_APPS[0]
name = "Foo" # overrides app().name
description = "An application that does foo"
style = {'classes' : ('collapse',)}
order = 1
models = ( # model order in this list determines their display order in app block
(BarModel, BarModelAdmin),
(BazModel, None), # use default ModelAdmin, don't show description
)
admin.site.register(FooAppAdmin) # no need for the tedious for model in [A, B, C, D]: admin.site.register(model)
</pre>Resultshttps://code.djangoproject.com/ticket/7497#changeloghttps://code.djangoproject.com/ticket/15667
https://code.djangoproject.com/ticket/15667#15667: Implement template-based widget renderingWed, 23 Mar 2011 12:37:45 GMTbrutasse<p>
Following <a class="ext-link" href="https://groups.google.com/d/topic/django-developers/fMQnk2fAo_A/discussion"><span class="icon">​</span>this proposal on django-dev</a>, this ticket tracks the status of replacing the widgets rendering code with a template-based system.
</p>
<p>
The proposal is based on an existing implementation, <a class="ext-link" href="https://github.com/brutasse/django-floppyforms"><span class="icon">​</span>django-floppyforms</a>. The api provides several ways of extending a widget:
</p>
<ul><li>Widget.template_name: the name of the template used to render the widget
</li><li>Widget.get_context_data(): a way to inject additional context data
</li><li>Widget.get_context(name, value, attrs=None): this method calls get_context_data() and provides the basic context variables: attrs, hidden, name, required, type.
</li></ul><p>
I'm actively working on a patch and will attach it to the ticket as soon as I can so that the implementation and extension points can be discussed.
</p>
Resultshttps://code.djangoproject.com/ticket/15667#changeloghttps://code.djangoproject.com/ticket/23814
https://code.djangoproject.com/ticket/23814#23814: Documented apps refactored out of DjangoThu, 13 Nov 2014 11:13:38 GMTshabda<p>
Follow up to: <a class="closed ticket" href="https://code.djangoproject.com/ticket/23809" title="Cleanup/optimization: Update Localflavor docs (closed: wontfix)">#23809</a>
</p>
<p>
Documented apps refactored out of Django
</p>
<ul><li>comments
</li><li>localflavor
</li><li>formtools
</li></ul><p>
Remove documentation for removed apps - Localflavor
Remove documentation for formtools and point to RTD
</p>
Resultshttps://code.djangoproject.com/ticket/23814#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 GMTapollo13<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#changelog