Create / Share a Topic in More Than One prefixed-Forum (Page 2 of 2)

All Righty Then... ready for this?...
------------------------------------------------------------
**NEW IDEA #3 ***    ..... (BETTER????)

Okay, now wait a minute..., maybe we're making this more difficult than it really is.
The only time a forum is listed or accessed on any page is when a user has permission to interact with it (read/post/whatever) - right?
So instead of having the admin ever select a foreign forum(s), or worrying about managing/controlling listing of forums at all....
...why couldn't we do it strictly via managing permissions?

***Just give the admin ability to assign forum permissions for a resident group within any one ('this')BBS ...to any other ('that')BBS throughout the collective?

PROPOSED REQUIREMENTS:
1 edit in config.php that changes prefix var to an array, and give it more prefixes,
1 db_class adjustment for handling prefixes from the variable array,
1 plugin for admin_forums.php to provide utility for setting native group permissions to foreign forums
1 function for encoding native group_ids for foreign storage
1 function for decoding native group_ids retrieved from foreign storage
1 function for always pointing users_table calls/references to the native users table

WHAT IT LOOKS LIKE:
1) edit config.php file $prefix to be an array value, and add your other BBS's prefixes to it
2) edit the db class to handle the prefix array value accordingly (so now all queries will run fully on native and listed foreign BBS's),
3) create a plugin for admin_forums.php to pull in and list foreign forums (per the config file prefixes entered),
4) when admin clicks 'edit' for setting group permissions for a foreign forum, we have the usual list of native users in 'thisBBS' come up.

Now isn't it here where the crucial part comes in?...
5) When permission is assigned for a group, say to Read, the 1/0 value gets stored in the forum_perms table where the associated forum_id is referenced.
***In this case we would naturally be addressing the foreign 'thatBBS's forum_perms table and not the native one because we selected a foreign forum for assigning permissions.***
-------------------------
Now, we cannot enter our native group_ids because there could be a conflict....
===========================
So, we need to make sure our group_ids from here at 'thisBBS' have unique number assignments to those in 'thatBBS' table where they will get stored.

Following then from #5, What if we simply...
6) When clicking submit (to assign the permissions), everything is entered into the foreign forum_perms table as usual,
....except we augment/encode our *group_id that is being sent* in a way that makes it unique to 'thatBBS's native table (similar to the logic in my last [the 2nd] idea).

For now I am going to limit this to two BBS's, and so in this case when our group_id is entered into the foreign forum_perms table we are going to have the code augment our native group_id to, say, a negative number.  So if our native group_id is 22, then the one entered 'over there' is -22.
===========================
7) So now, when visiting any pages at 'thisBBS', ...when the code gets to running query actions for the foreign BBS it will be addressing only those foreign tables,
...and its going to check access/availability to any of those forums based on permissions lookup in the foreign BBS's forum_perms table...
...so we need to let our query know to parse only group_ids properly encoded to 'thisBBS' (where we are querying from)....

8a) So We use a single function wrapper for identifying and then parsing all our 'thisBBS' group_id values present in the foreign forum_perms table ...for use in our foreign queries, (i.e., we correct gid/g_id variable references so they function "just like normal" without having to edit any queries directly).

8b) We are going to need another function for always pointing any users_table references to only the native users_table, and never the foreign one.

THAT SHOULD DO IT.
Well quite possibly anyway. 
*Probably have to build a/some shunt(s) so we don't interact with the foreign tables for things like adding users, etc... don't know, I haven't dug that deep yet.  May be as easy as not applying it in certain places...
BUT If its true that controlling users and groups references are the key to all things (tables) in the BBS, then it seems a method based in this logic should provide an elegant solution. 
==================================================================
***If this logic is sound, then it would seem that any query would run as normally as it ever would, even handling our permissions for accessing a foreign forum by obtaining the permission info right from within the foreign table;

...i.e.:  no code needed for cross table special case management mumbo-jumbo (i.e., no editing queries), no fiddling with forum_ids, no added tables, no edited table structures...
We use just about everything just as it is ...all is accomplished by essentially and simply storing our group_ids in an encoded fashion in the foreign group_id table, and allowing our db class to simply address all BBS's in a very natural fashion.

DID I MISS ANYTHING?
WOULDN'T THIS WORK?
WHAT DO YOU THINK ABOUT THIS IDEA/METHOD FOR TACKLING THIS PROBLEM?

Last edited by twohawks (2009-07-08 18:54:53)

C'mon folks... new idea #3 (post 28 above).
Its not all that long... and its comprehensive.

Is that the better way to go?.., or did I grossly overlook something (in the logic)?

Not at all. I personally just haven't mentioned anything further because I've completely lost the plot now.