Sometimes, we need to pass hidden fields with an initial value in forms but cannot trust the returned values because it could have been tampered. So here is a form that adds an additional 'hidden' field (called 'form_hash') that hashes all the initial value of hidden fields and checks for tampering. Pretty straightforward to use.
**Step 1** Save somewhere in your project directory **Step 2** Add to your settings.py MIDDLEWARE_CLASSES = ( 'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.middleware.doc.XViewMiddleware', 'utils.debug.UserBasedExceptionMiddleware', ) Normal users will get your 500.html when debug = False, but If you are logged in as a super user then you get to see the stack trace in all its glory.
With this command you can calculate the maintainability index for your whole project. In your settings you have to add a dictionary called `RADON_MI_SETTINGS`. It could be like this: ```python RADON_MI_SETTINGS = { 'paths': ['projectname'], 'exclude': 'projectname/some_app/some_file.py', 'ignore': 'migrations,tests', } ``` I had to add following packages: ``` radon==3.0.1 progress==1.5 plotly==3.7.0 GitPython==2.1.11 ``` Following commands are available: * `python manage.py calculate_maintainability_index` Only display the maintainability index of the project. The average from every file is build by using the logical lines of code per file. * `python manage.py calculate_maintainability_index --init` Go through every commit filtered by their commit_message (is set to “bump version” currently) and calculate the maintainability index for the whole project. This creates a file with the history. * `python manage.py calculate_maintainability_index --showhistory` Display the history of the maintainability_index in a graph in your browser. * `python manage.py calculate_maintainability_index --commit` Calculate the current maintainability_index and append it to your history. Commit your edited history file. * `python manage.py calculate_maintainability_index --fail` Calculate the current maintainability_index and raise an Error, if it is lower than the last entry in your history. Useful for use in an automated pipeline. Hints: * radon has a problem with large lists and dictionaries. If you have a file with a list or dictionary with more than 100 entries, you should exclude it. * To initialize your history you should change the commitmessage filter to something, that suits your needs. Created by Martin Becker at [Jonas und der Wolf GmbH](https://www.jonasundderwolf.de)
This is the "unobtrusive comments moderation" code from http://www.djangosnippets.org/snippets/112/ , but updated so it works properly with Django 1.0. There are only a few small changes reflecting changes in the comments, contenttypes, and signals APIs. For full background, see the original snippet: http://www.djangosnippets.org/snippets/112/
Signal to notify new saved comments. **Example:** from django.contrib.comment import models, signals signals.comment_was_posted.connect(new_comment_notifier, sender=models.Comment)
Usually I start an authentication app with this model. Don't forget to set it up in the settings file AUTH_PROFILE_MODULE = 'authentication.UserProfile'
django online users, usage: `{{ request.online_now }}` or `{{ request.online_now_ids }}`, complete tutorial: https://python.web.id/blog/django-count-online-users/, this snippet forked from: https://gist.github.com/dfalk/1472104
This is a decorator which will gets Django to try the cache before computing the result of a function. It automatically builds the cache key as a hash of the function name and inputs, and allows you to set whatever timeout you want.
If you are like me and you find yourself often using M2M fields for tons of other on-model methods, in templates, and views alike, try using this quick and dirty caching. I show the use of a "through" model for the m2m, but that is purely optional. For example, let's say we need to do several different things with our list of beads, the old way is... # views.py necklace = Necklace.objects.get(id=1) bead = Bead.objects.get(id=1) if bead in necklace.beads.all(): # this bead is here! # template necklace.html {% for bead in necklace.beads.all %} <li>{{ bead }}</li> {% endfor %} ...which would hit the database twice. Instead, we do this: # views.py necklace = Necklace.objects.get(id=1) bead = Bead.objects.get(id=1) if bead in necklace.get_beads(): # this bead is here! # template necklace.html {% for bead in necklace.get_beads %} <li>{{ bead }}</li> {% endfor %} Which only does one hit on the database. While we could have easily set the m2m query to a variable and passed it to the template to do the same thing, the great thing is how you can build extra methods on the model that use the m2m field but share the cache with anyone down the line using the same m2m field. I'm by no means an expert, so if there is something here I've done foolishly, let me know.
Use this snippet to log the time taken to execute a specific DB query.
Third party services (e.g. Stripe) optionally sign webhook events to verify it is them sending events. If the third party you use does not provide an SDK or official library for verifying signatures, you can manually verify the signature with this snippet.
Based on https://djangosnippets.org/snippets/2020/ and https://stackoverflow.com/questions/5146539/streaming-a-csv-file-in-django Can be used on really large querysets.
Useful for models with fields like `finished` or `last_updated`
Python 3.8's Assignment Expressions, aka the Walrus operator, feel like an excellent pattern for checking optional environment variables that are only needed to initialize a library like Sentry.
es solo un ejemplo