view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    can recursively inherit other roles; for example, the role 'mega_mods'
    can inherit the roles 'mods' and 'editors'. Users of the 'mega_mods'
    role will assume all actions owned by the 'mods' and 'editors' roles.

    A commonly known use-case for this type of access control is message
    boards, where the administrator might wish to create roles with certain
    actions and associate users with the roles (more commonly called 'user
    groups'); for example, the admin can create an 'editor' role, giving
    users of this role the ability to edit and delete posts, but not any
    other administrative action. So in essence, this type of access control
    relieves the developer of deciding who gets to do what and passes these
    decisions to the end-user, which might actually be necessary in certain
    situations.

    The "Abilities" module is implemented as a Moo role (which makes it
    compatible with Moose code). In order to be able to use this mechanism,
    applications must implement a user management system that will consume
    this role. More specifically, a user class and a role class must be
    implemented, consuming this role. Entities is a reference implementation
    that can be used by applications, or just taken as an example of an
    ability-based authorization system. Entities::User and Entities::Role

lib/Abilities.pm  view on Meta::CPAN

for example, the role 'mega_mods' can inherit the roles 'mods' and 'editors'.
Users of the 'mega_mods' role will assume all actions owned by the 'mods'
and 'editors' roles.

A commonly known use-case for this type of access control is message boards,
where the administrator might wish to create roles with certain actions
and associate users with the roles (more commonly called 'user groups');
for example, the admin can create an 'editor' role, giving users of this
role the ability to edit and delete posts, but not any other administrative
action. So in essence, this type of access control relieves the developer
of deciding who gets to do what and passes these decisions to the
end-user, which might actually be necessary in certain situations.

The C<Abilities> module is implemented as a L<Moo role|Moo::Role> (which makes
it compatible with L<Moose> code). In order to be able to use this mechanism,
applications must implement a user management system that will consume this role.
More specifically, a user class and a role class must be implemented, consuming this role. L<Entities> is a reference implementation that can be used by applications, or
just taken as an example of an ability-based authorization system. L<Entities::User>
and L<Entities::Role> are the user and role classes that consume the Abilities
role in the Entities distribution.