UBB.Developers Forums UBB.threads 6 V6 Modifications V6 Mod Ideas User restrictions

I'm working on a hack to add the following user privileges: profile-edit-enabled, pm-enabled and login-enabled.

profile-edit-enabled - if set, user can make changes in the My Home area. (This might need to be further broken down.)
pm-enabled - if set, user can send and receive private messages
login-enabled - if set, user can log in

I'm trying to figure out the best way to approach this. Here are some possibilities:

(1) Add three new columns to w3t_Users.

(2) Add the three new columns to w3t_Banned.

(3) Create a new table w3t_X_UserRestrictions, with these three columns, along with the username and/or user number. The rationale here is that normally users would have all these privileges, so only a small fraction of the users would require having a row in this table.

(4) Use the permission groups (somehow) to implement this functionality.

My design goals are to (A) minimize the amount of hacking required (to facilitate new-version-updates), (B) avoid database-compatibility issues with new versions, and (C) keep the script efficient.

What do you think is the best approach? Any feedback is welcome.

Hi Dave,

Not sure of the answer to your question, but I thought I'd add a functionality suggestion: if you're trying to put some partial controls in place for users, it might be useful to create a "Moderated" designation for users... in other words, instead of making a whole board "Moderated", you could designate posts from certain unruly users as requiring approval prior to display.

I would think that usergroups would be the most flexible way of approaching it, as it would require no database changes (I thinkg)

Cheers,
Max

Moderating individual users is a good idea. However, right now I'm focusing on changes needed to support UBB.classic's feature set, so I'll defer that one.

I gave some thought to how to implement this with #4 (permission groups). For example, I could add a group "No private messages", and add users to that group to disable their private-message privileges. The private-message code would check for membership in that group. Similarly, I could add groups "No login" and "No profile editing". This appproach seems kind of ugly.

I'm leaning toward using (2) or (3). (3) would probably be less likely to cause conflicts with future versions.

You're right, it sounds like (2) is probably less disruptive.

If you do it with usergroups though, you probably would want to set up groups with the various combinations... ie
group A: No Login, No PM, no profile
group B: No Login, No PM, yes profile
etc.
which would probably get unwieldy if you have a lot of parameters.

Max

Being able to set a user to moderated would be extremely useful. It's less confrontational. Trying to keep someone from posting entirely turns into a cat and mouse game where they just become determined to find a way around it.

Greg

I agree.

Although an even better method for a determined troublemaker might be to make his posts visible only to himself.

As I mentioned above, right now I'm focusing only on porting UBB.classic features, which doesn't include moderating individual users. However, the method I'm using for storing the restrictions will be general enough to accomodate a "moderated" flag. The harder part would be the user interface.

Progress report:

I decided to go with #2.

I've added the following columns to w3t_Banned:
B_X_NoEditPost
B_X_NoEditProfile
B_X_NoMessage
B_X_NoPost
B_X_NoRate

And I've changed user::check_ban(), and all calls to it, to check these privileges. For example, if there's a row in w3t_Banned with B_Username='XYZ', B_X_NoPost='0' and B_X_NoMessage='1', then user XYZ can post, but not send private messages.

I wanted to add a B_X_NoLogin flag as well, but I had problems with that, as described here.