.. _acl:

====================
Access Control Lists
====================

How permissions work
--------------------

On top of that we use the ``access.models.GroupUser`` and ``Group`` to define
what access groups a user is a part of, and each group has ``rules`` defining
which permissions they grant their members, separated by ``,``.

Permissions that you can use as filters can be either explicit or general.

For example ``Admin:EditAddons`` means only someone with that permission will
validate.

If you simply require that a user has `some` permission in the `Admin` group
you can use ``Admin:%``.  The ``%`` means "any."

Similarly a user might be in a group that has explicit or general permissions.
They may have ``Admin:EditAddons`` which means they can see things with that
same permission, or things that require ``Admin:%``.

If a user has a wildcard, they will have more permissions.  For example,
``Admin:*`` means they have permission to see anything that begins with
``Admin:``.

The notion of a superuser has a permission of ``*:*`` and therefore they can
see everything.


Django Admin
------------

Django admin relies on 2 things to gate access:
- To access the admin itself, ``UserProfile.is_staff`` needs to be ``True``. Our custom implementation allows access to users with a ``@mozilla.com`` email.
- To access individual modules/apps, ``UserProfile.has_perm(perm, obj)`` and ``UserProfile.has_module_perms(app_label)`` need to return ``True``. Our custom implementation uses the ``Group`` of the current user as above, with a mapping constant called ``DJANGO_PERMISSIONS_MAPPING`` which translates Django-style permissions into our own.