v1.3.11: users_groups, groups, and permission tables are orphans

[ghost]

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.)