If your app has both roles and permissions you generally always want to be checking for permissions and not roles. This way you can shuffle permissions between roles, add new roles, etc, and the code never changes.
A great example is if you offer pricing tiers on your site. You’ve got Basic, Pro and Enterprise. As the app evolves and the featureset changes you may find that Basic users get more and more functionality that used to only belong to Pro. If you’re checking only roles then you’ll have to constantly be swapping out those checks…
if (hasRole('pro') || hasRole('basic'))
But permissions never have to change:
if (hasPermission('inviteUser'))
If you’re using permissions nothing changes—Basic users now have more permissions than they did yesterday. But no code changes! And if you give your Product Manager an admin screen that lets them change permissions on a role you’ll be their best friend for life! 
At my last job we also added Role Limits—it determined how many of “something” a certain role could perform. For example, basic could perform only 10 searches a month, but Pro could perform an unlimited number. So we’d add a check like:
if (!hasPermission('search')) throw new AuthenticationError
if (!underLimit('search')) throw new LimitError
// permission granted, proceed...
If your app only has roles then that’s all you can check anyway, so disregard the above suggestions.