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.
Use this paginator to make admin pages load more quickly for large tables when using PostgreSQL. It uses the reltuples statistic instead of counting the rows when there is no where clause. To use this code, add the following in your admin: `class BigTableAdmin(admin.ModelAdmin): paginator = LargeTablePaginator def get_changelist(self, request, **kwargs): return LargeTableChangeList `
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/)
This is a helper field & widget that lets you ask for a 'user or group'. It presents a select box for whether you wish to enter a user or a group, and then a text field for the name of the user or group you wish to have. It will validate that the username or group name selected exists. You would use this like any other field: ` class AddForumCollectionCreatePermForm(forms.Form): user_or_group = UserOrGroupField(label = "User or Group", help_text = "The user or group to grant " "forum collection create priveleges to.") `
**This is an alternative to User.get_profile.** Rather than having you call `User.get_profile` directly, this retrieves the profile instance for a `User` and attaches the fields from the profile to the `User` object when instantiated. The special methods for `DateField`, `FileField`, `ImageField` and fields with `choices` are also created. Since the profile object still has to be retrieved from the database before its fields can be added to the `User`, the costs for using this might outweigh the rewards unless you are heavily using profiles. To install, place it in a module on your `PYTHONPATH` and add it to `INSTALLED_APPS`.
Twitter Bootstrap 3 default pagination with all pages indexes and controls for Django 1.6 ListView template.
The version of [snippet](http://djangosnippets.org/snippets/2397/) that works with Django 1.5. Kudos to [kmike](http://djangosnippets.org/users/kmike/) for the original snippet.
This RSS using `Rss201rev2Feed` from Django. And we found it from source code of blog.pythonanywhere.com: https://github.com/pythonanywhere/jab/blob/master/jab/feeds.py Demo: http://django.id/blog/feed/
This tag builds on top of the [ifusergroup/else tag](http://www.djangosnippets.org/snippets/390/), fixes a small bug and introduces support for else blocks. This adds a way to provide multiple groups via group1|group2|group3
open file in text editor
Some times if third party application is not translated competelly, developer have to extract and save all of **i18n** strings of third party application to current project, somewhere in root project directory (and configure additional `LOCALE_DIRS` entry) or in any project's applications (usually named "main" or same as project). And after, create **po** file by makemessages, completely translate it and compile it to **mo** file. This script allows you to extract all messages (`msgid`) from all **po** files and save it in **python** file in **django** format — `_("Some i18n message")`, and also compile complex **po** file, contained all **msgids** with related **msgstrs** of third party application. Full example: You have third party app, which is translated to russian, but not completely and names **blog**. It contains two locale dirs and have, for example, the following structure: blog ..locale ....ru ......LC_MESSAGES ........django.mo ........django.po ..contrib ....comments ......locale ........ru ..........LC_MESSAGES ............django.mo ............django.po ......__init__.py ......models.py ..__init__.py ..models.py ..urls.py ..views.py Each po file may contains any set of strings, which may be duplicated accross the application and any other po files, anyway result **po** file will be contain only unique **msgids** and **msgstrs**. This application installed by pip into virtualenv lib directory and of cource you do not want change code here. To translate this application in your project it is possible to copy all (unstanslated) strings to you project as `ugettext` entries (usually `_("Some i18n string")`), make **po** file, translate it and compile **mo** file. So, after call this script (for example, let it be named `pomessages.py`), you will get two files, **django.py** which contains all i18n strings and **django.po** which contains all **msgids** (i18n strings) with related translations. `pomessages.py path/to/third-party-app/root locale [project-name:default is empty] [filename:default=django]` In this case: `pomessages.py path/to/blog ru blog django` After script will be finished, in blog directory will be added two files, **django.po** and **django.mo**. **django.py** content: ... # blog:admin (source:ru) directory translations # ---------------------------------------------- _("Category") # blog:models.py:10, blog:views.py:15 _("Article") # blog:models.py:20 # blog:category/admin (source:ru) directory translations # ------------------------------------------------------- _("Add Category") # blog:category/admin/templates/admin/create.html:10 _("Edit Category") # blog:category/admin/templates/admin/change.html:20 ... **django.mo** content: ... # msgid "" msgstr "" "Project-Id-Version: Blog\n" "POT-Creation-Date: 2016-02-08 12:00+0000\n" "PO-Revision-Date: 2016-02-08 18:00+0000\n" #: path/to/file.py:10 msgid "Category" msgstr "Категория" #: path/to/file.py:20 msgid "Article" msgstr "" ... After you just need to place **py** file anywhere in your project and place **po** file to the following locale directory (or merge with existing **po** file if it exists), run: `django-admin makemessages -lru` to fix **po file** (remake it), translate missing entries and run: `django-admin compilemessages`, reload project and you will have translated third party application.
It is a haystack custom whoosh backend which provides analyzer customisation (required `get_analyzer` method definition). That means it is possible to define any complex analyzers (see [whoosh](https://bitbucket.org/mchaput/whoosh/wiki/Home) docs and source). Sample code shows how to use it, builtin `LanguageAnalyzer` instance configured for working with russian language used as custom analyzer. Base idea taken from this snippet: [https://djangosnippets.org/snippets/3025/](https://djangosnippets.org/snippets/3025/)
email backend which use sendmail subprocess
Most people simply wrap "from localsettings import *" in a try/except ImportError block. That's what I've done for years, but recently came up with this better way. The problem this snippet solves is that if your localsettings.py itself causes an ImportError somehow, that error will be silently swallowed and your intended localsettings will be ignored. Instead, we use `imp` to first check if the module exists, then unconditionally try to import it.
Save the snippet as actions.py within your core app, and then add an action on any model you want in it's ModelAdmin definition. Example usage: `from actions import export_as_csv_action` `class YourModelAdmin(admin.ModelAdmin):` ` list_display = ('field', 'get_field2')` ` actions = [export_to_csv(filename='your-model')]` ` def get_field2(self, obj):` ` return obj.field2`