Common Modifications - Printable Version

The following warnings occurred:

Warning [2] Undefined variable $unreadreports - Line: 26 - File: global.php(961) : eval()'d code PHP 8.2.25 (Linux)

File	Line	Function
/global.php(961) : eval()'d code	26	errorHandler->error
/global.php	961	eval
/printthread.php	16	require_once

Warning [2] Undefined property: MyLanguage::$archive_pages - Line: 2 - File: printthread.php(287) : eval()'d code PHP 8.2.25 (Linux)

File	Line	Function
/printthread.php(287) : eval()'d code	2	errorHandler->error
/printthread.php	287	eval
/printthread.php	117	printthread_multipage

Common Modifications - Printable Version

+- UserSpice (https://userspice.com/forums)
+-- Forum: Miscellaneous (https://userspice.com/forums/forumdisplay.php?fid=28)
+--- Forum: Modifications and Hackery (https://userspice.com/forums/forumdisplay.php?fid=29)
+--- Thread: Common Modifications (/showthread.php?tid=271)

Pages: 1 2 3 4

Common Modifications - plb - 09-27-2016

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.

Common Modifications - brian - 09-27-2016

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

Common Modifications - mudmin - 09-27-2016

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

Common Modifications - plb - 09-27-2016

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

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

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

Common Modifications - mudmin - 09-27-2016

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

Common Modifications - mudmin - 09-27-2016

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

Common Modifications - smugwimp - 10-10-2016

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

Common Modifications - mudmin - 10-10-2016

I love it...thanks for sharing!

Common Modifications - Trioxin - 01-21-2017

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