`fairdm.management.commands.create_dev_accounts`#

Create the five development accounts FairDM ships.

Nothing in the framework otherwise creates a named account: there is the one superuser a portal’s environment variables produce, and a fake-data command for records. This command creates one account per shipped portal role and one holding none, through the ORM rather than a fixture. Person subclasses a polymorphic Contributor, so a fixture row would need a content-type primary key that differs between databases, and a fixture cannot refuse to load at all.

The accounts share a published password (password, also written down in docs/developers/reference/development-accounts.md), so the refusal below, not secrecy, is their whole safety outside development. fairdm.E501 (fairdm/conf/checks.py) is the second line of defence: it reports any of these five addresses found on a portal this command never ran against, such as one restored from a production database copy.

Module Contents#

Classes#

Command

Create the development accounts, one per portal role and one holding none.

Data#

`DEV_ACCOUNT_PASSWORD`
`DEV_ACCOUNTS`
`DEV_ACCOUNT_EMAILS`
`EXAMPLE_ACCOUNTS`
`PROFILE_ACCOUNTS`
`EXAMPLE_ACCOUNT_EMAILS`

API#

DEV_ACCOUNT_PASSWORD#: ‘password’

DEV_ACCOUNTS#: ()

DEV_ACCOUNT_EMAILS#: ‘frozenset(…)’

EXAMPLE_ACCOUNTS#: ((‘regular.user@example.com’, ‘Regular’, ‘User’, False, False), (‘staff.user@example.com’, ‘Staff’, …

PROFILE_ACCOUNTS#: ((‘admin.user@example.com’, ‘Admin’, ‘User’, False, False), (‘member.user@example.com’, ‘Member’, ‘U…

EXAMPLE_ACCOUNT_EMAILS#: ‘frozenset(…)’

class Command(stdout=None, stderr=None, no_color=False, force_color=False)#

Bases: django.core.management.base.BaseCommand