Sometimes a textarea field is to small for usage. I add some JavaScript and CSS to resize all textareas a little dynamically: The JS change the size in dependence text-lengthen. You should store this snippet into a file like this: templates_django/admin/base_site.html
Peeping middleware, that replaces active user to another one for current http request. Admin permissions required to activate, so you can place this snippet even on the production server. Very useful for debugging purposes. Wish it to be part of Django. How to use: Put this middleware after all other middlewares in the list. Then just add ?as_user=username or &as_user=username to the url, where username is the name of user whose views you want to see.
Have you ever needed to customize permissions, for example, allow only some fields for editing by some group of users, display some fields as read-only, and some to hide completely? FieldLevelPermissionsAdmin class does this for newforms-admin branch. Not tested well yet (>100 LOC!). You typically would like to use it this way: class MyObjectAdmin(FieldLevelPermissionsAdmin): def can_view_field(self, request, object, field_name): """ Boolean method, returning True if user allowed to view field with name field_name. user is stored in the request object, object is None only if object does not exist yet """ ...your code... def can_change_field(self, request, object, field_name): """ Boolean method, returning True if user allowed to change field with name field_name. user is stored in the request object, object is None only if object does not exist yet """ ...your code... def queryset(self, request): """ Method of ModelAdmin, override it if you want to change list of objects visible by the current user. """ mgr = self.model._default_manager if request.user.is_superuser: return mgr.all() filters = Q(creator=request.user)|Q(owner=request.user) return mgr.filter(filters)
You can switch boolean fields in the admin without editing objects Usage: ` class News(models.Model): # ... pub = models.BooleanField(_('publication'),default=True) # ... pub_switch = boolean_switch(pub) class Admin: list_display = ('id', 'pub_switch') ` Thanks for [svetlyak](http://www.djangosnippets.org/snippets/398/).
Usually, you can add links in the admin using such code: class Pingback(models.Model): #... target_uri = models.URLField( _('Target URI')) #... def admin_target(self): return '<a href="%(targ)s">%(targ)s</a>' % {'targ': self.target_uri} admin_target.short_description = _('Target URI') admin_target.allow_tags = True #... class Admin: list_display = ('id', 'admin_target') But when you have two or more url fields, such approach becomes to expensive. Follow the DRY principe and use my code in such way: # Just add this line instead of the ugly four lines **def blabla** admin_target = link('target_uri', _('Target URI'))
This method lets you define your markup language and then processes your entries and puts the HTML output in another field on your database. I came from a content management system that worked like this and to me it makes sense. Your system doesn't have to process your entry every time it has to display it. You would just call the "*_html" field in your template. Requires: Django .96 [Markdown](http://cheeseshop.python.org/pypi/Markdown/1.6 "Python Package Index: Markdown") [Textile](http://cheeseshop.python.org/pypi/textile "Python Package Index: Textile")
The models in the Site Administration screen are listed alphabetically. If you need to order them differently, say, in the order of creation of objects or some other 'workflow' criterion, you can use the instructions in this snippet.
Ever wanted to add a link or two at the end of a row in a model's change list? Say you had a model for people and a model for registrations or blog posts and you want to modify the people change list so it has a link to, say all of the registrations or blog posts for the person. Well, Django provides half of the solution already in that the example registration change_list already handles the display of all registrations tied to that person. For example, the url `/admin/registrations/registration/?person__id__exact=121` gets you to a filtered list of registrations for the person with the id of 121. This is the same url used if you use list_filter in your model definition (though setting list_filter is not required for what we're doing). Okay, so to add a link to the end of each person row in the change list, you need to create a template tag similar to "person_result_list" in the code. There, I've given an example that adds two links. Each dictionary in additional_links needs to have at least a text, sortable, and url_template attribute. The text attribute is what will display as the header to the column. url_template will be fed the id of the row object (in this example, a person id), which you can use to construct the link for each row. You could extend this if you wish, though all I ever need is the id. And the last step is to use your new template tag in a modified change_list.html in place of the default result_list tag. The example at the bottom of the code shows an example usage of the tag. Hope this makes sense and is helpful to someone!
The newforms-admin branch (to be merged by 0.97, I think) is very nice to work with, separating models from the admin. It is trivial to create an admin site that includes every app that is installed. Note that you also get all your docs for things like template tags, etc.
This adds a checkbox for each object and three buttons to a model's change list: 1. **Delete selected:** deletes the selected objects 2. **Delete shown: ** deletes all the visible objects. For example, if you perform a search or in any way filter the list, this button deletes only objects that were filtered. 3. **Delete all: ** Deletes all instances of the model, including those not shown (if looking at a filtered list). The deletes perform no confirmation -- once you hit the buttons the models are **gone**, so maybe don't use (or add a confirmation screen) for really sensitive stuff. * uses django oldforms-admin (ie 0.96) * works fine if you include a search_fields list in the Admin class * code for the view could probably be refactored a bit :)
This code will add a thumbnail image to your Model's Admin list view. The code will also generate the thumb images, so the first view may be a little slow loading. This assumes you have an **ImageField** in your Model called **image**, and the field's **upload_to** directory has a subdirectory called **tiny**. You then must add **"thumb"** to your Model's Admin **list_display**. The thumbnail images are also linked to the full size view of the image. I found this **VERY** useful... hope someone else does as well.
This is quite a hack (need to modify Django code), but relatively simple and stable. It displays various times in whichever increments and columns you specify, rather than just Midnight, Noon, Now & 6am. You can use it throughout your admin and newforms-admin code. This is a (slightly updated) copy of the ticket #1848 which wasn't included in trunk. http://code.djangoproject.com/ticket/1848
This is FieldsetForm for rendering forms with fieldsets. This is not in anyway final version of this snippet. This is preliminary version which just works. One can easilly implement the `as_ul`, `as_p` at the end with just looking the `as_table` definition. > Content developers should group information where natural and appropriate. When form controls can be grouped into logical units, use the FIELDSET element and label those units with the LEGEND element... - [Web Content Accessibility Guidelines 1.0](http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-grouping) **Notice**: Since this uses *real* fieldset elements of HTML we had to define `form.as_table` the way it *includes* the `table` element around it. **Usage in template** {{ form }} and **not** `<table>{{ form }}</table>` **Usage in view** Following usage example is for *django.contrib.flatpage*, but naturally you can use it to whatever you want. Example assumes user knows about newforms and basics to how to use `form_for_*` functions from THIS-SNIPPETS-POSITION-IN-PYTHON-PATH import form_fieldsets ... fieldsets = form_fieldsets( (None, {'fields': ('url','title','content',)} ), ("Advanced options", {'fields': ('sites', 'template_name', 'registration_required',), 'classes':'collapse'}) ) ... ... forms.models.form_for_instance(flatpage, **fieldsets) ... forms.models.form_for_model(FlatPage, **fieldsets) ... Above creates two fieldsets: 1. "None" named fieldset (meaning no name is given) with fields 'url', 'title' and 'content'. 2. "Advanced options" named fieldset with fields 'sites', 'template_name' and 'registration_required' and collapse class in place. Syntax of form_fieldsets function is identical with models `class Admin: fields = (...)`, actually you can use admins exact line here with adding it like `form_fieldsets(*FlatPage.Admin.fields)` if you prefer that, although it wrecks the point of having newforms admin, if one does identical forms as in admin part. Purpose of this is not to create identical forms as in admin but to provide easy fieldsets for all views and forms. To follow DRY principle this should be part of Django and Django's newforms-admin branch should start to use some subclassing of this. But even if the newforms-admin branch never take this in, it is more DRY than without to use this in own projects, with this in place you can forget all template hazzles defining fieldset manually. **Some "counter" statemets for having this** > **S**: "But I want to define the table tag myself in template!" **A**: Well, you understod something wrong; First of all, for example, if there is something missing from the output of this table tag, you can feel free and subclass from FieldsetForm and define own as_table. Second of all, for having own table tag there can be only one reason to that, you want extra arguments, and that is TODO, but it is also easy piece. I haven't just needed extra stuff yet so they are not implemented. > **S**: "But, oh my! (newforms) admin does this already!" **A**: For the **last time** this is not meant for only newforms admin, you can use this on **any** given view or form renderition, since currently django does not give a simple way to use that handy fieldset automation in own views. And currently (9th of April, 2007) newforms admin does not do it this way. > **S**: "But, I want to use as_p, as_ul ..." **A**: Go ahead and fix them below... Should be pretty easy stuff. > **S**: "Each model should have only one fieldsets setting." **A**: I don't believe that; even if I did that is not convincing, since there are views that are not based on models, just bunch of fields, how would you define their fieldsets if it is not defined in the form renderition at the first place? This is the right place to define fieldsets. And the point of *FieldsetForm* is not just having multiple fieldsets per model, it is about *where* and *how* to render them.
This is a very simple way to display images within the admin list view. It is not efficient in the sense that the images are being downloaded in original format, however for cases where the images are not regularly accessed it may be a straightforward option. Can also be tied into WYSIWYG editors like TinyMCE by adding an appropriate href link in the return value.
This code gives you the ability to authenticate a user by their email address instead of the username. I've also added the ability to authenticate via LDAP. Some code used from this [snippet](http://www.djangosnippets.org/snippets/74/)
241 snippets posted so far.