Simple filter for django ModelAdmin How use: #models.py class ObjectWithGenericForeignKey(model.Model): content_type = models.ForeignKey(ContentType) object_id = models.PositiveIntegerField() content_object= GenericForeignKey('content_type', 'object_id', for_concrete_model=False) #admin.py class CommentAdmin(admin.ModelAdmin): list_filter = (get_generic_foreign_key_filter(u'Filter title'),)
A simple Python function that converts a Python datetime formatting string to its nearest PHP equivalent. Python and PHP use different format string conventions when specifying datetime formats: * Python: [https://docs.python.org/2/library/time.html#time.strftime](https://docs.python.org/2/library/time.html#time.strftime) * PHP: [http://php.net/manual/en/function.date.php](http://php.net/manual/en/function.date.php) Working with Django the Date, Time and DateTime widgets all use Python format strings as stored in: * django.conf.global_settings.DATE_INPUT_FORMATS * django.conf.global_settings.TIME_INPUT_FORMATS * django.conf.global_settings.DATETIME_INPUT_FORMATS but if you want to use a datetime widget like the datetimepicker here: [http://xdsoft.net/jqplugins/datetimepicker/](http://xdsoft.net/jqplugins/datetimepicker/) then you'll find it uses PHP format specifiers. If you want Django and the datetimepicker to populate a field in the same way, you need to ensure they use the same format. So I add to the Django from context the default format as follows: `context["default_datetime_input_format"] = datetime_format_python_to_PHP(DATETIME_INPUT_FORMATS[0])` and in the template Javascript on my form for the datetimepicker i give it: `"format": {{default_datetime_input_format}}` and the datetimepicker now populates the the datetime field in the same format as Django.
This creates an RSS feed that has "content:encoded" elements for each item in the feed. The "description" is best used for a brief summary of the entry, while the extra ["content:encoded"](http://purl.org/rss/1.0/modules/content#syntax2) element is designed for the entire contents of something. This is the code I'm using for a weblog app. The main features you'd need to copy to add "content:encoded" elements to your own feed are: * **ExtendedRSSFeed()** -- this is used to create a new kind of feed generator class that will know about these extra elements. * **feed_type = ExtendedRSSFeed** -- we tell the feed class which feed generator class to use. * **item_extra_kwargs()** -- we add the "content:encoded" element to each item. This populates the element by calling... * **item_content_encoded()** -- this prepares the actual content. The name doesn't have to be in this format, but it seemed sensible to follow convention. The body of my weblog Entries are split into two parts and here it makes sure we add both parts, both of which contain HTML (which the syndication classes will encode appropriately.
This hasn't been thoroughly tested yet but so far it works great. We had no use for sessions or the built in authentication middleware for django as this was built to be a microservice for authentication. Unfortunately if you just use the django rest framework-jwt package the authentication occurs at the view level meaning request.user.is_authenticated() will always return False. We have a few internal non-api views that needed @login_required. We have a stripped down version of django that is very performant that we are using for microservices with built-in authorization using JSON Web Tokens. This service is authentication which has access to a `users` table. Any questions or curious how well lightweight django is working for microservices, or we he are doing the the authorization on the other services, or just improvements please drop a line - thanks.
Salaam Insert Required Field Asterisk Thank You
Enables a search bar for both sides of the Filter_Horizontal fields. Copy replace in your static/admin/js/SelectFilter2.js
Use HTTP Authorization to log in to django site. If you use the FORCE_HTTP_AUTH=True in your settings.py, then ONLY Http Auth will be used, if you don't then either http auth or django's session-based auth will be used. This assumes that the regular auth middleware is already installed. If you provide a HTTP_AUTH_REALM in your settings, that will be used as the realm for the challenge. Having both a decorator and a middleware means that for site-wide http auth, you only need to specify it once, but the same code can be used as a decorator if you want part of your site protected using htty basic auth, and the other bits freely visible. Of course, since this is basic auth, then you need to make sure your site is running under SSL (HTTPS), else your users passwords are effectively transmitted in the clear.
This is based on [snippet 501](http://www.djangosnippets.org/snippets/501/), with some corrections: 1. if user doesn't exist and AD.authenticate passes, then create new user - don't store password - prevent default django auth backend authentication 2. if user exists and AD.authenticate passes - django User object is updated 3. various error handling 4. fixes (some mentioned in original snippet) 5. some settings removed from settings to backend module 6. other changes (ADUser class, re-indent, logging etc.) 7. ignores problem with search_ext_s (DSID-0C090627) 8. caching connection - when invalid then re-connect and try again Note that there is also ldaps:// (SSL version) django auth backend on [snippet 901](http://www.djangosnippets.org/snippets/901/). Possible improvements: 1. define new settings param - use secured - then LDAPS (snippet 901) 2. define new settings extra ldap options - e.g. protocol version 3. fetch more data from AD - fill in user data - maybe to make this configurable to be able to update user.get_profile() data too (some settings that has mapping AD-data -> User/UserProfile data)
Call a function for each element in a queryset (actually, any list). Features: * stable memory usage (thanks to Django paginators) * progress indicators * wraps batches in transactions * can take managers or even models (e.g., `Assertion.objects`) * warns about `DEBUG`. * handles failures of single items without dying in general. * stable even if items are added or removed during processing (gets a list of ids at the start) Returns a `Status` object, with the following interesting attributes * `total`: number of items in the queryset * `num_successful`: count of successful items * `failed_ids`: list of ids of items that failed
[The problem](http://stackoverflow.com/questions/671369/django-specifying-a-base-template-by-directory): {% extends "./../base.html" %} won't work with extends. It causes a lot of inconvenience, if you have an extensive hierarchy of django templates. This library allows relative paths in argument of 'extends' and 'include' template tags. Relative path must start from "./" Just write in your templates as follows: ``` {% load relative_path %} {% extends "./base.html" %} ``` this will extend template "base.html", located in the same folder, where your template placed ``` {% load relative_path %} {% extends "./../../base.html" %} ``` extend template "base.html", located at two levels higher same things works with 'include' tag. ``` {% load relative_path %} {% include "./base.html" %} ``` include base.html, located near of your template. **Warning!** The rule 'extends tag must be first tag into template' is disabled by this library. Write your template with caution. **Compatibility** Code was tested with Django versions from 1.4 to 1.9 Installation. ------------- Installation is differs for Django version 1.9 and previous versions, because 1.9 brings many changes into template's mechanizm. **Django 1.9** Plug reference to library code in 'TEMPLATES' key of settings.py or django.settings.configure() ``` TEMPLATES = [{ 'BACKEND': 'django.template.backends.django.DjangoTemplates', 'DIRS': [os.path.join(ROOT_PROJECT, 'tpl').replace('\\', '/')], 'OPTIONS': { 'loaders': [ 'dotted_path_to_relative_path_file.FileSystem19', 'dotted_path_to_relative_path_file.AppDirectories19', ], 'libraries': { 'relative_path': 'dotted_path_to_relative_path_file', }, }, }] ``` **Django 1.4/1.8** Put 'relative_path.py' file to the 'templatetags' folders of your app. (app must be included into INSTALLED_APPS tuple) In settings.py or django.settings.configure(), replace standard django template loaders by loaders from this library ``` TEMPLATE_LOADERS = ( 'dotted_path_to_relative_path_file.FileSystem', 'dotted_path_to_relative_path_file.AppDirectories', ) ```
Here's some fairly normalized models for representing postal addresses. Making postal_code a separate model would probably be the only way to get it to a level that everyone would agree is 2NF, but we handle a lot of international addresses so that isn't really feasible. Country and StateProvince are intended to be populated with data from ISO 3166. I'd include the SQL I used with that data, but it's very long and there's no attach feature. Also, I'd probably be violating ISO's copyright.
In my sphinx documentation I really wanted a nice clean list of the fields on my Django models. The most obvious way of doing this is to add ":param blah:" tags to the docstring, but this takes a long time to implement and violates DRY principles when you already have lots of nice help text in the model definition. Another way is to use "#:" comments on attributes, but this approach suffers from the same issues as the previous method with the additional problem of Sphinx crapping out on file and custom fields. So anyway, this is my solution. It uses the Sphinx docstring processing callback to intercept any objects that inherit from django.models.Model and creates a nice param list of all the fields on that model. Param descriptions come from the field's help text or verbose name if no help text is defined. To use this, just add it to the end of your source/conf.py, filling out the project path as appropriate. You may be able to skip the Django environment setup lines if you're adding this to a Sphinx doc that already has Django models set up.
A tag that parses args ang kwargs like the url tag. {% get_with_args_and_kwargs somevar,"sometext",kwarg1=someothervar %}
A simple decorator that requires a user to be logged in. If they are not logged in the request is examined for a 'authorization' header. If the header is present it is tested for basic authentication and the user is logged in with the provided credentials. If the header is not present a http 401 is sent back to the requestor to provide credentials. The purpose of this is that in several django projects I have needed several specific views that need to support basic authentication, yet the web site as a whole used django's provided authentication. The uses for this are for urls that are access programmatically such as by rss feed readers, yet the view requires a user to be logged in. Many rss readers support supplying the authentication credentials via http basic auth (and they do NOT support a redirect to a form where they post a username/password.) Use is simple: ` @logged_in_or_basicauth def your_view: ... ` You can provide the name of the realm to ask for authentication within.
Based on: [View all log entries in the admin](https://djangosnippets.org/snippets/2484/) Improvements: * No crash on `object_link` when reverse route missing, * Filter by users present in the log AND in database currently * Other filters on users - only superusers / only staff (modify to fit your needs) EDIT: Incorporated `action_description` from [django-logentry-admin](https://github.com/yprez/django-logentry-admin). * The list filter now has human-friendly action names, and the table also. * Refactored list filter class hierarchy.