Fixes #3233 Cascading usergroup moderator permissions broken

[Starpaul20]

Fixes #3233

[dvz]

$perms values can be inadvertently downgraded when a group with lower permissions is checked after a group with higher permissions in the same forum.

Some variables, like $perms[$action], can be undefined when used with max() (same with existing code, but we can start fixing those given the code will be carried over to future branches).

[Eldenroot]

@PaulBender - are you willing to complete this?

[Starpaul20]

I can't really, I just changed computers and I'm still settling it in.

[Ben-MyBB]

@PaulBender Ping, if you get time.

[Eldenroot]

@PaulBender - please can you finish this one? To review and merge :) thank you!

[Starpaul20]

Don't know if I can, I had to delete and recreate my repository awhile back.

[Eldenroot]

This PR is a small one... maybe recreate it? :) thx

[Starpaul20]

Yeah, I'll try to fix this and recreate it this week if I can.

[Starpaul20]

After playing around with this issue last night, I've come to the conclusion that the original issue probably isn't worth fixing, at least in 1.8.

[yuliu]

euantorano has said in Discord on a relating issue #3776:

Yes, permissions can be confusing sometimes especially for users with lots of groups
That’s why 2.0 was going to use a yes/no/never system like XenForo’s
I’d also like a way to visualise the exact permissions for any given user

[Ben-MyBB]

@euantorano thoughts on this one?

[euantorano]

Will have to review and reacquaint myself, but based on comments it sounds like we may be looking at a different approach in the future.

[yuliu]

I have some idea about resolving #3996 (including #3233 that this PR tries to resolve), however the PR resolving #3996 and this PR will conflict with each over.

Anyway, the way getting mod permissions from multiple user groups of this PR seems fine to me, though primitive but does some work and should have no side effect.

[lairdshaw]

With the intention of reviewing unmerged 1.8 PRs and issues to try to get them merged where possible, I've just revisited this PR, and I think the concerns raised by @dvz above, and @yuliu in #3996 mean that merging this PR would create as many problems as it solves - e.g., it would mean that the comment // User settings override usergroup settings no longer applies unconditionally, given that a $value of zero in the usergroup code block would override an earlier non-zero permission set in the preceding user code block.

Recommendation: close this PR without merging it, and revisit permissions in 1.9, taking careful account of @yuliu's and @dvz's comments/analyses.