NSN Groups

Subject Matter Expert Joined: Feb 23, 2004 Posts: 358

I have done quite a bit of modification to my installation to take advantage of NSN Groups. I have a few questions, since I cannot find any documentation on the deeper workings.

Ok, so I understand the Nuke Groups is point-based, and NSN is permission based. Got that. Wink

This whole thing of kinda wrapping it around the phpBB Groups has me scratching my head. Does anyone know why this was done? For a long time, I wrote my custom modules using phpBB permissions, because I simply loved their all-in-one data being always available in the userdata array. Now I am working with other people's modules and back to Nuke style for this and that, and I'm using these groups. Here's what I'm not getting, as far as the logic to it (again, got the usage).

If you create a Group in Forums Admin, it is not added to NSN Groups. If you add it to NSN Groups, it is added to Forum Group.

If you create a Forum Group and assign a Moderator, that Moderator can actually access the Group and edit the Group. If you assign a Moderator to NSN, they cannot access that Group from within Nuke without being logged in as an Admin. This is strange... I do not understand why the Groups feature was not just ripped out of phpBB and made into a Module like both the Private Messages and Member List?

Unless there is a reason NSN Groups exists in its current form for a reason I'm not understanding, then I'm probably going to go ahead and create a module from phpBB Groups. Can anyone enlighten me on some of these questions? Thanks folks!

- Keith

Posted: Wed Dec 01, 2010 4:28 pm

PS -

In trying to figure out how an external NSN Group Moderator could actually manage their group, I realized that the only way was to make them a Nuke Admin with access to Groups only. Of course, they are not any longer restricted to their Group, and that's a problem.

The other problem, and the reason for this PS, is that there was an error in the Admin checking portion of the Groups admin script.

So:

Code:

$query2 = $db->sql_query('SELECT `aid`, `email`, `radminsuper` FROM `'.$prefix.'_authors` WHERE `aid`=\''.$aid.'\'');


list($aname, $amail, $radminsuper) = $db->sql_fetchrow($query2);


$db->sql_freeresult($query2);

Is listing aname against aid, and that proves false when compared to the value in the modules table.

So:

Code:

$query2 = $db->sql_query('SELECT `name`, `email`, `radminsuper` FROM `'.$prefix.'_authors` WHERE `aid`=\''.$aid.'\'');


list($aname, $amail, $radminsuper) = $db->sql_fetchrow($query2);


$db->sql_freeresult($query2);

worked a little better there. Smile

- Keith

Posted: Wed Dec 01, 2010 5:03 pm

I would guess the only reason you are seeing a moderator in the NSN Groups is simply so you have the data to enter into the forum group.

That being said it would probably be fairly easy to expand the front-end of groups to allow the moderator to moderate the group.

Posted: Wed Dec 01, 2010 5:37 pm

Thanks Palbin -

Permissions are probably one of the greatest assets to a CMS, just as important as they are to Forums. It certainly helps to have the ability to delegate areas to certain people, relieving some administration duties from the site admin(s).

So let me ask a few more questions, and these are pointed towards the new RN builds in development...

If things like integrating phpBB Groups are done, we are, in fact, integrating more of phpBB into Nuke itself. Is the forward direction of RN still including phpBB? I'd hate to commit a whole bunch of integration work just to have it come to naught (besides legacy use).

Is -any- work being done with NSN Groups to modify or expand it in any way in future versions of RN? Again, doing double work would not be prudent... or are future builds of RN just going with NSN Groups pretty much the way it sits?

If these are confidential answers, please run permission by Gaylen to give me a few brief answers, and they can be PM'd to me.

Thanks again!
- Keith

Posted: Wed Dec 01, 2010 8:42 pm

These are very logical questions and ones that we've discussed here over the years. For a couple of my custom modules I use NSN groups to control permissions rather than using the normal (slightly insane IMHO) normal *Nuke methods (which include adding admins to the authors table and which uses a comma delimited list of admin names inside the modules table to control access to administration of specific modules, as well as case, links and ops in an admin directory and various other yada yada junk). So on a form I might have a general area (for all users) and an area that only admins can see and I just control the echoing of the restricted part by doing a if (in_groups ($gname) { test where $gname is the number of the group I want to restrict access to.

But that's getting off track. Montego and I have discussed a number of times the desirability of having NSNgroups "integrated" the way it is with PHPBB. I've pointed out some of the same illogical aspects that you just pointed out. From other discussions we've had it seems very likely that RN is going in the direction of supporting a "bridge" to PHPBB3 rather than the current "integrated" approach to PHPBB2. Palbin or Raven can correct me if I'm wrong on that.

