Model-driven multiple database router
Multiple database router that allows setting the target database for each model by setting the `in_db` field in its `Meta` class.
- multiple-databases
- routing
Multiple database router that allows setting the target database for each model by setting the `in_db` field in its `Meta` class.
You can place this snippet in management/commands/ and have it upload files from disk into objects in your database. Usage: ``` python manage.py upload_file_to_model myapp mymodel myfield 1 field_name /some/file/path ```
This decorator will memoize the results of instance methods, similar to `django.util.functional.memoize`, but automatically creates a cache attached to the object (and therefore shares the life span of the object) rather than requiring you to provide your own. Note this is intended for instance methods only, though it may work in some cases with functions and class methods with at least one argument. This is useful for memozing results of model methods for the life of a request. For example: class MyModel(models.Model): #Fields here @auto_memoize def some_calculation(self): #some calculation here return result
This script tested under Django==1.9.*
Easy way to get base64 for the image to display in the template, eg: `<img src="{{ post.get_cover_base64 }}">`
Displays hotshot profiling for any view. http://yoursite.com/yourview/?prof Add the "prof" key to query string by appending ?prof (or &prof=) and you'll see the profiling results in your browser. It's set up to only be available in django's debug mode, but you really shouldn't add this middleware to any production configuration. * Only tested on Linux * You should probably use this one instead: http://djangosnippets.org/snippets/2126/
This is just modified version of [friendly id](https://djangosnippets.org/snippets/1249/) for make this script compatible with python 3.x 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) self.save() 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 :-)
A template tag that includes a modified version of the GET query string. the query string can be manipulated by adding and removing fields. If a value is given that resolves to a context variable that the value of the variable is used. Based on [this snippet by dnordberg](http://djangosnippets.org/snippets/826/), but with the ability to use context and done in a cleaner manner, without the need to add an arbitrary template.
This mixin is for class based views. Kwargs passed from url patterns to views via the dispatch method.
Decorator to automagically add placeholders to form widgets. `cls` can be any class derived from `django.forms.Form` or `django.forms.ModelForm`. The field labels are used as value for the placeholder. This will affect all form instances of this class. * add_placeholders only to forms.TextInput and form.Textarea * add_placeholders_to_any_field adds placeholders to any field Usage: @add_placeholders class Form(forms.Form): name = forms.CharField The name field will render as `<input type="text" placeholder="name">`
Fixed minimal version, works with Django 1.7+, tested on Django 1.9. Add the following to your settings: AUTHENTICATION_BACKENDS = [ 'project.backends.UserModelEmailBackend', # Login w/ email 'django.contrib.auth.backends.ModelBackend', # Login w/ username ]
HTML allows an option in a <select> to be disabled. In other words it will appear in the list of choices but won't be selectable. This is done by adding a 'disabled' attribute to the <option> tag, for example: `<option value="" disabled="disabled">Disabled option</option>` This code subclasses the regular Django Select widget, overriding the render_option method to allow disabling options. Example of usage: class FruitForm(forms.Form): choices = (('apples', 'Apples'), ('oranges', 'Oranges'), ('bananas', {'label': 'Bananas', 'disabled': True}), # Yes, we have no bananas ('grobblefruit', 'Grobblefruit')) fruit = forms.ChoiceField(choices=choices, widget=SelectWithDisabled())
This is a utility script that scans a models.py file and automatically outputs the corresponding newforms-admin source code - the code that goes into the admin.py file. The purpose is to simplify the migration to newforms-admin. Here is what it outputs: * an import line that lists only the needed classes from the model. * inline editing classes - inheriting from either `admin.TabularInline` or `admin.StackedInline` * admin options classes containing any original `Admin` class contents (`'fields'` is replaced by `'fieldsets'` and the value of `'classes'` is made into a tuple), plus the following fields whose values are determined automatically: `inlines`, `prepopulated_fields`, `filter_horizontal`, `filter_vertical` and `raw_id_fields` * invokations of `admin.site.register` for the generated admin options classes. Example usage of the script (this will generate the admin.py file for the models.py file in the satchmo.product module): >./new-forms-gen.py satchmo.product > admin.py
Example (in project/application/models.py): register_custom_permissions_simple((("is_editor", "User is editor"),)) In a view: if not request.user.has_perm('application.is_editor'): return HttpResonseRedirect(LoginUrl)
If you want anonymous visitors to your site, or parts of your site to be authenticated as real users so that you can treat them as such in your views and models, use this snippet. Add the above AuthenticationBackendAnonymous middleware into AUTHENTICATION_BACKENDS in your settings.py and use the snippet anonymous_or_real(request) in your views, which returns a user. Comment out the bit where it creates a profile if you are not using profiles.