Modification to udb_base.inc.php

[kennylucius]

I have been creating a bridge to my own application suite, and I'm quite impressed with CPG. Everything has gone pretty well so far, but I ran into a minor problem that required a modification to the file "udb_base.inc.php".

I am bridging my users/login, but I wish to use CPG groups to control access. Unfortunately, when bridging is enabled, CPG adds 100 to "group_id" even if "use_post_based_groups" is set false. I considered a few workarounds:

1) I could set

Code Select Expand

$this->field['usertbl_group_id'] = 'user_group-100'
This would work, but might break other things that need the field name.

2)  I might define the function "synchronize_groups()" so that the existing CPG groups are duplicated with higher group_ids. That would cause too many groups in the group control panel.  Deleting group_ids 1 through 4 would work okay until bridging is disabled...

3) I could re-define the function "get_users()"

I decided that this problem is probably a bug you should know about, so I'm recommending the following modification to function "get_users()" in "udb_base.inc.php":

Code Select Expand

line 205:   if ($CONFIG['bridge_enable']) . . .
should be:  if ($CONFIG['bridge_enable'] && $this->use_post_based_groups) . . .

Kenny Lucius
http://www.awardannals.com/

[Joachim Müller]

you should avoid modifications of coppermine core files. Not sure why you have to modfiy it.

[kennylucius]

Are you familiar with the bridge system?

[Joachim Müller]

a wee bit. Actually, I'm not the bridging expert - Nibbler probably could answer your question in more detail. Please don't PM him though. If he wants to answer, he will do so publicly.

[kennylucius]

Okay. Thanks for your response, by the way.

Well, in a nutshell, the bridging system handles groups in a funny way. CPG groups get assigned IDs beginning with "1". When bridging is enabled, the default behavior is to copy the groups from the bridged BB into CPGs group table with IDs starting at "101". The core bridge script just authomatically adds 100 to the IDs when it creates the SQL SELECT.

Unfortunately, this behavior doesn't work if you want to use CPGs groups and not the BB groups. When SELECTing users, the script creates a JOIN on group "101", and there is no group "101", so no users are returned. It looks as if there are no users in the User Manager panel.

There seems to be some evidence that the option to use CPG groups was recognized and available at one point in the development, but it seems to have been left behind. I have seen quite a few hacks and unhacks in the core code indicating an interesting and exciting history, and I'm fairly certain that the original intention of the bridge system was to allow the use of CPG groups. The mod that I have proposed seems fairly obvious to me, though I admit I've only had a few days worth of exposure to the system.

BTW, I didn't make the core mod lightly. That's why I'm going to the trouble of discussing it here.

Kenny Lucius

[Nibbler]

You either use all the groups from the forum as they are or you have these cast to simpler groups of only registered, admins, guests. CPG groups are not taken into account atall. There is no need to change udb_base since the bridge file you create extends the base class and can redefine any of its methods.

[kennylucius]

Well, I suppose it's a feature request rather than a bug, then. I didn't understand as well as I thought.

I do understand, however, that bridging is meant to be used for bulletin boards that have their own users and groups. My intentions are a bit different. When I'm done, I'll show it to you. Perhaps you'll think it's worth it.

[kennylucius]

I gave up. Now I am trying simply to bridge my own groups, and I'm running into the same problems. Why on Earth did you decide to add 100 to group_id in some cases? The behavior is inconsistent, and it's causing problems.

As it stands, I'm deleting lines 87-91 from udb_base.inc.php

Code Select Expand

if ($this->use_post_based_groups){
  $USER_DATA['has_admin_access'] = (in_array($USER_DATA['groups'][0] - 100,$this->admingroups)) ? 1 : 0;
} else {
  $USER_DATA['has_admin_access'] = ($USER_DATA['groups'][0] == 1) ? 1 : 0;
}


'has_admin_access' is set in the previous line, in a call to get_user_data() with the real group_ids, so there's no reason to undo the setting in those lines.

Does this thing really work with other BBs?

[Nibbler]

Because if we setup the basic groups as 1,2,3 and try to import groups 3,4,5 from a forum it's not going to work. The +100 is there to stop the group numbers colliding. If you don't want to do that then don't. You can redefine any method you don't like with your own version with your bridge file. The bridge system has to cater for over a dozen different apps and their different ways of organising groups and users and admin rights. You can't expect it to be perfect for your own system but it can be made to work. Any modifications you make to udb_base will just make updating harder for you in the future.

[kennylucius]

I can only conclude that you don't know what you're talking about, or you don't know what I'm talking about.

I've tried it many different ways--the thing doesn't work. If I don't use the +100 hack, no user "has_admin_access". If I do use it, none of the permissions get applied to the user. The only way is to re-define the authenticate function, which seems to be your excuse for not looking.

If you can't see the bug, then the hell with you.

[Nibbler]

Nice.