USE ONLY ON FRESH AKELOS INSTALLATIONS AS IT MIGHT OVERRIDE YOUR EXISTING FILES!!!

If you are using an old version of Akelos, replace it with a new version before installing the Admin Plugin.

The Admin Plugin installer does have code that prevents/controls overwriting of files, but they can be overridden and your files overwritten.

The Admin plugin assists you on creating a basic admin with RBAC (permission, role and user management).
It is not meant to be used as a “fit all” solution but as a simple to adapt/modify base for your applications.
The Admin plugin, like Akelos itself, is based on conventions for building navigation and handling user permissions.
The user permission interface is heavily inspired by the Community plumbing section of Drupal.

  ./script/plugin install admin

You will be prompted for the URL path and master account details.
After installing you can visit http://yourhost.com/admin (by default admin)

You can use the admin scaffold generator exactly like the scaffold generator.

  ./script/generate admin_scaffold

It will generate controllers inside the the admin module, views that match the admin conventions, and helpers with permission check-points in order filter the links to show.

Keeping track of who can do what on your admin is plain and simple. Permissions are grouped/scoped into Extensions for clarity.
You can restrict access to portions of your application using code like

    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

    <? if($admin_helper->can('View credit card number', 'Account management')) : ?>
      <p>_{Credit card number}: {card.number} </p>
    <? endif; ?>

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';

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.

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 admin provides a basic user model. It's quite limited on purpose, so you can evolve the basic model to suit your needs.

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 2^nd 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.