You asked in your post:

Quote:

If you create a Group in Forums Admin, it is not added to NSN Groups. If you add it to NSN Groups, it is added to Forum Group.

.

Good question. Think about the history and you'll know the answer. PHPBB was developed without giving a thought to any form of *nuke. They never intended it to be integrated and my understanding is that if you ask any form of *nuke question over at PHPBB you'll get axed. The code in RN for managing PHPBB groups comes direct from PHPBB so of course it will not do anything about nsngroups. Now, when nsngroups was developed the authors did know about PHPBB and so they built the logic in to also update PHPBB groups whenever you did something with a nsngroup. In my opinion that was a mistake and it will be rectified if we ever get to fully implement a PHPBB bridge (which will also make even installing PHPBB optional).

Now, if you've used NSNgroups to maintain any reasonable size number of groups you'll know that it is very 1990's technology. If you have, say 1500 users as I do, then to add certain ones to a group means paging through screen after screen of user listings, selecting those you want in the group (based solely on username) and saving them screen by screen. Scroll forward to another screen listing more users before you have saved the ones on the first screen and all your selections are lost. Even if you know that you want username "donkeyman" in your group you have to play guess work about what page in the list donkeyman might be on.

I think your approach to fixing this problem has some merit. Just develop a separate NSNgroup manager module that can eventually take the place of the current one. Maybe leave them both in place for one intermediate release even as we iron any kinks out. I've been fooling a bit with using AJAX for this. My idea would be to create some kind of drop down list of current groups and another list of users and maybe have it so that you could scroll over the list of groups and have a pop up box of the users currently in the group and another searchable list of the users who aren't and be able to drag and drop back and forth, be able to preview your results and then apply the update through AJAX. I haven't gotten the AJAX part working and have limited time to work on it. And I have to confess I don't have the full interface details worked out.

It might also be helpful to have some sort of criteria based approach to building nsngroups ... say all users who haven't visited the site in 6 months could be put on a investigate_to_delete group.

Posted: Wed Dec 01, 2010 10:08 pm

What fkelly said is pretty accurate. Your best bet would be to develop an enhanced NSN group module. We would be more than willing to evaluate your changes and include them at some point.

Posted: Thu Dec 02, 2010 10:38 am

Ok, thanks for all this input, and especially thanks for patiently getting me up to date on previous discussions and thoughts of moving forward!

While I can imagine some webmasters having just a pure CMS need, I would think them a minority, and the majority really wanting the forums to develop a sense of community. That to me means forums-driven mentality, because as it stands now, you can disable forums if you wish, therefore the minority are taken care of.

These answers you've given me has caused about 100 more questions I have... I'll try to be as brief as possible with my thoughts.

First, over the many years of integrating phpBB 2.x into Nuke, it is embedded into so much of the code, it's hard to imagine doing the work to rip it all out. As far as the NSN Groups go, I'm hearing that basically if I would want to work on that, I'm free to, because...? No one else is? This is an example of a module that does transactions with phpBB code and database tables. If what you're telling me pans out (phpBB 2.x dropped in favor of a bridge to whatever other Forum), then the Groups module absolutely MUST be handled by someone. Of course, this is not the only module along those lines. Even current webmasters who disable Forums, if they use NSN Groups for anything (and they DO, since its basic function out-of-the-box is to control Module permissions), then interactions with the Forums code and database ARE taking place, regardless.

Then we get into other integrated modules that use a vast majority phpBB code and db structure, Private Messaging and Member List. While a Member List would be fairly easy to re-write, a PM system would NOT be so easy. Guess what I'm saying is, if Forums became "optional", is there an "in-house" proprietary Private Messaging system being built for RN, or does that become an option dependent on whether you opted for Forums or not?

It's impossible to think all of this out without having an opinion develop. I'm sure this has all been fleshed out over discussions I wasn't here for, and maybe code development based on those decisions is significantly moving forward, but I can't help but to ask... wouldn't it just be best to keep phpBB 2.x? It isn't supported by phpBB group any longer, which means since it was always open source and freely modifyable, why wouldn't the RN team just take that over and give it their stamp? We don't have "upgrade" issues any longer, which was the biggest frickin' PITA back years ago.

Let me take a slightly different route, that might have easier answers... what does phpBB 3 have, in terms of features and/or look, that we couldn't code into phpBB 2.x? phpBB 2.x is just an engine. It can be put into any "chassis", or theme, that we want. A new RN forum system could be developed that was now INDEPENDENT of phpBB (insert your version here), but utilizing the engine of 2.x. I frankly feel that the only reason phpBB 3 was pushed out the door was to chase vBulletin and try to stay "relevant". I don't see why a separate RN team isn't put together that ONLY deals with Forums, Private Messaging and other inter-site communications, while the original team continues development of the CMS portion. As it stands now, basically the CMS team is busy doing what they do, and is just tossing in software developed by a different group. A group that doesn't like Nuke. Hates Nuke. Won't even speak to us. No, I never understood that, either.. but it is how it is.

