
Description
Thanks for maintaining laravel-authentication-acl 👍
N.B. I haven't checked whether this affects later versions of laravel-authentication-acl.
In v1.3.11, laravel-authentication-acl seems to make migrations that create the following tables (among others) and leave them as orphans:
- a
users_groups
table; - a
groups
table; and - a
permission
table.
The fact that these tables, in particular, are orphans, seems to be a bug. Why?
Because the users_groups.user_id
column seems intended to draw its contents exclusively from the users.id
column's contents. (So, ideally the migrations would declare a foreign-key relationship between the two.)
Similarly, the users_groups.group_id
column seems intended to draw its contents exclusively from the groups.id
column's contents. (So, ideally the migrations would declare a foreign-key relationship between the two.)
Also, there seems to be an implicit many-to-many relationship between the groups.permissions
column and the entries in the permission
table. Currently, laravel-authentication-acl appears to handle this by having the former contain text strings that are PHP arrays (I think) made by concatenating entries from permission.permission
with surrounding boilerplate. This seems needlessly fragile and un-RDBMS-like. (Ideally, the migrations would instead create a groups_permission
table, and declare foreign-key relationships betweengroups.id
and groups_permission.group_id
and between groups_permission.permission_id
and permission.id
.)