Abilities

 view release on metacpan or  search on metacpan

INSTALL  view on Meta::CPAN

9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
    % 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

76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
  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

87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
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

38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
        } 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