Most of us Nuke techs have extremely intricate knowledge of phpBB structure, theme, and code hooks from being forced to work with it for so many years. Why a bridge to a software team who is hostile towards us, was happy to be rid of us, and would be mortified to have us back? There has to be some reward that is worth this... I've installed phpBB 3 systems. I don't see what it does that is so cool that we HAVE to have it in that form. Any cool parts could be developed for 2.x.

The question is wide open to all, not just Team members or other devs. As a community, what does phpBB 3 do that 2 doesn't?

- Keith

Posted: Thu Dec 02, 2010 2:11 pm

User permissions has always been a PITA. NSN Groups was the closest thing anyone ever did to handle extended permissions but it had to work within the constraint that it was originally developed as an 'add-on' for *nuke because there was no way to get it integrated in the core code from php-nuke.org

In an ideal world, I would dispense with the '_authors' table completely and use a 'role and group' system whereby each user is allocated a specific number indicative of his role e.g.;
0 = anonymous
1 = user
2 = moderator
3 = admin
4 = admin defined role
5 = admin defined role etc
You can then give each 'role' specific permissions based on what they can access and what they can do (edit/delete privs etc).

This would also make it much easier to integrate third party apps like phpBB because it would be much simpler to 'bridge'.

Posted: Thu Dec 02, 2010 2:55 pm

Guardian2003 wrote:

This would also make it much easier to integrate third party apps like phpBB because it would be much simpler to 'bridge'.

Guess I need the working definition of 'bridge' here, as using the term along with 'integrate' in the same sentence confuses me.

Whenever I see the term bridge, I usually think along the lines of a 'shared' or passed over login, and really not much else. The bridge-er has its own set of attributes for the user, and the bridge-ee has its own set.

Integration then, to me at least, is the sharing of these attributes (which would include permissions).

So, if bridging, as it relates to a new RN direction, includes more than just passing a username over (realistically only preventing the user from needing to login twice), then what else would it include?

- Keith

Posted: Thu Dec 02, 2010 3:05 pm

btw, really appreciate you folks being patient with me, as it's quite apparent this path has been gone down before. For me, however, I have some completed projects (mods), and quite a few more on my 'wish list'. Whether or not I go into those projects depends a lot on how this information pans out. I hate wasting time writing code the wrong direction.

When I write for myself, or a client, it's a MUCH different direction than I would take if it's for a 'public' release. There's a LOT less error-checking, stuff embedded in the files rather than embedding them in the ACP, etc etc.. authoring for the public involves exponentially more dummy-proofing.

If the direction of this CMS is going south away from phpBB 2.x, then many of my mods probably don't need to be authored for public consumption. I have a strong embrace of phpBB 2.x, and almost everything I write uses their engine, because it prevents the need to re-invent the wheel. As is the case with Groups, I would not have the time right now to sit and re-write an entire 'enhanced' permissions module, so that's out. I have already branched it out, and I'll post some examples in a bit... but it's of course using even more phpBB integration, not less. Not sure I should work further at it if there's no point in releasing it.

- Keith

Posted: Thu Dec 02, 2010 3:14 pm

I can't comment on PHPBB2 versus 3 since I have no experience with 3. I do know that over the past few years we've had a lot of requests to move to 3 here. I also know that PHP moves on, MYSQL moves on and functions that were perfectly acceptable a few years are deprecated now and will be eliminated in the future. PHPBB2 will not work forever.

Quote:

I don't see why a separate RN team isn't put together that ONLY deals with Forums, Private Messaging and other inter-site communications, while the original team continues development of the CMS portion.

I can think of two reasons. First, there aren't a lot, there may not be any, qualified programmers to assign to this. It is hard enough to keep the core team going -- everyone pretty much has a full time job in addition to trying to squeeze in RN work when they can. Second, there are good forum solutions out there already -- including PHPBB3. Why duplicate those efforts -- especially in the light of the resource constraints we have. There is plenty to do on core without taking on a Forum too. The path Palbin and others have defined for revised filtering in the next Major version of RN is going to take a LOT of programming to fully implement.

