GitLocker: The Coding Marketplace

Description:

edcauth 0.3.89

edc-auth
Authentication and permissions for the Edc

Default Groups
The default groups are required for the normal operation of an EDC deployment. The default groups are:

ACCOUNT_MANAGER: members may add/change and delete user accounts
ADMINISTRATION: members may view the Administration page
AUDITOR: members may view all forms but have no add/change permissions.
CLINIC: members may add/edit/delete all CRFs, Requisitions, Actions and other required clinic trial data entry forms. They may also view the Requisition page of the Lab section;
EVERYONE: members may access the EDC;
LAB: members may perform all functions in the Lab section (Edit requisitions, receive, process, pack, manage manifests, etc);
PHARMACY:
PII: members may view all personally identifiable data and edit forms that manage such data (Screening, Consents, Patient registration);
PII_VIEW: members may view personally identifiable data but have no add/edit permissions for any of the forms that store such data.

Permissions
Permissions use Django’s permission framework, therefore, all permissions are linked to some model.
Permissions don’t always naturally link to a model. In such cases, a dummy model is created.
For example, with Navigation bars from edc_navbar. Permissions to follow an item on a
navigation bar are associated with model edc_navbar.Navbar. A similar approach is used for
listboard permissions using edc_dashboard.Dashboard.

Extending permissions with site_auths global
A module can add new or update existing groups and roles and even add custom codenames.
The site_auths global autodiscovers configurations from auths.py in the root of your module.
The site_auths global gathers but does not validate or change any data in django’s
group/permission models or the Edc’s role model.
The site_auths global gathers data:
* to ADD new groups,
* to update codenames for an existing group,
* to add a new role
* to update the group list for an existing role
* to add to the list of PII models
* to specifiy custom functions to run before and after groups and roles have been updated
For example,
# auths.py
from edc_auth.constants import CLINICIAN_ROLE, STATISTICIAN_ROLE
from edc_auth.site_auths import site_auths

from edc_protocol_violation.auth_objects import (
PROTOCOL_VIOLATION,
PROTOCOL_VIOLATION_VIEW,
protocol_violation_codenames,
protocol_violation_view_codenames,
)

# add a new group specific to models in this module
site_auths.add_group(*protocol_violation_codenames, name=PROTOCOL_VIOLATION)
# add a new group specific to models in this module
site_auths.add_group(*protocol_violation_view_codenames, name=PROTOCOL_VIOLATION_VIEW)
# update the existing role CLINICIAN_ROLE to add the group PROTOCOL_VIOLATION
site_auths.update_role(PROTOCOL_VIOLATION, name=CLINICIAN_ROLE)
# update the existing role STATISTICIAN_ROLE to add the group PROTOCOL_VIOLATION_VIEW
site_auths.update_role(PROTOCOL_VIOLATION_VIEW, name=STATISTICIAN_ROLE)
As a convention, we define group names, lists of codenames and custom functions auth_objects.py.
In the above example, the auth_objects.py looks like this:
# auth_objects.py

# declare group names
PROTOCOL_VIOLATION = "PROTOCOL_VIOLATION"
PROTOCOL_VIOLATION_VIEW = "PROTOCOL_VIOLATION_VIEW"
# add/change/delete/view codenames
protocol_violation_codenames = (
"edc_protocol_violation.add_protocoldeviationviolation",
"edc_protocol_violation.change_protocoldeviationviolation",
"edc_protocol_violation.delete_protocoldeviationviolation",
"edc_protocol_violation.view_protocoldeviationviolation",
)
# view only codename
protocol_violation_view_codenames = (
"edc_protocol_violation.view_protocoldeviationviolation",
)

AuthUpdater
The AuthUpdater class runs in a post_migrate signal declared in apps.py.
The AuthUpdater reads and validates the data gathered by site_auths. Once all
validation checks pass, the AuthUpdater updates Django’s group and permission
models as well as the Edc’s Role model.
Validation checks include confirming models refered to in codenames exist. This means that
the app where models are declared must be in your INSTALLED_APPS.
During tests having all codenames load may not be ideal. See below on some strategies for testing.

Testing SiteAuths, AuthUpdater
An app sets up its own groups and roles using the site_auths global in auths.py. To test just your apps
configuration, you can prevent site_auths from autodiscovering other modules by setting:
EDC_AUTH_SKIP_SITE_AUTHS=True
You can prevent the AuthUpdater from updating groups and permissions by setting:
EDC_AUTH_SKIP_AUTH_UPDATER=True
You can then override these attributes in your tests
@override_settings(
EDC_AUTH_SKIP_SITE_AUTHS=True,
EDC_AUTH_SKIP_AUTH_UPDATER=False
)
class TestMyTests(TestCase):
...
Above the site_auths global autodiscover is still disabled but the AuthUpdater is not.
In your test setup you can update site_auths manually so that your tests focus on the
add/update or groups/roles/codenames/tuples relevant to your app.
You can emulate autodiscover behaviour by explicitly importing auths modules needed for your tests.
For example:
from importlib import import_module

from django.test import TestCase, override_settings
from edc_auth.auth_updater import AuthUpdater

class TestAuths(TestCase):
@override_settings(
EDC_AUTH_SKIP_SITE_AUTHS=True,
EDC_AUTH_SKIP_AUTH_UPDATER=True,
)
def test_load(self):
import_module(f"edc_dashboard.auths")
import_module(f"edc_navbar.auths")
AuthUpdater(verbose=True)
You can clear the site_auths registry and add back specific items need for your tests.
For example:
# taken from edc-dashboard
@override_settings(EDC_AUTH_SKIP_SITE_AUTHS=True, EDC_AUTH_SKIP_AUTH_UPDATER=False)
class TestMyTests(TestCase):
def setUpTestData(cls):
site_auths.clear()
site_auths.add_group("edc_dashboard.view_my_listboard", name=CLINIC)
site_auths.add_custom_permissions_tuples(
model="edc_dashboard.edcpermissions",
codename_tuples=(("edc_dashboard.view_my_listboard", "View my listboard"),),
)
AuthUpdater(verbose=False, warn_only=True)
return super().setUpTestData()

def test_me(self):
...

Importing users
You create user accounts by importing a specially formatted CSV file. Once an account is created a “Welcome” email may be sent.
Import users from a CSV file with columns:
username
is_staff
is_active
first_name
last_name
job_title
email
mobile
alternate_email
site_names: a comma-separated list of sites
role_names: a comma-separated list of roles
Then import the users from your application commandline
python manage.py import_users --csvfile=/Users/erikvw/meta_users.csv --notify-to-test-email=ew2789@gmail --resource-name=meta.clinicedc.org --resend-as-new

Legacy notes
Important: If you are upgrading from edc_base.auth:
The userprofile table is now in edc_auth. edc_auth has one migration for this table.
Copy the same table from edc_base and fake the edc_auth migration.
CREATE TABLE edc_auth_userprofile LIKE edc_base_userprofile;

INSERT edc_auth_userprofile SELECT * FROM edc_base_userprofile;
python manage.py migrate edc_auth --fake
You can now run the edc_base migration safely.