Put this code and import it where you define your ModelAdmin-classes. # typical admin.py file: from django.contrib import admin from foo.bar import ReadOnlyAdminFields class MyModelAdmin(ReadOnlyAdminFields, admin.ModelAdmin): readonly = ('field1', 'field2',)
A URL field specifically for images, which can validate details about the filesize, dimensions and format of an image at a given URL, without having to read the entire image into memory. Requires [Python Imaging Library](http://www.pythonware.com/library/pil/). *4th October, 2008* - updated for 1.0 compatibility.
This is a great way to pack extra data into a model object, where the structure is dynamic, and not relational. For instance, if you wanted to store a list of dictionaries. The data won't be classically searchable, but you can define pretty much any data construct you'd like, as long as it is JSON-serializable. It's especially useful in a JSON heavy application or one that deals with a lot of javascript. **Example** (models.py): from django.db import models from jsonfield import JSONField class Sequence(models.Model): name = models.CharField(maxlength=25) list = JSONField() **Example** (shell): fib = Sequence(name='Fibonacci') fib.list = [0, 1, 1, 2, 3, 5, 8] fib.save() fib = Sequence.objects.get(name='Fibonacci') fib.list.append(13) print fib.list [0, 1, 1, 2, 3, 5, 8, 13] fib.get_list_json() "[0, 1, 1, 2, 3, 5, 8, 13]" *Note:* You can only save JSON-serializable data. Also, dates will be converted to string-timestamps, because I don't really know what better to do with them. Finally, I'm not sure how to interact with forms yet, so that realm is a bit murky.
These three classes allows you to use enumerations (choices) in more natural model-like style. You haven't to use any magic numbers to set/get field value. And if you would like to make your enumeration a full-fledged django-model, migration should be easy. Note, that you can subclass Item to add some context-specific attributes to it, such as `get_absolute_url()` method for instance. Examples are provided in the form of `doctest` in the second half of the snippet.
Daniel Roseman's snippet, updated will all fixes mentioned in the comments of the first version + some other things to make it work under Django 1.4. South, and dumpdata are working. There's an ugly int(....) at the validate function in order to cast each value as an integer before comparing it to default choices : I needed this, but if you're storing strings values, just remove the int(......) wrapper. ------------------------------------- Orginal readme Usually you want to store multiple choices as a manytomany link to another table. Sometimes however it is useful to store them in the model itself. This field implements a model field and an accompanying formfield to store multiple choices as a comma-separated list of values, using the normal CHOICES attribute. You'll need to set maxlength long enough to cope with the maximum number of choices, plus a comma for each. The normal get_FOO_display() method returns a comma-delimited string of the expanded values of the selected choices. The formfield takes an optional max_choices parameter to validate a maximum number of choices.
This replaces the html select box for a foreign key field with a link to that object's own admin page. The foreign key field (obviously) is readonly. This is shamelessly based upon the [Readonly admin fields](http://www.djangosnippets.org/snippets/937/) snippet. However, that snippet didn't work for me with ForeignKey fields. from foo.bar import ModelLinkAdminFields class MyModelAdmin(ModelLinkAdminFields, admin.ModelAdmin): modellink = ('field1', 'field2',)
I will change a model form widget attribute without define the complete field. Because many "meta" information are defined in the model (e.g. the help_text) and i don't want to repeat this. I found a solution: Add/change the widget attribute in the __init__, see example code.
the trick resides in `field.field.required`. The intuitive way of testing this in the templates is to access `field.required`. But it's not the good one. Enjoy! [Found via Django users Google Groups](http://groups.google.com/group/django-users/browse_thread/thread/ce83f74fb1156b4b/0df36947de16a071?lnk=gst&q=required+field#0df36947de16a071)
This Base64Field class can be used as an alternative to a BlobField, which is not supported by Django out of the box. The base64 encoded data can be accessed by appending _base64 to the field name. This is especially handy when using this field for sending eMails with attachment which need to be base64 encoded anyways. **Example use:** class Foo(models.Model): data = Base64Field() foo = Foo() foo.data = 'Hello world!' print foo.data # will 'Hello world!' print foo.data_base64 # will print 'SGVsbG8gd29ybGQh\n'
This provides some basic cryptographic fields using pyCrypto. All encryption/decription is done transparently and defaults to use AES. Example usage: class DefferredJunk(models.Model): semi_secret = EncryptedCharField(max_length=255)
A [common pattern in Django](http://code.djangoproject.com/wiki/UsingMarkup) is to create a TextField intended for Markdown text (i.e. description) and a companion non-editable TextField for storing the HTML version (i.e. description_html), so the Markdown converter need not be run for every page view. This snippet is a custom field which encapsulates this pattern in a single field which can automatically create and update its companion HTML field. Usage: class MyModel(models.Model): description = MarkdownTextField()
You can add this code to a file named "field_attrs.py" in a templatetags folder inside an application. To use it, remember to load the file with the following template tag: {% load field_attrs %} And for each field you want to change the widget's attr: {{ form.phone|attr:"style=width:143px;background-color:yellow"|attr:"size=30" }}
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)
A simple Django form field which validates a list of emails. [See this at my blog](http://sciyoshi.com/blog/2009/aug/08/emaillistfield-django/)
**Sumary** M2M relation without creating table. Normally you should specify m2m only in *one* model, thus widgets for many-to-many relations will be displayed inline on whichever model contains the actual reference to the ManyToManyField. But if you want to be able to have widgets displayed on both form you need some tricks, for example using intermediary-models can help, but you will not get multiselect widget (and in case of inlining extra = multi). Also you can write your own form which takes care about adding widget (just 1 line) and setting default values and saving it (more than few lines of code). If you try ManyToManyField with same db_table specified, the only problem will be in syncdb (it will try to create two identical tables) and the only thing our class does is preventing creation of table for M2M, so in one model you should use ManyToManyField and in another ManyToManyField_NoSyncdb with the same db_table argument. **Example** So to have M2M widgets in both forms you can write: class User(models.Model): #... groups = ManyToManyField('Group', related_name='groups', db_table=u'USERS_TO_GROUPS') class Group(models.Model): #... users = ManyToManyField_NoSyncdb(User, related_name='users', db_table=u'USERS_TO_GROUPS')