09-27-2016, 12:22 PM
I think any kind of implicit authority on the basis of ID number goes against the fact that they are arbitrary ID #s.
I can give my $0.02 on how it could be implemented...
In the front end you have to change to allow for groups to be chosen as members of the group being edited. (Currently only users can be chosen)
Then in the database you
(1) add a column to (2) create a view which is simply a join of the table N levels deep - something like this:
CREATE VIEW flattened_user_permission_matches
SELECT upm.user_id, upm.permission_id
FROM User_Permission_Matches upm
WHERE user_is_group = 0
UNION
SELECT upm.user_id, upm2.permission_id
FROM User_Permission_Matches upm
LEFT JOIN User_Permissions_Matches upm2 ON (upm.user_is_group = 0 AND upm2.user_is_group = 1 AND upm.permission_id = upm2.user_id)
UNION
SELECT upm.user_id, upm3.permission_id
FROM User_Permission_Matches upm
LEFT JOIN User_Permissions_Matches upm2 ON (upm.user_is_group = 0 AND upm2.user_is_group = 1 AND upm.permission_id = upm2.user_id)
LEFT JOIN User_Permissions_Matches upm3 ON (upm3.user_is_group = 1 AND upm2.permission_id = upm3.user_id)
And now whenever you want to look up what have been assigned to a user you look in . What I've got above takes the nesting to 3 levels (user within group within group within group) (I think - I get confused on this stuff - I may only have 2 levels there) but it could easily be extended to N levels just by giving myself a headache for a little bit longer...
Obviously the SQL code above is just conceptual - I'm sure I've got typos throughout and I may have missed important conditions. If you decide to go this way I can look up that old project and copy/paste since it's already working fine there.
If it is easier to change the front end and leave the back-end (the functions that look up permissions) unchanged then you could easily change the name of the existing to and then name the view . You might be able to come up with a better name than ... :-) (Oh, wait! We could call it ! Actually, no, that probably just complicates the semantics to use both names for the same meaning...)
I can give my $0.02 on how it could be implemented...
In the front end you have to change
Code:
admin_permission.php
Then in the database you
(1) add a column
Code:
user_is_group
Code:
User_Permission_Matches
Code:
User_Permission_Matches
CREATE VIEW flattened_user_permission_matches
SELECT upm.user_id, upm.permission_id
FROM User_Permission_Matches upm
WHERE user_is_group = 0
UNION
SELECT upm.user_id, upm2.permission_id
FROM User_Permission_Matches upm
LEFT JOIN User_Permissions_Matches upm2 ON (upm.user_is_group = 0 AND upm2.user_is_group = 1 AND upm.permission_id = upm2.user_id)
UNION
SELECT upm.user_id, upm3.permission_id
FROM User_Permission_Matches upm
LEFT JOIN User_Permissions_Matches upm2 ON (upm.user_is_group = 0 AND upm2.user_is_group = 1 AND upm.permission_id = upm2.user_id)
LEFT JOIN User_Permissions_Matches upm3 ON (upm3.user_is_group = 1 AND upm2.permission_id = upm3.user_id)
And now whenever you want to look up what
Code:
permissions_id
Code:
flattened_user_permission_matches
Obviously the SQL code above is just conceptual - I'm sure I've got typos throughout and I may have missed important conditions. If you decide to go this way I can look up that old project and copy/paste since it's already working fine there.
If it is easier to change the front end and leave the back-end (the functions that look up permissions) unchanged then you could easily change the name of the existing
Code:
user_permission_matches
Code:
fred
Code:
user_permission_matches
Code:
fred
Code:
user_group_matches