Quick background

Small businesses like us face the following problems:

1. Our data is fragmented across various tools. There’s no connection between them. Finances are managed at one platform while hiring at completely different.
2. Difficult tracking organizational activities. Small updates in emails and Chat/Slack are getting harder to track as data is piling up.
3. Decision making is not easy as it’s hard to compare data from different sources.
4. Lots of boring repetitive tasks. Like generating invoices monthly, calculating taxes, etc.

We’re working on an Employee Portal to solve all the above problems for us. And we’re building it using what we know best: Laravel.

Why Laravel?

Laravel has helped us build meaningful ideas for ambitious people. Some from scratch, some that were already built, some that were dying but survived because we rewrote them in Laravel. Laravel provides a huge amount of ammunition to any developer. The inbuilt features are enough to make a robust application. On top of that, there are loads of community packages built only for Laravel. But the best thing about Laravel is not the features or packages, it’s the documentation.

With this tech decision so early in the application lifecycle, it was easy for us to architect everything around Laravel.

When we solve a problem, a new one shows up.

Quick on the problem

Talking about Employee Portal, we recently finished the Reports section for finances. From a single screen, we can now track our monthly invoices, cash inflow from local and foreign clients, individual project details, dues, GST and other taxes, bank charges etc. Our external accountant (let’s call him Saurav) needed access to the reports section. ONLY, the reports section. We didn’t want him to access HR data, knowledge sharing data, clients, and projects information.

Clearly, the platform needed an Access Control Mechanism. And that’s where Laravel made it easy.

Laravel community comes to the rescue

Going through our cataloged items, I figured we had already researched a lot on implementing ACL in Laravel. A year ago, while working on a Laravel based healthcare project, Tushar did some research and also wrote an article on how he implemented a modified role-based access control.

We figured we can follow the conventional way of ACL, using roles and permissions. We need to create the following tables:

1. roles [ id, name ]
   Contains the possible roles in the application. Superadmin, admin, employee, hr-manager etc
2. permissions [ id, name ]
   Contains the possible permissions a module can have. A module can be the reports, projects, clients, recruitment, library etc. For example, a permission named projects.view decides whether someone has access to view the projects.
3. permission_role [ permission_id, role_id ]
   The permissions a role has. For example, Saurav should only be able to view the finance reports. That means he’ll be assigned a role which will only have finance_reports.view role.
4. role_user [ role_id, user_id ]
   The roles a user has.

Before I started working on a custom roles and permissions package using Tushar’s implementation, I looked at existing solutions in the Laravel community. Laravel News mentioned the two best roles and permissions package:

1. Laravel-permission by Spatie
2. Bouncer by Joseph Silber

I’ve been a continuous follower of Spatie and especially their open source. Our team recently spoke at LaravelLive India and I got chance to meet Freek there. So, I was naturally more inclined to go with Spatie’s package than Bouncer. With just a brief look at the laravel-permission package, we figured that it aligned with our theory above and can be used in Employee Portal.

Easy execution in Laravel

Installing the package was a breeze. The documentation is up-to-date and easy to follow. Then we figured what default roles and permissions should be there in Employee Portal. We came up with five roles:

• super-admin
• admin
• employee
• hr-manager
• accountant

The permissions were common across all modules. Each entity has a set of CRUD permissions. For example, projects have,projects.viewprojects.create, projects.update, projects.delete. Using the laravel-permission package along with Laravel’s inbuilt authorization support, we were able to create a hybrid solution that aligned perfectly with our need.

Final roadblock

We used Laravel Socialite to log in users automatically into the portal using their GSuite email. Saurav doesn’t have a ColoredCow email. We had two options:

1. Either give him a ColoredCow GSuite account and email (and pay $5/mo so that he can see the reports once a month)
2. Or use Laravel’s native authentication with email and password so that he can log in with his existing email.

Technology is expected to lower down the business expenses. And that’s why everyone would go for the second option. So did we.

While implementing Socialite, we did some changes to the `users` table and added two new columns provider and provider_id. The provider column keeps which third-party tool authenticated the user. It can be Google, GitHub, Facebook etc. In our case, we restricted that only to Google. So, when we register a new user using Laravel’s native registration, we set the provider to “default”.

We assigned roles and permission in such a way that only certain roles should be able to see certain modules/entities. For example, an HR manager shouldn’t see the finances, only a super-admin can create a new user, employees can only see active projects, knowledge sharing, library etc.

Finishing the implementation

The new login page:

How a super-admin sees the dashboard:

How Saurav sees the dashboard:

Impact

When we granted Saurav access on Employee Portal, seeing all the summations, dues, and individual invoice details, I can tell there was happiness in his eyes. He knew he doesn’t have to do the repetitive boring calculations anymore.

We asked him what else can be done to make his work easier and he proposed some additions. We added client’s GST number, a link to directly download the invoice and some other finer details that he required.

What’s next?

We’ve completed the first version of ACL. Here’s the plan next:

1. A user management section where a super-admin can add/modify roles and permissions
2. Complete syncing of user roles between GSuite and Employee Portal. When a new role is added or a user’s role is changed in GSuite, it should get reflected in Employee Portal also.