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
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