Menu instance tutorial _ php instance for Yii2rbac permission Control

This article mainly introduces information about the menu instance tutorial of Yii2rbac permission control, you can refer to the previous article to introduce yii2 to build a perfect backend and implement rbac permission control instances. In this tutorial, yii2's background construction and rbac permission control are perfectly implemented, if you have not implemented this function, please first read the above and then refer to this article, because this article is complete and supplemented on the basis of the above.

Some of our experts have reported how to control the menu at last. I don't know how to control the menu. I can't help it, but it seems that you haven't finished it! It's really not that complete. Today, let's look at how we can achieve menu-perfect permissions. First, let's talk about the main content. If you don't need to read it, you just need to share it with people in need.

Add a menu using the menu table

Adminlte is perfectly displayed in the left-side menu.

Customize the icon in front of the menu and display it

How to control menu display or hide

Page operation buttons are not displayed if they are not permitted

Only buttons with Operation permissions are displayed in the gridview.

Well, that's almost the case. If you have other requirements on permission control menus, please leave a message below to share your ideas.

First, let's take a look at the general effect of the image preview. Otherwise, how can you learn it.

First, we first access the routing page/dmin/route/index, try to select all on the left, then move to the right, and then remember to assign relevant access permissions to the current user.

Next, access the menu list/admin/menu/index and click Add menu. If you do not have the permission to access the menu at this time, please temporarily allow the current user to access any permissions in the as access file of the configuration file, and remove the as access settings when we have added the permissions. Remember, otherwise, do not return to me if the permission is invalid.

Here, we first fill in the four fields marked with red

For example, we want to add the first-level menu "permission management"

Enter "permission management" for the name, because it is a level-1 menu, leave the parent name blank, and select "/admin/default/index" for routing, if any route is matched, visit the routing page to move the selected on the left to the right.

Ing is actually a matter of sorting. For example, if I have added two menus, if the ing value is 1, the above value is 2 and below 1. Here we enter the number 1.

We will talk about "data" later.

Follow the method described above to add a level-2 menu "permission control ".

You only need to enter the parent name here as the first-level name we just added "permission management. Others are the same. If you do not want to perform the operation, read it twice. It is best to add all the menu items of permission management, because we need to continue and you can practice more.

Now we have added a menu.

Let's take a look at the next step, and use the background framework we set up earlier to present it.

use mdm\admin\components\MenuHelper; echo dmstr\widgets\Menu::widget( ['options' => ['class' => 'sidebar-menu'], 'items' => MenuHelper::getAssignedMenu(Yii::$app->user->id), ] );

Isn't it easy? What? I don't know how to use dmstr. Sorry, I have already said it many times. I need to check the combination of the above menu first.

OK. Refresh the page and check your menu. Although we haven't fully implemented the functions we want, you should be able to see your menu display here.

Next we will go to our key points and difficulties. We need to implement the small icon in front of the menu and complete the menu to hide and control.

Do you remember the only option "data" that was not filled in when we first created the menu? For the convenience of subsequent operations, we will fill in the icons and hidden options here. Take the level-2 menu "background user management" as an example. Let's take a look at the current status of our menu,

Make sure to fill in the following code in the "data" item on the Update page. If you have a new idea, follow my ideas before making changes, because we will perform the operation later.

{"icon": "fa fa-user", "visible": false}

Yes, we fill in a piece of json code for this "data" item. Next we will make a slight correction to the code that shows the menu. In order to make it easier for you to read the code, $ callback is directly written on the page. You can continue encapsulation optimization later.

Use mdm \ admin \ components \ MenuHelper; <? Php $ callback = function ($ menu) {$ data = json_decode ($ menu ['data'], true); $ items = $ menu ['children ']; $ return = ['label' => $ menu ['name'], 'url' => [$ menu ['route '],]; // process our configuration if ($ data) {// visible isset ($ data ['visable']) & $ return ['visable'] = $ data ['visable']; // icon isset ($ data ['icon ']) & $ data ['icon '] & $ return ['icon'] = $ data ['icon ']; // other attribute e.g. class... $ return ['options'] = $ Data;} // The default icon displayed when no icon is configured (! Isset ($ return ['icon ']) |! $ Return ['icon ']) & $ return ['icon'] = 'fa fa-circle-O '; $ items & $ return ['items '] = $ items; return $ return ;}; // here we have optimized echo dmstr \ widgets \ menu :: widget (['options' => ['class' => 'sidebar-menu '], 'items' => MenuHelper: getAssignedMenu (Yii :: $ app-> user-> id, null, $ callback),]);?>

Yes, you are not mistaken. The code is a little long. Let's analyze it in a simple way. In fact, our $ callback method only analyzes the "data" item in the menu we added above. It is not hard to see that we have made judgments on the icon and visible respectively and appended them to the current menu.

At this point, we have made some twists and turns to realize the addition of icons and the hiding of menus. If you have other attributes that need to be configured, you can continue to configure them separately.

Now, we still have two tasks to complete. We recommend that you customize the gii template for your project for your convenience, if you do not support custom gii templates, you can refer to the custom gii templates. When you find the functions that need to be done later, I think you will be amazed at our operations here.

For ease of operation, we add a test table here. We will first generate a model + curd with the unmodified gii template. We first assign all the permissions of test/* to the currently logged-on user and add a piece of data. Open/test and we can see the following. Note the two labels in the figure.

Then open the test/index. php file and modify the two marked locations as follows:

Use mdm \ admin \ components \ Helper; <? Php // if (Helper: checkRoute ('create') {echo Html: a ('create test', ['create'], ['class' => 'btn btn-success ']) ;}?> <? = GridView: widget ([//...... 'columns '=> [//...... ['class' => 'yii \ grid \ ActionColumn ', 'template' => Helper :: filterActionColumn ('{view} {update} {delete}'),]);?>

Now let's refresh the page/test and try again. It seems that there is no change. Don't worry. Now we revoke the/test/create and/test/update permissions of the current user. Then, refresh the page to see the effect. Let's take a look.

That is to say, the button without permission disappears. When you manually access/test/create, you will find that you are not authorized.

If your gii template is custom, I believe you will quickly add permission control to all the operations in the template generated by it. Is it very happy?

Finally, our menu's explanation of permission control is basically over. For a long time, there are not many things in retrospect, but I hope it will help you.