srbac version 1.01
Enhancements:
Custom layout for srbac (layout must be in default application’s layout folder - protected/views/layouts/)
Add ajax indicators.
Can call and display user assignments directly from your user’s (or any other) controller by
$this->renderPartial('application.modules.srbac.views.authItem.assignments',
array("id"->$id),
false,
true);
//$id is the user's id
Spanish translation (Ricardo Obregon)
Russian translation (idle sign)
That’s exactly what i forgot to do. Now it works as it should 
Thanks again.
P.S. I want to get involved with portuguese/brazilian-portuguese translation for this module. Where do i start from?
There are 2 files to translate
messages/el_gr/srbac.php
and
views/authItem/install/installText.php
I attached a German translation, but only for messages/el_gr/srbac.php.
310
Nice module, works like a charm in 1.0.
Best regards,
schmunk
I started the implementation of the automatic creation of operations
It scans all the *Controller.php files in the applications controllers path and creates auth items in the form of
ControllerAction (eg PostCreate, PostShow etc)
(Maybe it’s time to think about adding aliases too)
I will also add two tasks (eg PostUser, PostManager)
the user will be assigned the show and list actions and the manager all actions.
Then all the controllers that need rbac will have to extend a BaseController which will overide the beforeAction method like this
protected function beforeAction($action) {
$access = ucfirst($this->id).ucfirst($this->action->id);
if(!Yii::app()->user->checkAccess($access)) {
$this->renderText('<br /><br /><br />You do not have authorization for the action '.$access);
return false;
} else {
parent::beforeAction($action);
return true;
}
}
This will automatically check if the user has the acces to the current Controller/action without having to add checking code in ever controller/action
What do you think of this?
As long as it’s optional, I think it is great.
The part when srbac automatically creates Operations (PostCreate, PostShow) is nice and obvious, but Tasks creation part is not. I think Operations, Tasks and Roles should be strictly defined: e.g. PostUser and PostManager are rather Roles than Tasks. Roles are nouns, whereas tasks should be verbs (ManagePost, ViewPost). The main problem here is how to differentiate Operations from Tasks (both are verbs).
Another question is how to auto-assign Operations to Tasks. Say we assign common ‘list’ and ‘show’ to ViewPost task and ‘manage’, ‘create’, ‘update’, ‘delete’ to ManagePost task. From now we can automatically assign all tasks containing ‘Manage’ to ‘Manager’ (much global than just ‘PostManager’) role, and tasks containing ‘View’ to ‘Viewer’/‘User’ role.
Much to think about.
As for beforeAction override ― good idea 
Yes defining what is task/role is a little confusing.
You are right PostManaging , PostViewing etc should be tasks while Administrator, User, PowerUser , PostManager etc should be roles.
Also the obvious assignments should be made automatically (show/list to a user task, create, update, delete to an administration task) and as you say view tasks to user role and manage tasks to Admin role.
Something like :
PostList , PostView => PostViewing
PostCreate, PostDelete, PostUpdate ,PostAdmin =>PostAdministrating
(What about all the other possible actions? Should be assigned to administrator or left unassigned?)
PostViewing=> User
PostAdministrating=> Administrator
This will be a simple form of rbac, for more complex assignments you can always use the assignments GUI
I think unassigned is a right choice as long as we cannot afford wizard in srbac GUI. GUI could provide something like contoller action to rbac conversion tool.
Let’s say we have a dropdown containing controllers list. When we pick a controller, its’ action methods are listed below, we check those needed and assign them to tasks (i.e. we transparantly create operations from selected actions and assign them to tasks).
And cause the idea gets more and more complicated (though only its internal php part) we should think about Anonymous role, without it rbac is a little inconsistent. Basically unauthenticated user should be automatically assigned to that role.
Hi spyros
In Tasks tab
design slightly down for opera browser but not in mozilla
and another question how to add confirm box for revoke role
please i am waiting for your reply
Can you post a screenshot, I checked opera and didn’t find anything wrong with the task tab.
Is really a need for a confirmation box? If you revoke something accidentally you can easily assign it again
Here is an alpha version of srbac 1.02
Please test it and tell me of any problems you find.
What’s new:
Automatic creation of operations based on controller/action names
Automatic creation of 2 tasks (a using and an administrating)
Assign (list, view, show) operations to using task (The list of actions to assign to using task may need to be configurable as an srbac attribute)
Assign all operations to administrating task
I checked that page with checkaccess if the authority removes his role authorithy then the page didn’t visible for him. since He lacks the permission to access that page.
So confirmation needed
since i created a operation called modifyrole
i checked this page with if the user has checkaccess of modifyrole the this page is allowed to him.
since this page is permitted for authority role only
so this problem occurs
here its screenshot
313
and another one slightly down
315
or anything i changed in views
That’s because the “Not assigned operations” phrase is wrapping. You may change the css to use smaller letters or a longer tabview.
If you revoke the authority role you can reassigned it by changing srbac debug attribute to true in the module’s configuration
Thanks. I changed width in srbac.css (class is srbac)
And another one how to minimize tabview’s width.
And last one is
I wanted to check the access modifyrole for displaying that page since other users or guests are not allowed to see it.
so i can’t set debug mode to true any other ideas to confirmation for revoke role
Regards
murugan
You have to change debug to true only for the time you need to reassign the authority role.
The confirmation for each revoke could be annoying
There are two options:
1 add a confirmation only when revoking the authority role
2 won’t let you revoke the autority role if there’s no other user with the authority role.
second option i need then how to do this
And another one how to minimize tabview’s width.
please give me idea
What do you mean by this?
Srbac version 1.02
http://www.yiiframework.com/extension/srbac/
Enhancements:
Creation of two tasks (using, administrating)
The operations are also assigned to these tasks based on the action’s name (all operations assigned to administrating and you can choose which actions are assigned to using)
Mass delete of automatic created operations, tasks for each controller
Added an SBaseController that must be extended for the use of automatic created auth items.
Cannot revoke Authority role if there’s no other user with that role
Custom not authorized page
srbac front page (just the links for authItems managing, assigning and user’s assignments)
srbac isInstalled() method
About the automatic creation of AuthItems:
You can automatically create operations/tasks for your controllers.
The operations are named as ContollerIdAction (eg PostView, PostDelete etc)
Also you can create 2 tasks named ControllerIdViewing, ControllerIdAdministrating (eg PostViewing, PostAdministrating).
All operations are assigned to the administrating task, and you can select witch operations are assigned to viewing task by editing the $_userOperations attribute in AuthController.php (This will be a srbac attribute in the next release)
If you also want srbac to automatically check for access in your controllers, your controllers should extend the SBaseController class in srbac module or any other class that extends this one.
SbaseController overides the beforeAction($action) method and checks if the user has access to the current controller/action.
protected function beforeAction($action) {
parent::beforeAction($action);
//create srbac access itemname
$access = ucfirst($this->id).ucfirst($this->action->id);
//Always allow access if $access is in the allowedAccess array
if(in_array($access, $this->allowedAccess())) {
return true;
}
//Allow access if srbac is not installed yet
if(!Yii::app()->getModule('srbac')->isInstalled()) {
return true;
}
// Check for srbac access
if(!Yii::app()->user->checkAccess($access) && !Yii::app()->params->debug) {
// You may change this messages
$error["code"] = "403";
$error["title"] = "You are not authorized for this action";
$error["message"] = "Error while trying to access " .$this->id."/".$this->action->id."." ;
//You may change the view for unauthorized access in your main cfg file
if(Yii::app()->request->isAjaxRequest) {
$this->renderPartial(Yii::app()->getModule('srbac')->notAuthorizedView,array("error"=>$error));
} else {
$this->render(Yii::app()->getModule('srbac')->notAuthorizedView,array("error"=>$error));
}
return false;
} else {
return true;
}
}
/**
* an array holding the items that are always allowed
* @return <Array>
*/
private function allowedAccess() {
return array (
'SiteLogin','SiteLogout','SiteIndex','SiteAdmin','SiteError',
'SiteContact'
);
}
As you can there’s a method allowedAccess() returning an array for the operations that are always allowed (this must be changed to fit your needs - Also will be a srbac attribute in next releasa)
There’s also a new attribute notAuthorizedView for defining the view to display when check access fails