view release on metacpan or  search on metacpan

README  view on Meta::CPAN

  assigned_role( $role_name )
    This method receives a role name and returns a true value if the
    user/role is a direct member of the provided role. Only direct
    membership is checked, so the user/role must be specifically assigned to
    the provided role, and not to a role that inherits from that role (see
    "does_role( $role )" instead).

  does_role( $role_name )
    Receives the name of a role, and returns a true value if the user/role
    inherits the abilities of the provided role. This method takes
    inheritance into account, so if a user was directly assigned to the
    'admins' role, and the 'admins' role inherits from the 'devs' role, then
    "does_role('devs')" will return true for that user (while
    "assigned_role('devs')" returns false).

  abilities()
    Returns a hash reference of all the abilities a user/role object can
    perform, after consolidating abilities inherited from roles (including
    recursively) and directly granted. Keys in the hash-ref will be names of
    actions, values will be 1 (for yes/no actions) or a single-item
    array-ref with the name of a constraint (for constrained actions).

UPGRADING FROM v0.2
    Up to version 0.2, "Abilities" required the "roles" and "actions"
    attributes to return objects. While this made it easier to calculate
    abilities, it made this system a bit less flexible.

    In version 0.3, "Abilities" changed the requirement such that both these
    attributes need to return strings (the names of the roles/actions). If
    your implementation has granted roles and actions stored in a database
    by names, this made life a bit easier for you. On other implementations,
    however, this has the potential of requiring you to write a bit more
    code. If that is the case, I apologize, but keep in mind that you can
    still store granted roles and actions any way you want in a database
    (either by names or by references), just as long as you correctly
    provide "roles" and "actions".

    Unfortunately, in both versions 0.3 and 0.4, I made a bit of a mess that
    rendered both versions unusable. While I documented the "roles"
    attribute as requiring role names instead of role objects, the actual
    implementation still required role objects. This has now been fixed, but
    it also meant I had to add a new requirement: consuming classes now have
    to provide a method called "get_role()" that takes the name of a role
    and returns its object. This will probably means loading the role from a
    database and blessing it into your role class that also consumes this
    module.

    I apologize for any inconvenience this might have caused.

AUTHOR
    Ido Perlmuter, "<ido at ido50 dot net>"

BUGS
    Please report any bugs or feature requests to "bug-abilities at
    rt.cpan.org", or through the web interface at
    <http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Abilities>. I will be
    notified, and then you'll automatically be notified of progress on your
    bug as I make changes.

SUPPORT
    You can find documentation for this module with the perldoc command.

            perldoc Abilities

    You can also look for information at:

    *   RT: CPAN's request tracker

        <http://rt.cpan.org/NoAuth/Bugs.html?Dist=Abilities>

    *   AnnoCPAN: Annotated CPAN documentation

        <http://annocpan.org/dist/Abilities>

    *   CPAN Ratings

        <http://cpanratings.perl.org/d/Abilities>

    *   Search CPAN

        <http://search.cpan.org/dist/Abilities/>

LICENSE AND COPYRIGHT
    Copyright 2010-2013 Ido Perlmuter.

    This program is free software; you can redistribute it and/or modify it
    under the terms of either: the GNU General Public License as published
    by the Free Software Foundation; or the Artistic License.

    See http://dev.perl.org/licenses/ for more information.