if(User::can('Create project', 'Project administration')){
// create project code
}
This can be added to your models, helpers or controllers if the user has been authenticated.\\ \\
In your views you can use
can('View credit card number', 'Account management')) : ?>
_{Credit card number}: {card.number}
The ideal scenario is to have an authenticated area under the admin module and unrestricted areas which do not require credentials under normal controllers.\\ \\
By default, actions on controllers inside the admin module are added to the Permissions table. In order to disable this behaviour on your controller, just define the attribute
var $protect_all_actions = false;
and select individual actions, if any, using
var $protected_actions = 'index,show,edit,delete';
==== Structure and Initial Data ====
The RBAC system consists of users, roles, permissions and extensions. Users may have one or more roles. Roles may have one or more permissions. Each permission has an extension.
When the plugin is installed, it is installed with the following data:
users -- roles ------------------ permissions ----------------------------------- extension
1 Application Owner
Administrator ---|-- add action ---------------|----------------- Admin::Users
|-- destroy action ---------------|
|-- edit action ---------------|
|-- index action ---------------|
|-- listing action ---------------|
|-- show action ------------------|
|-- manage users --------------------------------|-- Admin Menu Tabs
|-- Accounts (users controller, | |
| listing action) -------------------|
\-- Edit other users -------------/ |
|
Registered User ----|-- Dashboard (dashboard controller) ---------/
\-- index action -------------------------------- Admin::Dashboard
Admin::Permissions
Admin::Roles
If you're logged as Root (Application Owner role), new permissions found in your code will be added automatically to your permission pool. Just like with multilingual strings on Akelos.
==== Menu system ====
In order to benefit from the menu building system and automated privileges, your controllers in the admin module must extend AdminController, which is located at
./app/controllers/admin_controller.php
There are 2 different menus on the admin:
* An admin menu, which affects the whole admin module.
* A controller menu, which is dependent on each controller.
Menus are built by declaring the following attributes in your controller:
class Admin_UsersController extends AdminController
{
// just for this controller
var $controller_menu_options = array(
'Accounts' => array('id' => 'accounts',
'url'=>array('controller'=>'users',
'action'=>'listing')),
'Roles' => array('id' => 'roles', 'url'=>array('controller'=>'roles')),
'Permissions' => array('id' => 'permissions',
'url'=>array('controller'=>'permissions', 'action'=>'manage')),
);
// Which tab to select on the controller menu
var $controller_selected_tab = 'Accounts';
}
The code is quite straight forward.\\ \\
By convention, the selected tab will be the one that matches the array key with current controller name. In this case we manually set it to Accounts.\\ \\
By default, strings on the menu system are internationalized.\\ \\
You could also have set var $admin_menu_options = array(....); which would have summed/overridden the options inherited from the AdminController.\\ \\
To completely override the admin menu you must use var $_admin_menu_options = array(....);
==== The User Model ====
The admin provides a basic user model. It's quite limited on purpose, so you can evolve the basic model to suit your needs.
==== Plans for the Future ====
This is not a full featured automated admin. You'll have to custom code your intranets, but this might speed up the process.
It is anticipated that Admin may need to be customized. Therefore, when it is installed, files are copied into the project's main directories instead of being referenced in /app/vendor/plugins/Admin.
Plans for the future include:
* Implement non-http authentication screens.
* Implement password retrieval system.
* Implement simple user sign-up system.
* Implement simple and flexible user details system.
* Implement Simple user preferences system.
* Stop adding features :)
The following tasks are under active development:
* Delete the entering of Application Owner profile information from the Admin installation. Instead, the first time the Admin is executed, if there is no user data, an Add page for the Application Owner is opened.
* Implement non-http authentication screens.
* This version does not include a password retrieval feature. Instead, it includes three security question and answer combinations. When logging in, if the user has forgotten the password, the user may answer the questions. The user's profile should then be edited to change the password. This approach eliminates the need for a new password to be emailed to the user.
* The user sign-up allows the user to create his/her profile. It is initialized as Inactive. An Administrator must make the profile active and assign roles to the user.
* The user details at this time include (beside the login, password and email), name (first and last), address (2 fields. The 2nd is optional), postal code, city, state or province (optional), country code (drop down list), language (drop down list populated from config.php) and telephone.
Not under development at this time is a user preferences system. Possible user options that may be added are:
* Reimplementing http authentication (by uncommenting 3 statements). If this is done, a field may need to be checked so that non-http authentication is not triggered. The Admin installation code will need to be changed to get the application owner's choice and implement the code.
* Because the password is stored encrypted, it cannot be retrieved. If the security questions and answers are not desirable to handle the forgotten password situation, a page to generate a new password and send it to the user might be written. The Admin installation code will need to be changed to get the application owner's choice and implement the code.
* Making the state or province field a required one for certain countries. Change the field to a drop down list box for those countries.
* Including several telephone fields, with a description of each telephone number.
* Include business fields, such as company name, department name, etc. This may even be a separate table linked to the user.
* Now stop adding features. LOL