This ModelAdmin class sets fields for models saved in admin corresponding to the user that created the object and the user that last updated the object. Trivial for the current model, but a little more involved to make it work with inlines.
The fields still show up as drop-downs (`select`) in the admin, but I fixed that with a little jQuery:
$(function(){
$("select[id*='creator'], select[id*='updater']").each(function(){
var user = $('option:selected', this).text();
$(this).siblings('.add-another').hide();
$(this).hide();
$(this).after(user);
});
});
This could easily be subverted, but with trusted users, it makes for a quick and dirty read-only field.
I recently needed to sort a list of objects by cardinal direction clock-wise. Since this is different than alphabetical, and I didn't want to use a dictionary to map to integers, here is what I came up with.
There may be a cleaner way to do this by overriding some object methods, but I just thought I'd put this out there anyway.
I had some trouble getting other peoples code to work for AD support, so I wrote my own which authenticates against LDAP and will also use SSL and cert if required. It will also verify that an autheticated user has specific group membership before authorizing.
This will also debug to a file, which is really helpful when trying to figure out problems.
One thing that really got me when getting python-ldap to work was that you must have "ldap.set_option(ldap.OPT_REFERRALS,0)" set or any ldap search will not work.
Also, this will add group permissions to a user.
A custom model field 'ColorField' which stores a hex color value like '#FFFFFF' and shows a Javascript color picker in the admin rather than a raw text field. It is written to work with the current trunk (i.e. after newforms-admin merge).
You'll need the ColorPicker2.js file found at [www.mattkruse.com](http://www.mattkruse.com/javascript/colorpicker/combined_compact_source.html) (his license prohibits including the file here). This should be placed in the 'js' folder of your admin media.
The snippet includes a python source file which can be placed wherever you wish, and a template which by default should be placed in a folder 'widget' somewhere on your template path. You can put it elsewhere, just update the path ColorWidget.render
The custom field at present does not validate that the text is a valid hex color value, that'd be a nice addition.
If you view Django's admin pages as a convenience for experts, and so don't see the point in heavily modifying it beyond a few simple things like list_display and some ordering or filtering options, you may feel that newforms-admin makes things harder, not easier. ... Well, there's some truth to that, but it turns out that fighting newforms-admin is doomed - too much has changed to make the fight to preserve the old simplicity winnable to any useful extent, so I'm withdrawing this.
A script I wrote a little while ago to help speed up newforms-admin conversion.
From memory it works best when run from an old-forms installation, but it is still useful post-conversion. There are some features missing, but it's supposed to be a starter.
Just install this command and run:
./manange.py port2nfa > admin.py
(To install, copy the file to management/commands/port2nfa.py in an app somewhere)
- Choices are saved as the key integers.
- Admin will show the correct translation in forms.
- You can reuse the make_choices function for other choices fields.
- Bad side: bin/make_messages.py won't get the choices values automatically, you have to add them in the .po's by hand.
This adds a checkbox in the admin site that removes the reference to a file uploaded via a FileField (or ImageField). It does not delete the actual file.
I needed to be able to synchronize my LDAP users and groups to the Django database. This may not be as efficient as some might like but it works like a charm. It returns a list of messages that I pipe into request.user.messages in my template.
** Help me get better! If you vote (either way) please leave a comment if you have time and say what was good or bad. I appreciate any and all feedback. Thanks! **
I keep finding places in my apps where I need an isolated snippet of text that can periodically be changed from the admin interface. Most often it's html but sometimes it's text, javascript, or css.
Use it like so:
(Assuming this snippet lives in snippy_snip/models.py and there is a snippet named "Welcome Message" in the database)
from snippy_snip.models import snip
msg = snip("Welcome Message")
Or, you might populate a parameter hash for a template:
def showpage(request):
params = {
'welcome': snip('Welcome Message'),
'video1': snip('Video 1'),
'NavHeader': snip('Nav.SectionHeader'),
}
return render_to_response("main.html", params)
For clarity, *params* might look something like this:
welcome -> "Welcome to our site. Please use the menu on the left..."
video1 - > a YouTube snippet
NavHeader -> Some HTML which comprises the top of a navigation menu.
This is a very simple bit of code but I've found it very useful. It isn't intended for instant changes... Your snippets will cache like anything else, which may cause confusion if you expect immediate changes. And it's probably not great for a high traffic site, but for my moderate traffic sites and workgroup apps I've found it useful.
(This code was created for 0.96, but I'm working to bring it into alignment with the latest svn version of Django, see comments.)
Template tag for displaying a list of arbitrary models. Useful for life-stream kind of pages that display blog entries, links, photos etc ordered by date. [Example](http://bjornkri.com)
**Usage:** something like:
{% for object in object_list %}
{% display_excerpt object %}
{% endfor %}
Will look for *app/model_excerpt.html* by default, and fall back on a generic *display_excerpt.html*, or returns the object's string representation as a last fallback.
*display_excerpt.html* might look something like:
<a href="{{ object.get_absolute_url }}">{{ object }}</a>
Any model you throw at it should have a *get_absolute_url* and a string representation of some sort, so this gives you the bare minimum of a title and a link to a detail page.
*display_excerpt* takes an optional argument to set the template suffix. This might be handy for generating different formatting for feeds, for instance:
{% for object in object_list %}
{% display_excerpt object "feed" %}
{% endfor %}
This will look for app/model_feed.html to render the object.
Got lots of help from mattmcc on #django for this one, thanks!