Now as to nsngroups. What Guardian says makes perfect sense. Let's go a little further. In my view, to make groups work properly and adequately as a basis for permissions we need to modify the database structure somewhat. First off we need to enable having groups within groups recursively with inherited privileges (or permissions). There might be better database approaches but one way would be to add a summary or entry level field to the nsngr_groups table. Only entry level groups would have users directly belonging to them, summary groups would own entry groups. The nsngr_groups_users table would have to be modified to add a field -- call it e_gid for entry group id. As I say summary groups would not have uid's associated directly -- you would look up entry groups that belong to them and then look up uid's that belong to that entry group (probably help if you look at phpmyadmin while reading this to visualize it). There could be any number of levels of groups.

Privileges or permissions would be assigned to groups. Probably the best way to do this would be to have a groups_permissions table. In that, you'd have gid and permission_id. You'd probably want a permissions table too where the permissions themselves are defined in "readable" terms. Perhaps a permission_id, a short name (for referencing in programs) and a longer name that more fully defines what the permissions are used for.

Just like we have the is_user and is_admin functions in mainfile, we'd add a get_permissions function too. We'd look up all groups that a user belongs to and create an array of his permissions, then reference that throughout the new system.
By executing that on every page load we'd automatically know what permissions a user has. The modules could then test for the existence of appropriate permissions to carry out functions.

This approach would vastly simplify groups maintenance. Instead of having a comma delimited list of admins (who had to have been previously added to the authors table and who have to remember to sign on administratively every time they come on the system) we'd simply create groups for each module that we wanted to assign users to have administrative privileges for. The maintenance screen would let you assign users to groups or groups to groups and let you see what the results would be in terms of what users belong to what entry and summary groups.

... and I have to say, this groups, permissions model is not new. Unix, if I am not mistaken, has something like it, Netware does, even MS Windows. In all likelihood we could find something functioning to model our approach after and maybe even some cool Javascript code to handle the user interface.

Posted: Thu Dec 02, 2010 3:36 pm

Well, the logic -and- code to PHP permissions is all over google... it's not a problem developing the system, and there's excellent starter (or framing) code available, even some good examples in OOP. The problem is integrating and managing it. The reason I brought up the phpBB Groups is because it's already there in construction and management. Implementation would be relatively easy at that point.

You're talking about everyone with jobs, families, etc. You speaka my lingo Wink

My whole point from the OP to this post is, make life easier by re-using what is already there.

What part of phpBB 2.x code is deprecated? I have it running on a PHP 5.3.3 system, which means it should run on PHP 6 without any fatal errors (although it might require a few more modifications as we get to 6.0). I just do not believe 2.x code is about to go belly up and stop running anytime soon. In fact, it was so well written, I believe any good programmer should be able to patch it indefinitely. The only scary thing about the code that I will subscribe to is that 'unknown' script attack in the future.

- Keith

Posted: Thu Dec 02, 2010 4:06 pm

The PHPBB2 versus 3 versus leaving it up to the admin to load his/her choice is beyond my pay grade. Raven and/or Palbin would have to address our direction on that. I can only say that it has received a lot of attention over the last couple of years and we have been moving steadily towards reducing dependencies between RN and PHPBB. Perhaps you are right that PHPBB2 would continue to run indefinitely. But once we start hacking the code to make changes, we own it and we take responsibility to keep it running. Personally, I don't think that's a wise thing to do.

If there is code in PHPBB (either 2 or 3) that we can use to manage groups in RN, then yeah go for it and use it as the basis for moving forward. I was just googling things like "groups permissions" and "groups permissions joomla" and "groups permissions drupal". Spend a half hour reading, we are not alone in this and no we don't want to reinvent the wheel.

Posted: Thu Dec 02, 2010 5:09 pm

good lord... lost a whole typed out reply... gah...

Posted: Fri Dec 03, 2010 7:19 pm

At any rate, said I would provide an example... so it's now posted on my webpage.

Further discussion can be had there, if you're bored of it over here, or we can continue here. Assuming there's anything else to discuss from the Team's standpoint. Wink

Code:

www.ezcommunities.com

- Keith

registered · Posted: Sat Dec 04, 2010 11:15 am

All that I have to add is that groups/roles and permissions are like you said, should be absolutely integral to the CMS, meaning CORE capability with a clear API. The API should be flexible enough to "plug-in" with third-party software such as what was discussed here with phpBB3. That is the "bridge" concept I believe. This is all possible with the right API. Problem is having enough collective experience to write that with the flexibility it needs.

Regardless, it needs to be core, not some add-on module. While I agree that the maintenance of groups/roles and permissions would be a separate module, it should be using the same underlying core API to manage and use these groups/roles and permissions. Wink

Edited by author: for numerous grammatical errors. Ouch.