Django app for implementing Helsinki profile GDPR API
Django app for implementing Helsinki profile GDPR API.
This library will allow a service using Helsinki profile to implement the GDPR
functionality required by open-city-profile
backend.
pip install helsinki-profile-gdpr-api
Authentication needs to be configured for the required django-heluser
Model which is to be used for GDPR operations should inherit SerializableMixin
and
include the required serialize_fields
property.
Define the following settings in your Django configuration.
| Setting | Example | Description |
|—-|—-|—-|
| GDPR_API_MODEL | “youths.YouthProfile” | GDPR profile model in the form app_label.model_name
. model_name is case-insensitive. |
| GDPR_API_QUERY_SCOPE | “jassariapi.gdprquery” | API scope required for the query operation. |
| GDPR_API_DELETE_SCOPE | “jassariapi.gdprdelete” | API scope required for the delete operation. |
Add the GDPR API urls into your url config:
urlpatterns = [
...
path("gdpr-api/", include("helsinki_gdpr.urls")),
]
The configuration above is the minimum needed. With those the app uses the default behaviour.
The app can also be configured in various ways if the default behaviour is not appropriate.
If GDPR API URLs are setup as explained in the Usage section above, the GDPR URL pattern isgdpr-api/v1/profiles/<uuid:pk>
. The first part (gdpr-api/
) can be set freely in the URL config. The
rest (v1/profiles/<uuid:pk>
) can be controlled with the GDPR_API_URL_PATTERN
setting. It can be set to
for example users/<uuid:user_id>/gdpr
. There needs to be exactly one named parameter in the URL
pattern. Its type needs to be uuid
, name can be chosen freely.
By default the GDPR_API_MODEL
is searched with its primary key, something like this:
from django.apps import apps
from django.conf import settings
model = apps.get_model(settings.GDPR_API_MODEL)
# The `id` is extracted from the request's URL
obj = model.objects.get(pk=id)
If pk
is not the correct field lookup to use, set the setting GDPR_API_MODEL_LOOKUP
to the correct
value, for example user__uuid
.
If changing the field lookup that way doesn’t solve the model instance searching, it’s also possible to
set the GDPR_API_MODEL_LOOKUP
setting to an import path to a function, for examplemyapp.gdpr.get_model_instance
. The function gets called whenever the GDPR API is accessed and the model
instance is needed. The function gets two arguments, the model class specified by the GDPR_API_MODEL
setting and the id from the GDPR API request’s path. The function must return an instance of the model
specified by the GDPR_API_MODEL
setting, if an instance is found. If no instance is found, then the
function must either return None
or raise a DoesNotExist
exception of the model.
It’s required that a User
model instance can be obtained from the GDPR API model instance specified by
the GDPR_API_MODEL
setting. By default the GDPR API model instance’s user
attribute is tried. If that
doesn’t work, it’s possible to configure a function that will provide the User
instance. This is
achieved by setting the import path of the function to the GDPR_API_USER_PROVIDER
setting, for examplemyapp.gdpr.get_user
. The function gets the GDPR API model instance as an argument.
By default the GDPR delete operation deletes the GDPR_API_MODEL
instance and the related User
instance. If that procedure isn’t sufficient for the project, it’s possible to override the data deletion
operation. This is achieved by setting the GDPR_API_DELETER
setting to an import path to a function, for
example myapp.gdpr.delete_data
. The function gets two arguments, the GDPR_API_MODEL
instance and a
boolean value indicating if this is a dry run or not.
The function gets called within a database transaction, which gets automatically rolled back if it’s a dry
run operation. Thus the function is free to do database modifications even in the dry run case. All
changes get rolled back afterwards. If it’s not a dry run case, then the transaction is committed and all
changes to the database are persisted.
If the data deletion isn’t allowed, the function has two ways to indicate this:
helsinki_gdpr.types.ErrorResponse
instance. This allows also communicating the reasonsdjango.db.DatabaseError
exception.It’s good to use a Python virtual environment:
$> python -m venv venv
$> source ./venv/bin/activate
Install development dependencies:
$> pip install -r requirements-dev.txt
Run tests:
$> pytest
This project uses Ruff for code formatting and quality checking.
Basic ruff
commands:
ruff check
ruff check --fix
ruff format --check
ruff format
pre-commit
can be used to install and
run all the formatting tools as git hooks automatically before a
commit.
New commit messages must adhere to the Conventional Commits
specification, and line length is limited to 72 characters.
When pre-commit
is in use, commitlint
checks new commit messages for the correct format.