On the QCode.in site Saqueib Ansari has written up a tutorial showing how to use a package in Laravel applications to manage roles and permissions easily. This package, spatie/laravel-permission, compliments the current Laravel roles/permissions handling with a few handy features that make management and evaluation simpler.

Although laravel comes with Policies to handle the authorization but I wanted to have an option to just create permissions in the database which we can manage by a UI in the admin panel, pretty standard. we can implement our own role and permission from scratch but I am going to use [spatie/laravel-permission](https://github.com/spatie/laravel-permission) package for this. This package was inspired by Jeffrey ways screencast and it’s very well maintained and very easy to use. It has everything we need and plays very well with Laravel Gate and Policies implementations.

He walks through the creation of a new Laravel application, running the auth:make to generate the authentication functionality and adding the spatie/laravel-permission package to the service provider. He creates several models for permissions and roles and updates the User model with a new trait. Once the migrations are run, he creates a default permission set. Then it's on to the code for the endpoints to work with roles (including syncing them with permissions). He then moves over to the views, showing how to use the can helper to determine if a user has access, creating an Authorizable trait and an AuthorizationException handler. Finally the tutorial wraps up with the roles and permissions management functionality complete with code and screenshots of the result.

On the Laravel News site there's an article posted from Sharon Steed covering some habits of highly productive tech teams including topics like trust, meetings and understanding roles.

There’s always a lot of talk about “culture” on tech teams. And that makes sense: managers generally hire people that will fit in well with the group they’ve assembled because they know there’s more to work than just doing the job. Being able to get along with your coworkers, being reliable, and looking the part are also important. A big part of building a solid company culture is about creating an environment which helps your employees be productive. Unfortunately, a lot of what we do in tech has the opposite effect.

She talks about the role of perks in an effective workforce and how, despite some seeming very nice on the outside, can cause burnout as it encourages longer work hours than normal. From there she moves into some suggestions about "meeting culture" and some of the major drawbacks to meetings (including how they can distract from "real, paying work"). There's a nice flow chart included in the post too that can help you determine if a meeting is really necessary or not. From there she goes on to talk about the other two topics mentioned above - employees knowing and understanding their roles and fostering trust between them through things like delegation and effective listening.

Continuing on from his previous post in his series, Jani Hartikainen looks again at the Zend_Acl component for access control and how to deal with its "abstract" role.

In the context of Zend_Acl, access to resources is given to roles: A role might be a user's name, a group a user belongs to, or just roles, which have been assigned to a user from the admin panel. Since Zend_Acl only defines an "abstract" role, resource and privilege, how do we deal with all of these using it? Read more to find out! I'll also be addressing some more ways to deal with allowing and denying access.

He looks at how you can use your own role scheme (custom strings with meaning to you and your application) to define what the user can and can't do. He creates a plugin/interface for the framework to help handle this style so that he can compare the user's current identity against the resource type(s) they want to check.