Abilities
view release on metacpan or search on metacpan
Copyright (C) 1989 Free Software Foundation, Inc.
51 Franklin St, Suite 500, Boston, MA 02110-1335 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The license agreements of most software companies try to keep users
at the mercy of those companies. By contrast, our General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. The
General Public License applies to the Free Software Foundation's
software and to any other program whose authors commit to using it.
You can use it for your programs, too.
When we speak of free software, we are referring to freedom, not
price. Specifically, the General Public License is designed to make
sure that you have the freedom to give away or sell copies of free
software, that you receive source code or can get it if you want it,
that you can change the software or use pieces of it in new free
programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of a such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
General Public License and to the absence of any warranty; and give any
other recipients of the Program a copy of this General Public License
along with the Program. You may charge a fee for the physical act of
transferring a copy.
2. You may modify your copy or copies of the Program or any portion of
it, and copy and distribute such modifications under the terms of Paragraph
1 above, provided that you also do the following:
a) cause the modified files to carry prominent notices stating that
you changed the files and the date of any change; and
b) cause the whole of any work that you distribute or publish, that
in whole or in part contains the Program or any part thereof, either
with or without modifications, to be licensed at no charge to all
third parties under the terms of this General Public License (except
that you may choose to grant warranty protection to some or all
third parties, at your option).
c) If the modified program normally reads commands interactively when
run, you must cause it, when started running for such interactive use
in the simplest and most usual way, to print or display an
announcement including an appropriate copyright notice and a notice
that there is no warranty (or else, saying that you provide a
warranty) and that users may redistribute the program under these
conditions, and telling the user how to view a copy of this General
Public License.
d) You may charge a fee for the physical act of transferring a
copy, and you may at your option offer warranty protection in
exchange for a fee.
Mere aggregation of another independent work with the Program (or its
derivative) on a volume of a storage or distribution medium does not bring
the other work under the scope of these terms.
3. You may copy and distribute the Program (or a portion or derivative of
it, under Paragraph 2) in object code or executable form under the terms of
Paragraphs 1 and 2 above provided that you also do one of the following:
a) accompany it with the complete corresponding machine-readable
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
Appendix: How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to humanity, the best way to achieve this is to make it
free software which everyone can redistribute and change under these
terms.
To do so, attach the following notices to the program. It is safest to
attach them to the start of each source file to most effectively convey
the exclusion of warranty; and each file should have at least the
"copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) 19yy <name of author>
1. You may make and give away verbatim copies of the source form of the
Standard Version of this Package without restriction, provided that you
duplicate all of the original copyright notices and associated disclaimers.
2. You may apply bug fixes, portability fixes and other modifications derived
from the Public Domain or from the Copyright Holder. A Package modified in such
a way shall still be considered the Standard Version.
3. You may otherwise modify your copy of this Package in any way, provided that
you insert a prominent notice in each changed file stating how and when you
changed that file, and provided that you do at least ONE of the following:
a) place your modifications in the Public Domain or otherwise make them
Freely Available, such as by posting said modifications to Usenet or an
equivalent medium, or placing the modifications on a major archive site
such as ftp.uu.net, or by allowing the Copyright Holder to include your
modifications in the Standard Version of the Package.
b) use the modified Package only within your corporation or organization.
c) rename any non-standard executables so the names do not conflict with
roles()
Returns a list of all role names that a user object belongs to, or a
role object inherits from.
Example return structure:
( 'moderator', 'supporter' )
NOTE: In previous versions, this method was required to return an array
of role objects, not a list of role names. This has been changed in
version 0.3.
actions()
Returns a list of all action names that a user object has been
explicitely granted, or that a role object has been granted. If a
certain action is constrained, then it should be added to the list as an
array reference with two items, the first being the name of the action,
the second being the name of the constraint.
Example return structure:
( 'create_posts', ['edit_posts', 'only_his'], 'comment_on_posts' )
NOTE: In previous versions, this method was required to return an array
of action objects, not a list of action names. This has been changed in
version 0.3.
is_super()
This is a boolean attribute that both user and role objects should have.
If a user/role object has a true value for this attribute, then they
will be able to perform any action, even if it wasn't granted to them.
get_role( $name )
This is a method that returns the object of the role named $name.
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
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
lib/Abilities.pm view on Meta::CPAN
=head2 roles()
Returns a list of all role names that a user object belongs to, or a role object
inherits from.
Example return structure:
( 'moderator', 'supporter' )
NOTE: In previous versions, this method was required to return
an array of role objects, not a list of role names. This has been changed
in version 0.3.
=cut
requires 'roles';
=head2 actions()
Returns a list of all action names that a user object has been explicitely granted,
or that a role object has been granted. If a certain action is constrained, then
it should be added to the list as an array reference with two items, the first being
the name of the action, the second being the name of the constraint.
Example return structure:
( 'create_posts', ['edit_posts', 'only_his'], 'comment_on_posts' )
NOTE: In previous versions, this method was required to return
an array of action objects, not a list of action names. This has been changed
in version 0.3.
=cut
requires 'actions';
=head2 is_super()
This is a boolean attribute that both user and role objects should have.
If a user/role object has a true value for this attribute, then they
lib/Abilities.pm view on Meta::CPAN
return $abilities;
}
=head1 UPGRADING FROM v0.2
Up to version 0.2, C<Abilities> required the C<roles> and C<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, C<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 C<roles> and C<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 C<roles>
lib/Abilities.pm view on Meta::CPAN
I apologize for any inconvenience this might have caused.
=head1 AUTHOR
Ido Perlmuter, C<< <ido at ido50 dot net> >>
=head1 BUGS
Please report any bugs or feature requests to C<bug-abilities at rt.cpan.org>, or through
the web interface at L<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.
=head1 SUPPORT
You can find documentation for this module with the perldoc command.
perldoc Abilities
You can also look for information at:
=over 4
lib/Abilities/Features.pm view on Meta::CPAN
=head2 plans()
This method returns a list of all plan names that a customer has subscribed to,
or that a plan inherits from.
Example return structure:
( 'starter', 'diamond' )
NOTE: In previous versions, this method was required to return
an array of plan objects, not a list of plan names. This has been changed
in version 0.3.
=cut
requires 'plans';
=head2 features()
This method returns a list of all feature names that a customer has explicitely
been given, or that a plan has. If a certain feature is constrained, then
it should be added to the list as an array reference with two items, the first being
the name of the feature, the second being the name of the constraint.
Example return structure:
( 'ssh_access', [ 'multiple_users', 5 ] )
NOTE: In previous versions, this method was required to return
an array of feature objects, not a list of feature names. This has been changed
in version 0.3.
=cut
requires 'features';
=head2 get_plan( $name )
Returns the object of the plan named C<$plan>.
lib/Abilities/Features.pm view on Meta::CPAN
return $features;
}
=head1 UPGRADING FROM v0.2
Up to version 0.2, C<Abilities::Features> required the C<plans> and C<features>
attributes to return objects. While this made it easier to calculate
available features, it made this system a bit less flexible.
In version 0.3, C<Abilities::Features> changed the requirement such that both these
attributes need to return strings (the names of the plans/features). If your implementation
has granted plans and features 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 plans and features
any way you want in a database (either by names or by references), just
as long as you correctly provide C<plans> and C<features>.
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 C<plans>
lib/Abilities/Features.pm view on Meta::CPAN
I apologize for any inconvenience this might have caused.
=head1 AUTHOR
Ido Perlmuter, C<< <ido at ido50 dot net> >>
=head1 BUGS
Please report any bugs or feature requests to C<bug-abilities at rt.cpan.org>, or through
the web interface at L<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.
=head1 SUPPORT
You can find documentation for this module with the perldoc command.
perldoc Abilities::Features
You can also look for information at:
=over 4
( run in 0.337 second using v1.01-cache-2.11-cpan-c333fce770f )