Common Modifications

[plb]

I think the "implementation" could be as simple as making mention that "Groups are supported" in the front-page advertisement for US. Changing the front-end would be icing on the cake. Simply documenting somewhere that "permissions=groups" from a DB and code perspective would be enough from that perspective.

[brian]

Okay, I'm definitely on board with that then.

[mudmin]

Me too...but since we're doing 5.0, we might as well change the permissions UI to groups also.

[plb]

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

Code:

admin_permission.php

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

Code:

user_is_group

to

Code:

User_Permission_Matches

(2) create a view which is simply a join of the

Code:

User_Permission_Matches

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

Code:

permissions_id

have been assigned to a user you look in

Code:

flattened_user_permission_matches

. 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

Code:

user_permission_matches

to

Code:

fred

and then name the view

Code:

user_permission_matches

. You might be able to come up with a better name than

Code:

fred

... :-) (Oh, wait! We could call it

Code:

user_group_matches

! Actually, no, that probably just complicates the semantics to use both names for the same meaning...)

[mudmin]

I like the concept. I was so thrilled that I got those functions to work when I wrote US4, I wasn't ready to make it more complicated.

[mudmin]

I like the concept. I was so thrilled that I got those functions to work when I wrote US4, I wasn't ready to make it more complicated.

[mudmin]

I like the concept. I was so thrilled that I got those functions to work when I wrote US4, I wasn't ready to make it more complicated.

[smugwimp]

There is a free service at avatars.adorable.io that I use.

They assign a random avatar based on email address, but once it's assigned, it stays.

I substitute the 'gravatar' code with this:

$grav = "http://api.adorable.io/avatar/100/" . strtolower(trim($user->data()->email));

the '100' is the square pixel size of the avatar, and you'll want to change it a little depending on the page you're using it with.

Users don't really get a 'choice', which is a downside to some. For me, I don't need to worry about it.

Just my 2¢.

Cheers!

-- Smug

[mudmin]

I love it...thanks for sharing!

[Trioxin]

That DB.php mod is nice but why not just use $db->query()?