For an overview of what has changed between versions, see the Changelog.
Upgrading from 1.1.0¶
Version 1.2.0 changes the way the anonymisation flag is stored. Previously it was stored
anonymised field which gdpr-assist added to your models, but this caused
problems when wanting to anonymise third party models. This flag has now been moved to a
new model in the gdpr-assist app, linked to your objects using a generic foreign key.
If you migrate without following these instructions, you will lose information about which database objects have been anonymised.
Migrating your data¶
You must write a data migration to move this data to run before you create a migration
to remove the
anonymised field. There is a migration operator to help you:
Create empty migrations for your apps with existing anonymisable models:
./manage.py makemigrations myapp --empty
Add the operator using the following migration template:
from django.db.migrations import Migration from gdpr_assist.upgrading import MigrateGdprAnonymised class Migration(migrations.Migration): dependencies = [ ('myapp', '0012_migration'), # Added by makemigrations ('gdpr_assist', '0002_privacyanonymised'), # Keep this dependency ] operations = [ MigrateGdprAnonymised('MyModelOne'), # Update this to your model MigrateGdprAnonymised('MyModelSix'), # Repeat for all your GDPR models ]
Create migrations to remove the fields:
./manage.py makemigrations myapp
Repeat for any other apps with anonymisable models
Run all migrations
./manage.py migrate ./manage.py migrate –database=gdpr_log
System check gdpr_assist.E001¶
Version 1.2.0 onwards adds a system check to ensure you have followed the above instructions, to avoid accidental data loss when upgrading. If your migration tries to remove the field before you have migrated data, you will see the error message:
Removing anonymised field before its data is migrated
This is triggered when removing any field called
anonymised before it has been
migrated with the
In most cases you can fix this by following the instructions above.
anonymised field was not added by gdpr-assist, and you do not want to run
MigrateGdprAnonymised, you can tell the check to ignore the failing migration by
gdpr_assist_safe = True to the migration class; for example:
class Migration(migrations.Migration): gdpr_assist_safe = True dependencies = [...
Alternatively if you are happy that all your migrations are safe, you can add the check
SILENCED_SYSTEM_CHECKS in your project settings to disable the migration check:
SILENCED_SYSTEM_CHECKS = [ "gdpr_assist.E001", ]
Changes to your code¶
In most cases no further action will be required, but if you are using the
anonymised field in your own code, you will need to call
query the model
- Add support for Django 3.0 and 3.1
- Remove support for Django 2.1 and earlier
- Add support for Django 2.2
PrivacyMetato support searching and exporting data which shouldn’t be anonymised. (#15, #17)
- Add bulk anonymisation operations to improve efficiency of large anonymisations
- Remove support for Django 1.8
- Fix support for third party models by removing the
anonymisedfield (#5, #13)
- Fix duplicate migrations (#6, #12)
- Fix documentation for post_anonymise (#8, #14)
- Code style updated to use black and isort
- Allow managers with delete to have custom additional parameters.
- This version removes python 2.7 support.
- Managers on registered models which set
use_in_migrationscan now be serialised for migrations.
Initial public release