Is it possible to define roles and permissions purely in code instead of in the database?

[MichelJonkman]

For the particular project I want to use this for I do not want the user to be able to edit roles and permissions. This means that using the database for these roles and permissions would come with more headaches to ensure that the application will always have up-to-date roles and permissions.

Of course I could use something like https://github.com/ryangjchandler/orbit as well but I'd prefer to not need an extra package for this. Is such a thing possible in a clean way?

[drbyte]

If you provide no UI to users for changing/setting permissions/roles, then all your roles and permissions ARE "in code", even if their state is set within the database. You would manage all of it via migrations that add/remove/assign permissions/roles.

But if you're wanting to skip the database entirely, then this package is not suitable for that situation. You would have to write code inside your User model (or other model) to check whether a user (who IS in the database) has permission to do a certain action, such as with functions like "is_admin()" (or whatever you want to name them) that would check against maybe the user's email address etc, to determine what access they have. Or could check against some sort of column/flag you've added to the User's table to check against ... but of course, THAT is still "in the database", so you're not "purely in code".

Before using a package like this one, most people would simply add a couple boolean fields to the User table in the db for certain permissions, and just check against those, as explained above. If that's all you require, then you don't need any package at all.

[MichelJonkman]

I meant more like, having the permissions defined in code but roles in database. Or having both only defined in code and linked to the user using a role id/slug. Using migrations is only more hassle and not very easy to read after a lot of changes have been done. The alternative would be to write a similar system but with both defined purely in code.

[drbyte]

I've always espoused that code should only check against permissions, and roles should be used merely for grouping permissions. And users are only assigned roles, not directly assigned any permissions.
And any UI's for roles/permissions are only involved with assigning roles to users. Never to create/delete roles/permissions.
Creation/Deletion of roles/permissions should be in migrations.
And if one wants to have a single migration file that shows all roles and permissions, then always copy any updates into that core migration file, and either delete the temporary migration that adds new ones, or write the migration in such a way that it only inserts the new record if not already present. That addresses the "easy to read" bit.

Obviously in an app that "needs" to have role and permission names be more dynamic, the above "rules" have to be broken. And that'd fine if the app really needs that. Many apps don't, but there's a temptation to make UI's for things we don't need! or only want as a dev for tinkering. But just use Tinker for that!

As for skipping the database altogether, well, if you only have half-a-dozen permissions just add flag columns to your Users db table, and don't overengineer things.
If you have a lot more, then I hope my approach described above helps you come up with a plan.