Script per Aggiornare i ContentTypes e i Permessi del Model di una Tabella nell Admin [Django Blog](http://www.darioagliottone.it/blog)
MongoDB Resource for Tastypie ============================= Allows you to create delicious APIs for MongoDB. Settings -------- MONGODB_HOST = None MONGODB_PORT = None MONGODB_DATABASE = "database_name" Example of Usage ---------------- from tastypie import fields from tastypie.authorization import Authorization from tastypie_mongodb.resources import MongoDBResource, Document class DocumentResource(MongoDBResource): id = fields.CharField(attribute="_id") title = fields.CharField(attribute="title", null=True) entities = fields.ListField(attribute="entities", null=True) class Meta: resource_name = "documents" list_allowed_methods = ["delete", "get", "post"] authorization = Authorization() object_class = Document collection = "documents" # collection name Github Repository ================= <https://github.com/fatiherikli/tastypie-mongodb-resource>
This is an Authorization class for [Tastypie](http://django-tastypie.readthedocs.org/en/latest/authentication_authorization.html) v0.9.11 (v0.9.12 changes how Authorization works). DjangoAuthorization checks specific permissions — `add_model`, `change_model`, `delete_model`, etc. If you don't need that level of permissions checking, this might be useful. It just makes sure the User is logged in. It's equivalent to the `login_required` decorator.
Use this to send emails to your users, takes one template and renders it as html or text as needed. Credits to """ Jutda Helpdesk - A Django powered ticket tracker for small enterprise. (c) Copyright 2008 Jutda. All Rights Reserved. See LICENSE for details. lib.py - Common functions (eg multipart e-mail) """ MIT licence I only removed the specific project parts and made it general to use. The original project repository https://github.com/rossp/django-helpdesk/
**Use case:** Suppose you are working on maintenance screens on some data objects. On one particular page (a form) you want to have exits directly back to a calling page (as a cancel operation) or indirectly back to the calling page (after an data update operation). However, the form and its object are not directly related to the target page (perhaps a one-to-many relationship) so you cannot figure the calling page from object data - but the target object IS referenced in the url. ** How To:** To make this work, we need to pick out a variable from the URL of the current page and use it to generate the URL of the target page. 1. [urls.py] Models *Banker* and *Iaccount* are related as One-to-Many so if we are creating an *Iaccount* we cannot usually determine the *Banker* object to return to. In this example, URL1 contains the variable `iid` - the primary key to the Banker object; this will render a create form. We want to be able to reference URL2 from this form. 2. [views.py: get_initial] We can access the variable we want with `self.kwargs['iid']` and use it to set the initial value of the `ident` fields which links back to the *Banker* object 3. [views.py: get_success_url] In the same way we can pass the value into the form's *success_url* to point at URL2 4. [template] In the template, we can also access the variable now as `form.ident.value` so we can construct a *Go Back* link to URL2 Thanks to Thomas Orozco for leading the way.
This snippet was inspired by [1783](http://www.djangosnippets.org/snippets/1783/). It allows simply create groups of fields for template rendering.
This snippet provides support to create a bit more advanced forms, eg group fields together vertically and horizontally. It's a bit similar to the options one has about displaying fields in the admin.
This is a ModelChoiceField where the choices are rendered in optiongroups (this is already posible with a normal Choicefield) For this to work properly the queryset you supply should already be ordered the way you want (i.e. by the group_by_field first, then any sub-ordering)
Based on [#1879](http://djangosnippets.org/snippets/1879/) and [#2356](http://djangosnippets.org/snippets/2356/) Works in Django 1.3 Hopefully it's generic enough to implement a compact (sparse) version of whatever custom filter you need.
Basically the idea is to import/update model instances from a json data that closely matches the model structure (i.e. identical field names) From my answer to this question: [http://stackoverflow.com/a/8377382/202168](http://stackoverflow.com/a/8377382/202168) See the original question for sample data format.
This is another fork of http://djangosnippets.org/snippets/2729/ that fixes the issue. Unlike those other versions i give you instructions so it works for you, this is modified a little. Instructions: If you want to import the passwords from drupal you need to prepend to each of them the word drupal so it looks like this: drupal$S$DQjyXl0F7gupCqleCuraCkQJTzC3qAourXB7LvpOHKx0YAfihiPC Then add this snippet to someapp/hashers/DrupalPasswordHasher.py And then in your settings add this: PASSWORD_HASHERS = ( 'django.contrib.auth.hashers.PBKDF2PasswordHasher', 'someapp.hashers.DrupalPasswordHasher', 'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher', 'django.contrib.auth.hashers.BCryptPasswordHasher', 'django.contrib.auth.hashers.SHA1PasswordHasher', 'django.contrib.auth.hashers.MD5PasswordHasher', 'django.contrib.auth.hashers.CryptPasswordHasher', ) So, what did i modify First i added the attribute algorithm to the class, django uses this word to identify wich hasher to use, so the passwords beggining with drupal should be verified with the hasher.algorithm == 'drupal' Ok so know django knows to use our class, but now our passwords won't validate because we changed them by adding the word drupal, so what do we do? we modify the verify method to remove the word drupal before verification :P Hope it helps
middleware to capture exceptions doesnotexists,objectdoesnotexists
You have some tree-like structure in your models, for example: `class MyModel(models.Model): parent = models.ForeignKey('self', verbose_name=u'Parent', \ null=True, blank=True, related_name='children') name = models.CharField(u'Раздел', max_lengtch=255) position = PositiveSmallIntegerField(u'Позиция', default=0) class Meta: ordering = ('position',)` To see it as a tree in admin's object list(you also can sort items, move to another parents by drag-n-drop; and rename them) add this to admin.py: `class MyModelAdmin(admin.ModelAdmin): ordering = ('position',) list_display = ('pk','name','parent','position') raw_id_fields =('parent',) list_per_page = 900 #we sould have all objects on one page list_editable = ('name','position','parent') def parent_id(self,obj): return obj.parent and obj.parent.id or '0' class Meta: model = MyModel class Media: js = [settings.MEDIA_URL + s for s in ('lib/jquery-1.3.2.min.js', 'lib/jquery.tree.min.js', 'lib/plugins/jquery.tree.contextmenu.js', 'lib/mymodel_admin.js',)] css = { 'all':(settings.MEDIA_URL+'css/nestedsortablewidget.css',) }` mymodel_admin.js is the code listed here, if you have different title field(not "name"), change var title_column in javascript, list_display and list_editable. jstree can be obtained here: [jstree](http://www.jstree.com/) screenshot is in [my blog](http://tabed.org/blog/2010/01/06/jstree-in-django-admin/)
The Django admin site has a feature to filter objects in change list by parameters supplied in the query string. Particularly, parameters such as date\__gte and date\__lte can be used. This example is for filtering objects in change list by a date range (the date field is called expiration_date, but you can, of course, use any other name). As the server side (Django) already supports such filtering, all you need to do is to edit this for your needs (you can also add some DRY if you want) and put it into templates/admin/app_name/model_name/change_list.html. Some CSS for better layout: div.date_filter select#from_month, div.date_filter select#to_month { margin-left: 0; } div.date_filter label { margin-right: 5px; }
When saving an edit to an object from a filtered list view you are, by default, returned to list view without any of your filters applied. This solves that problem, keeping the filtered view in a session variable until you reach a point where the session key is deleted. The solution presented here is hugely based off of other's work with most of the solution gained from: [Admin: return to change_list with filter and pagination applied](http://djangosnippets.org/snippets/2415/ "Admin: return to change_list with filter and pagination applied") This solution offered the best approach in our mind over the others listed here on snippets since the solution didn't require changes to template code...this is completely self contained within your own admin.py files. The advantage to our solution over the above linked solution is that under different use cases the user may or may not be redirected to the filtered list_view. For example, if you edit an object and click the save and continue button, then you would lose the filter when you finally finished editing the object and clicked save. Added on here is a delete of the session key when users add objects, the reasoning we're going this route is we don't want to return users to filtered views when they just added a new object. Your mileage may vary and if so, it's easy enough to fit your own needs. HTHs