We need to find a smarter way to render the labels, based on the bool value

For now we have the legacy implementation

This is a bug request.

Prerequisites

• Are you running the latest version?
• Are you reporting to the correct repository?
• Did you check the documentation?
• Did you perform a cursory search?

Description

I have to create only selectoptions permission. In Create Resource form only one field checked. but after saving it will create all unneccesary permissions.

Steps to Reproduce

Expected behavior

Actual behavior

https://github.com/laravel-enso/PermissionManager/blob/12d89fcfd20fe1b1e1dceb79d36efdc634c53c05/src/app/Http/Controllers/PermissionTableController.php#L21

default should be "default" or just plain default
I checked it with PHP 7.2 + Postgresql 9.6

We can use the legacy format for permissions description.

This is a bug.

Prerequisites

• Are you running the latest version?
• Are you reporting to the correct repository?
• Did you check the documentation?
• Did you perform a cursory search?

Description

The search in permissions seems to be broken; reproduced on https://www.laravel-enso.com/system/permissions/

Steps to Reproduce

try to make any search on https://www.laravel-enso.com/system/permissions/

Expected behavior

Correct filtering

Actual behavior

blank result set

When the user is creating a new default permission it should be added to all existing roles.

There is a problem in the B/E when building the permission object when we have permission groups from the same parent with different different levels of depth

maybe put links in the main Enso docs, as well as StructureManager

This is a feature request.

Prerequisites

• Are you running the latest version?
• Are you reporting to the correct repository?
• Did you check the documentation?
• Did you perform a cursory search?

Description

The bulk of our permissions are defined on a general role basis; however (as we have a granular rollout of new features, amongst other reasons) we need to define/override certain permissions on a user-level

Proposal

Base

Add a permission_user pivot that is also checked along with permission_role to verify permission.

This includes introducing a permissions() object on the user directly; that will check the role's permissions too (to remain DRY)

TODO:

• add permissions() relationship in the User Model (similar to the one in the Role Model)
• write accompanying db migration (new permission_user table)
• update from role->permissions() to user-based required in:
  • menumanager: MenuTree's setPermissions()
  • core: AppState's routes()
  • searchable: Finder's permissions()
  • permissionmanager: AuthServiceProvider's boot() (access-route)
• Investigate implications for ConfigWriter (in rolemanager)

Expansion/optional (depending on your feedback)

• Add a flag to above pivot indicating if it's a allow or deny (to allow overriding in both directions.
• implement permission-edit-UI coupled to user (our implementation only requires code-wise changes; but since the UI is already there for roles it shouldn't be a big extra to implement this; making the feature more solid for more use cases)

Note that I'll be starting on this first thing next week, hopefully as a contribution to the framework as I believe there's many use cases for this (depending on your comments, will otherwise just override what I need)

It needs to be updated with the new formbuilder.