Abilities

 view release on metacpan or  search on metacpan

INSTALL  view on Meta::CPAN

    % cpanm Abilities

If you are installing into a system-wide directory, you may need to pass the
"-S" flag to cpanm, which uses sudo to install the module:

    % cpanm -S Abilities

## Installing with the CPAN shell

Alternatively, if your CPAN shell is set up, you should just be able to do:

    % cpan Abilities

## Manual installation

As a last resort, you can manually install it. Download the tarball, untar it,
then build it:

    % perl Makefile.PL
    % make && make test

README  view on Meta::CPAN

    are the user and role classes that consume the Abilities role in the
    Entities distribution.

  CONSTRAINTS
    Generally, an ability is a yes/no option. Either the user can or can't
    perform a specific action. At times, this might not be flexible enough,
    and the user's ability to perform a certain action should be
    constrained. For example, a user might be granted the ability to edit
    posts in a blog, but this ability should be constrained to the user's
    posts only. The user is not to be allowed to edit posts created by other
    users. "Abilities" supports constraints by allowing to set a name-based
    constraint when granting a user/role a certain ability. Then, checking
    the user's ability to perform an action can include the constraint, for
    example:

            if ($post->{user_id} eq $user->id && $user->can_perform('edit_posts', 'only_his')) {
                    # allow
            } else {
                    # do not allow
            }

lib/Abilities.pm  view on Meta::CPAN

role in the Entities distribution.

=head2 CONSTRAINTS

Generally, an ability is a yes/no option. Either the user can or can't perform
a specific action. At times, this might not be flexible enough, and the user's
ability to perform a certain action should be constrained. For example, a user
might be granted the ability to edit posts in a blog, but this ability should
be constrained to the user's posts only. The user is not to be allowed to edit
posts created by other users. C<Abilities> supports constraints by allowing to
set a name-based constraint when granting a user/role a certain ability. Then,
checking the user's ability to perform an action can include the constraint,
for example:

	if ($post->{user_id} eq $user->id && $user->can_perform('edit_posts', 'only_his')) {
		# allow
	} else {
		# do not allow
	}

Here, the C<Abilities> module allows you to check if the user's ability is constrained,

lib/Abilities/Features.pm  view on Meta::CPAN

	} else {
		&initiate_http_connection();
	}

=head1 DESCRIPTION

This L<Moo role|Moo::Role> extends the ability-based authorization
system defined by the L<Abilities> module with customer and plan management
for subscription-based web services. This includes paid services, where
customers subscribe to a plan from a list of available plans, each plan
with a different set of features. Examples of such a service are GitHub
(a Git revision control hosting service, where customers purchase a plan
that provides them with different amounts of storage, SSH support, etc.)
and MailChimp (email marketing service where customers purchase plans
that provide them with different amounts of monthly emails to send and
other features).

The L<Abilities> role defined three entities: users, roles and actions.
This role defines three more entities: customers, plans and features.
Customers are organizations, companies or individuals that subscribe to
your web service. They can subscribe to any number of plans, and thus be