[Jifty-commit] r2326 - jifty/trunk/lib/Jifty/Manual

jifty-commit at lists.jifty.org jifty-commit at lists.jifty.org
Tue Dec 5 02:21:57 EST 2006


Author: agentz
Date: Tue Dec  5 02:21:57 2006
New Revision: 2326

Modified:
   jifty/trunk/lib/Jifty/Manual/AccessControl.pod

Log:
[Jifty::Manual::AccessControl]
- wording improvements.
- reformatted the POD a bit.

Modified: jifty/trunk/lib/Jifty/Manual/AccessControl.pod
==============================================================================
--- jifty/trunk/lib/Jifty/Manual/AccessControl.pod	(original)
+++ jifty/trunk/lib/Jifty/Manual/AccessControl.pod	Tue Dec  5 02:21:57 2006
@@ -1,32 +1,38 @@
 =head1 NAME
 
-Jifty::Manual::AccessControl
+Jifty::Manual::AccessControl - Using Jifty's default ACL system
 
 =head1 DESCRIPTION
 
 
 Out of the box Jifty-based applications have an ACL system.  The system 
-automatically validates ACLs on Jifty::Record objects by calling the method
+automatically validates ACLs on L<Jifty::Record> objects by calling the method
 C<current_user_can> before any create, read, update, or delete operation.
 In all cases, the arguments passed to the CRUD operation are passed as 
-extra arguments to current_user_can.
+extra arguments to C<current_user_can>.
 
 On C<create()>, we reject the operation if C<current_user_can('create')>
 returns FALSE.
 
-On C<_value()> or C<I<somefieldname>>, we reject the operation  if C<current_user_can('read')> returns false.
+On C<_value()> or C<I<somefieldname>>, we reject the operation
+if C<current_user_can('read')> returns false.
 
-On C<_set()> or C<I<set_somefieldname>>, we reject the operation  if C<current_user_can('write')> returns false.
+On C<_set()> or C<I<set_somefieldname>>, we reject the operation
+if C<current_user_can('write')> returns false.
 
 
-On C<delete()>, we reject the operation  if C<current_user_can('delete')> returns false.
+On C<delete()>, we reject the operation  if C<current_user_can('delete')>
+returns false.
 
-Out of the box, C<current_user_can> returns 1. When you want to actually check ACLs, you'll need to override C<current_user_can()> in your C<Jifty::Record> subclass.
+Out of the box, C<current_user_can> returns 1. When you want to actually 
+check ACLs, you'll need to override C<current_user_can()> in your
+C<Jifty::Record> subclass.
 
 It's likely that at some point, you'll decide you want to ask other
-questions on certain types of operation.  Say, you only want to let
+questions on certain types of operations.  Say, you only want to let
 administrators update the C<paid_account> field. In that case, you'd override
-C<check_update_rights()> to look for the C<admin> right rather than the C<update> right, if the C<FIELD> is C<paid_account>.
+C<check_update_rights()> to look for the C<admin> right rather than the 
+C<update> right, if the C<FIELD> is C<paid_account>.
 
 =head1 ENABLING ACCESS CONTROL USING THE LOGIN PLUGIN
 
@@ -38,7 +44,7 @@
       - Login: {}
 
 Then, create an C<App::Model::User> class that derives from
-C<Jifty::Plugin::Login::Model::User>, for example like that:
+C<Jifty::Plugin::Login::Model::User>, for example:
 
     use strict;
     use warnings;
@@ -58,7 +64,7 @@
 The model that manages C<User> Records is not limited to the plugin's
 definition. It can be expanded by providing an additional schema
 definition. Every column here will be added to the plugin's
-columns. Simply add a schema definition block like the following:
+columns. Simply add a schema definition block like this:
 
     use Jifty::DBI::Schema;
     use App::Record schema {
@@ -74,9 +80,9 @@
 a chance to add more data to the C<CurrentUser> object. This method
 will automatically get called after the Plugin's C<_init> is done.
 
-=head2 Templates defined by the Login plugin
+=head2 Templates defined by the C<Login> plugin
 
-To avoid the need for repetitive work, the Login plugin already
+To avoid the need for repetitive work, the C<Login> plugin already
 defines a couple of usable templates:
 
 =over 4
@@ -84,8 +90,8 @@
 =item F</login>
 
 provides a login screen with a signup option. After
-successful login, the current Continuation is called. If no
-Continuation exists, the template sitting at the base URL (F</>) is called.
+successful login, the current continuation is called. If no
+continuation exists, the template sitting at the base URL (F</>) is called.
 
 =item F</logout>
 
@@ -93,17 +99,17 @@
 
 =item F</signup>
 
-allows a user to sign up himself. As a default
-behavior a confirmation mail is sent out that has to get followed by
+allows a user to sign up himself/herself. By default
+a confirmation mail is sent out that has to get followed by
 the user.
 
 =item F</chgpasswd>
 
-allows a user to change his password.
+allows a user to change his/her password.
 
 =item F</passwordreminder>
 
-after entering his mail address, the user will receive a mail that
+after entering his/her mail address, the user will receive a mail that
 contains a link to F</let/reset_lost_password>.
 
 =item F</let/confirm_email>


More information about the Jifty-commit mailing list