In case you need a form field that only has one acceptable value, you can create a custom form field derived from `forms.ChoiceField` which only accepts one choice. Alternatively you can: * Ignore the value of such a field entirely. * Simply pass a single choice to a the `forms.ChoiceField`
This method will return an inline formset class that validates values across the given field are unique among all forms. For instance: ApprovedUserFormSet = inlineformset_factory(Request, ApprovedUser, formset=unique_field_formset('email'), form=ApprovedUserForm) Will make sure all ApprovedUser objects created for the Request have unique "email" fields.
These field and widget are util for to those fields where you can put a star and end values. It supports most of field types and widgets (tested with IntegerField, CharField and DateField / TextInput and a customized DateInput). **Example of use:** class FormSearch(forms.Form): q = forms.CharField(max_length=50, label=_('Search for')) price_range = RangeField(forms.IntegerField, required=False) **Example of use (with forced widget):** class FormSearch(forms.Form): q = forms.CharField(max_length=50, label=_('Search for')) price_range = RangeField(forms.IntegerField, widget=MyWidget)
**This is a model field for managing user-specified positions.** Usage ===== Add a `PositionField` to your model; that's just about it. If you want to work with all instances of the model as a single collection, there's nothing else required. In order to create collections based on another field in the model (a `ForeignKey`, for example), set `unique_for_field` to the name of the field. It's probably also a good idea to wrap the `save` method of your model in a transaction since it will trigger another query to reorder the other members of the collection. Here's a simple example: from django.db import models, transaction from positions.fields import PositionField class List(models.Model): name = models.CharField(max_length=50) class Item(models.Model): list = models.ForeignKey(List, db_index=True) name = models.CharField(max_length=50) position = PositionField(unique_for_field='list') # not required, but probably a good idea save = transaction.commit_on_success(models.Model.save) Indices ------- In general, the value assigned to a `PositionField` will be handled like a list index, to include negative values. Setting the position to `-2` will cause the item to be moved to the second position from the end of the collection -- unless, of course, the collection has fewer than two elements. Behavior varies from standard list indices when values greater than or less than the maximum or minimum positions are used. In those cases, the value is handled as being the same as the maximum or minimum position, respectively. `None` is also a special case that will cause an item to be moved to the last position in its collection. Limitations =========== * Unique constraints can't be applied to `PositionField` because they break the ability to update other items in a collection all at once. This one was a bit painful, because setting the constraint is probably the right thing to do from a database consistency perspective, but the overhead in additional queries was too much to bear. * After a position has been updated, other members of the collection are updated using a single SQL `UPDATE` statement, this means the `save` method of the other instances won't be called. More === More information, including an example app and tests, is available on [Google Code](http://code.google.com/p/django-positions/).
Invoice numbers like "0000004" are a little unprofessional in that they expose how many sales a system has made, and can be used to monitor the rate of sales over a given time. They are also harder for customers to read back to you, especially if they are 10 digits long. This is simply a perfect hash function to convert an integer (from eg an ID AutoField) to a unique number. The ID is then made shorter and more user-friendly by converting to a string of letters and numbers that wont be confused for one another (in speech or text). To use it: import friendly_id class MyModel(models.Model): invoice_id = models.CharField(max_length=6, null=True, blank=True, unique=True) def save(self, *args, **kwargs): super(MyModel, self).save(*args, **kwargs) # Populate the invoice_id if it is missing if self.id and not self.invoice_id: self.invoice_id = friendly_id.encode(self.id) super(MyModel, self).save(*args, **kwargs) if self.id and not self.invoice_id When an object from this model is saved, an invoice ID will be generated that does not resemble those surrounding it. For example, where you are expecting millions of invoices the IDs generated from the AutoField primary key will be: obj.id obj.invoice_id 1 TTH9R 2 45FLU 3 6ACXD 4 8G98W 5 AQ6HF 6 DV3TY ... 9999999 J8UE5 The functions are deterministic, so running it again sometime will give the same result, and generated strings are unique for the given range (the default max is 10,000,000). Specifying a higher range allows you to have more IDs, but all the strings will then be longer. You have to decide which you need: short strings or many strings :-) This problem could have also been solved using a random invoice_id generator, but that might cause collisions which cost time to rectify, especially when a decent proportion of the available values are taken (eg 10%). Anyhow, someone else has now already written this little module for you, so now you don't have to write your own :-)
FileField delete file on delete or update
Used to check if a field of an object has changed. This is probably most useful in the save method.
This is possibly the simplest solution for storing binary data in a TextField.
FileField that checks that the file is a valid CSV and if specified in `expected_fieldnames` checks that the fields match exactly. The widget's `accept` parameter is set to accept csv, text and excel files. **TODO**: Validate the entirety of the CSV file, not just the headers. But this should be enough for most use cases, as checking the whole file could be computationally expensive for huge files. Example usage: people = CSVField(expected_fieldnames=['First Name', 'Last Name'])
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 Form and ModelForm which provides the ability to specify certain fields as readonly, meaning that they will display their value as text wrapped with a <span> tag. The user is unable to edit them, and they are protected from POST data insertion attacks. The recommended usage is to place a NewMeta inner class on the form, with a readonly attribute which is a list or tuple of fields, similar to the fields and exclude attributes on the Meta inner class. class MyForm(ReadonlyForm): foo = forms.TextField() bar = forms.TextField() class NewMeta: readonly = ('foo',) Use these forms as you would a standard form in your templates.
=== version 2 === > Parts of this code are based off of source from *davidcramer* on #django and I'd like to thank him for his assistance. Example: # forms.py ... class ForumPostForm(FieldAccessForm): class Meta: model = ForumPost class FieldAccess: moderator = FieldAccessLevel( lambda user, instance: user.get_profile().is_moderator, enable = ('approve', 'delete', 'edit') member = FieldAccessLevel( lambda user, instance: user.is_active, enable = ('edit',), exclude = ('approve', 'delete') ... # template ... <form action="" method="POST"> <table> {% for field in form %} <tr><th>{{ field.label_tag }}</th><td> {% if not field.field.disabled %} {{ field }} {% else %} {{ field.field.value }} {% endif %} </td></tr> {% endfor %} </table> <p><input type="submit" value="Update" /></p> </form> ... This class will grant or deny access to individual fields according to simple rules. The first argument must be a user object, but otherwise, this class is instantiated the same as a ModelForm. To utilize this code, inherit your form from FieldAccessForm, and create an inner class on your form called FieldAccess. Variables added to this inner class must have the same structure as that provided by the FieldAccessLevel class, which defines an access level, and the fields which apply to that access level. FieldAccessLevel takes as it's first argument a callable rule that validates this access level. That rule will be called with two arguments: 'user' (current user requesting access) and 'instance' (model instance in question). The keyword arguments to FieldAccessLevel are field groups which are used to determine which fields on this form are to be enabled and/or excluded, when the current user matches this access level. The term exclude indicates fields which are not to be rendered in the form at all. Any fields not grouped in either 'enable' or 'exclude' will be disabled by default. Superusers are always assumed to have full access. Otherwise, if a field is not specified with the FieldAccess inner class, then it is disabled by default. In other words, all users (except superusers) are denied access to all fields, unless they are specifically given access on a per-field basis. It is worth mentioning that multiple access levels can apply simultaneously, giving a user access to fields from all levels for which he matches the rule. If a user is denied access to a field, then the widget for that field is flagged as disabled and readonly. The field is also given two new attributes: a boolean 'disabled', and a 'value' containing the instanced model field. These two attributes allow a template author to have great control over the display of the form. For example, she may render the plain text value of a field instead of the disabled widget. The FieldAccess inner class also allows one to conditionally exclude fields from being rendered by the form. These exclusions operate very similarly to the standard Meta exclude option, except that they apply only to the access level in question. Note: The FieldAccess inner class may be used on both the form and the model; however, generally it makes more sense on the form. If you do use FieldAccess on both the form and model, be aware that both definitions will apply simultaneously. All access levels for which the user passes the rule will be processed, regardless of whether they were found on the form or the model.
This snippet allows you to use a new field type, RoundedDecimalField, that will automatically round any value affected to it according to the max_digits and decimal_places attributes. You will no longer receive validation errors if you use a float or a decimal with too many decimal digits.
This is another foreign key to User model. User is automatically associated before save. Requires: [ThreadlocalsMiddleware](http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser) Inspired by: [snippet 509](http://www.djangosnippets.org/snippets/509/)
Change model field attributes from a abstract base classes model in a dry way.