This snippet provides a @group_required decorator. You can pass in multiple groups, for example:
@group_required('admins','editors')
def myview(request, id):
...
Note: the decorator is based on the snippet [here](http://fragmentsofcode.wordpress.com/2008/12/08/django-group_required-decorator/) but extends it checking first that the user is logged in before testing for group membership - [user_passes_test](http://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth.decorators.user_passes_test) does not check for this by default.
It is important to check that the user is first logged in, as anonymous users trigger an AttributeError when the groups filter is executed.
Template filter to add the given number of tabs to the beginning of each line. Useful for keeping markup pretty, plays well with Markdown.
Usage:
{{ content|indent:"2" }}
{{ content|markdown|indent:"2" }}
Add the decorator to an already defined templatetag that returns a Node object:
@with_as
def do_current_time(parser, token):
...
return a_node
The decorator will patch the node's render method when the "as" syntax is specified and will update the context with the new variable. The following syntaxes are available:
{% current_time %}
{% current_time as time %}
{{ time }}
I recently had a need to build an iTunes style filtered search -- a user can add/subtract any number of filters whereby the are offered selects for fields they want to search, what type of search they wish to perform on that field (i.e., equals, contains, etc.), and then enter a value to search. Finally, they are provided the option to search all or any of the created filters.
To keep things simple, I created this dynamic query builder. It takes a Model, plus lists of fields, types, values, and the chosen operator (and/or). Then, it constructs actual Q objects for each, performing a small sanity check to ensure a blank value has not been passed in.
In the end, it returns either a filtered QuerySet or an empty result set to ensure that we can at least provide a message back to the user if nothing comes of trying to build the query.
One would use it like so:
results = dynamic_query(ModelName, fields_list, types_list, values_list, operator)
if results:
# do something
else:
# do something else
This is useful to run before you add a unique key to a character field that has duplicates in it. It just adds numbers to the end of the contents, so they will be unique.
It takes a model class and a field name. The model class can be a South fake orm object, so this can be used inside data migrations.
A generic admin action to export selected objects as csv file. The csv file contains a first line with header information build from the models field names followed by the actual data rows.
Access is limited to staff users.
Requires django-1.1.
**Usage:**
Add the code to your project, e.g. a file called actions.py in the project root.
Register the action in your apps admin.py:
from myproject.actions import export_as_csv
class MyAdmin(admin.ModelAdmin):
actions = [export_as_csv]
This is simple validation weather a string is close enough to what we want. First param is keyword we are comparing to Second is user's input and third is tolerance level. Its very rudimentary. I have my mind fixed upon some imperfections. I am trying to make it good for human like(crazy keyboard) error.
[Based on snippet #513 by obeattie.](http://www.djangosnippets.org/snippets/513/)
**Update 10/10/09:** [Further development is now occurring on GitHub, thanks to Shrubbery Software.](http://github.com/shrubberysoft/django-picklefield)
Incredibly useful for storing just about anything in the database (provided it is Pickle-able, of course) when there isn't a 'proper' field for the job.
`PickledObjectField` is database-agnostic, and should work with any database backend you can throw at it. You can pass in any Python object and it will automagically be converted behind the scenes. You never have to manually pickle or unpickle anything. Also works fine when querying; supports `exact`, `in`, and `isnull` lookups. It should be noted, however, that calling `QuerySet.values()` will only return the encoded data, not the original Python object.
*Please note that this is supposed to be two files, one fields.py and one tests.py (if you don't care about the unit tests, just use fields.py).*
This PickledObjectField has a few improvements over the one in [snippet #513](http://www.djangosnippets.org/snippets/513/).
1. This one solves the `DjangoUnicodeDecodeError` problem when saving an object containing non-ASCII data by base64 encoding the pickled output stream. This ensures that all stored data is ASCII, eliminating the problem.
2. `PickledObjectField` will now optionally use `zlib` to compress (and uncompress) pickled objects on the fly. This can be set per-field using the keyword argument "compress=True". For most items this is probably **not** worth the small performance penalty, but for Models with larger objects, it can be a real space saver.
3. You can also now specify the pickle protocol per-field, using the protocol keyword argument. The default of `2` should always work, unless you are trying to access the data from outside of the Django ORM.
4. Worked around a rare issue when using the `cPickle` and performing lookups of complex data types. In short, `cPickle` would sometimes output different streams for the same object depending on how it was referenced. This of course could cause lookups for complex objects to fail, even when a matching object exists. See the docstrings and tests for more information.
5. You can now use the `isnull` lookup and have it function as expected. A consequence of this is that by default, `PickledObjectField` has `null=True` set (you can of course pass `null=False` if you want to change that). If `null=False` is set (the default for fields), then you wouldn't be able to store a Python `None` value, since `None` values aren't pickled or encoded (this in turn is what makes the `isnull` lookup possible).
6. You can now pass in an object as the default argument for the field without it being converted to a unicode string first. If you pass in a callable though, the field will still call it. It will *not* try to pickle and encode it.
7. You can manually import `dbsafe_encode` and `dbsafe_decode` from fields.py if you want to encode and decode objects yourself. This is mostly useful for decoding values returned from calling `QuerySet.values()`, which are still encoded strings.
The tests have been updated to match the added features, but if you find any bugs, please post them in the comments. My goal is to make this an error-proof implementation.
**Note:** If you are trying to store other django models in the `PickledObjectField`, please see the comments for a discussion on the problems associated with doing that. The easy solution is to put django models into a list or tuple before assigning them to the `PickledObjectField`.
**Update 9/2/09:** Fixed the `value_to_string` method so that serialization should now work as expected. Also added `deepcopy` back into `dbsafe_encode`, fixing #4 above, since `deepcopy` had somehow managed to remove itself. This means that lookups should once again work as expected in **all** situations. Also made the field `editable=False` by default (which I swear I already did once before!) since it is never a good idea to have a `PickledObjectField` be user editable.
When debugging/developing you want to be able to refresh your views every time you make a little change. But when in production mode you might want to cache these views because they contain long and resource hungry calculations or something.
By putting this above "hack" in after importing `cache_page` you only cache the views in production mode.
Limit ManyToMany fields in forms. Hide the field, if only one item can be selected. e.g. For limit sites choices only to accessible sites.
Also available via django-tools: http://code.google.com/p/django-tools/
Ripped this out of a project I'm working on. The field renders as two <select> elements representing the two-level hierarchy organized events Facebook uses. Returns the id's Facebook wants.
Tag to inspect template context, filter to inspect variable.
Originally by denis, [http://www.djangosnippets.org/snippets/1550/](http://www.djangosnippets.org/snippets/1550/).
This just extracts variables from the context to locals for quicker access and autocompletion (When using ipdb).
Additionally, 'vars' holds context keys for quick reference to whats available in the template.
This is an adaption of
[django.forms.extras.widgets.SelectDateWidget](http://code.djangoproject.com/browser/django/trunk/django/forms/extras/widgets.py#L16)
which has no day dropdown - it still produces a date but with the day set to 1.
Example use
class myForm(forms.Form):
# ...
date = forms.DateField(
required=False,
widget=MonthYearWidget(years=xrange(2004,2010))
)
Django's standard inclusion_tag doesn't include context variables by default.
When you add takes_context you are required to manually merge the context
variables into the dict which your tag returns, which tends to result in
wasteful code or [possibly accidentally] leaking variables into the global
context (`context.update({…})`).
This decorator allows your inclusion tag to remain simple and still have safe
access to the global context for things like `MEDIA_URL`:
@register.inclusion_tag('my_template')
@private_context
def my_tag(context, …):
return {"foo": 1, "bar": 2}