You're gonna have quite big queries...

You must mean because we are now querying all the forums on the other BBS, yes?
I don't think so.   If I am not mistaken... isn't it true that the only times any forum is queried is "where this user has permissions" to access it in some way?
If true, then it should be no different than, say, adding another native forum. 
(refer to section 7 under idea #3)

In the case of when the admin is setting permissions ...this is easily addressed by simply including a list of other BBS' for the admin to select from if he/she so chooses to go there (as opposed to polling them all whenever entering the permissions section).

Ah... I am tagging the ID's so they are always unique.  And its configured so that any BBS only deals with its native users.
Under "Proposed Requirements" initial list you will note...
"1 function for always pointing users_table calls/references to the native users table"

Take a careful look again at #6 thru #8.

In 8a + 8b I discuss how this should work.
..."parse only group_ids properly encoded to 'thisBBS'".... means as far as any BBS is concerned it is only dealing with its own users, whether in the domestic table or even in cases where they are added into a foreign permissions table (see #6).

I don't (yet) see a flaw in the logic, or maybe it is not explained clearly enough there ...or I am missing something?  If you are spotting something there can you be more specific (so I can study it)?

Good to hear from you.  Thanks for checking in.

Also, this still does not solve the problem with, say, user IDs.
Let's assume there are two users with the same ID, but from different boards (pre1 and pre2). Both have permission to post in pre1_forum with ID 1. And they do. How would you know which user you are referring to?

The 'Short' Plot for the 3rd idea might go something like...

1) - Write code that allows the current bbs to 'see' all other bbs' forums, period (don't even bother with coding for directly filtering forums -->> the code already exists!).

2) - Set permissions for users to read/post forums as usual, ...include ability (write code) for admin to also select forums from all other bbs's.

3) - Then when current user/visitor is online, your bbs lists the forums he/she has permissions to view - just as always...

Since permissions are (already built for) filtering/managing what forums are made available to view, we do not need other code to directly filter/manage display of foreign forums (as most of our discussion has seemed to focus on).

Instead, All we have to do is facilitate the db_function to allow queries to address all forums (in all bbs's), and simply let permissions filter forum/post listings in the normal way.

Post #28 focuses on explaining a proposal for how that might be accomplished using, primarily, a tweak to the config file and to the db_function handler.

Well I hope I didn't unwittingly disrespect anyone by coming out with post #28 up there (not a peep since).

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

Anyway, its going to be a bit of time before I can work on this, so I would appreciate it if this thread is not closed ...I will be back when I get going on this project.

Meantime, if anyone has a notion to glance through post #28 (Idea #3) and let me know if you spot any glaring problem in that logic, I would greatly appreciate it.  Short of any major 'bombs' I think it is the one makes best sense for a tryout.

Thank you to you folks who have dropped in and offered comments and help churn up ideas. 
Cheers,

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

• If it helps, at some point maybe we add 1 simple table that is universally accessed by all installed BBS's ...that is used for storing the BBS member's collection prefix_id's.  This table has/needs no prefix (I think).

• So after we have added a prefix at any BBS config file, at any BBS there is a function that runs that
- checks its own config file prefix list against this shared table
- if the value is not in there, it gets added
- the table assigns an auto-incrementing unique id value to the new prefix
...that can then be used by any new function we write for managing foreign table access or whatever.

What for...
Importantly, rather than having to create and track encoded group_ids on the fly, we can use this id to create unique integers for foreign storage of our native group_ids.

So for instance,
- the new table assigns prefix_id values starting at 1,000,000.  The auto-increment step is set to 1,000,000 as well.
- when a group_id encoding function runs, it performs a table lookup for its own prefix_id
- an addition is performed between the prefix_id and the current (native) group_id being handled
- the result is the new group_id that gets stored for 'thisBBS' in a foreign 'thatBBS' table.

Now all the various BBS' group_id's should be safely and uniquely stored in an automated fashion at any BBS.

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?

Keep us updated on your progress. This multi-database query stuff is something I've been planning to get around to for quite awhile now, (due to the shonky cross database method which exists for PgSQL), but never actually done so yet due to always getting sidetracked.

Actually, I have been working up logic for scenarios based on your method both without and with the table you mention, its just that I don't think you had mentioned creating a table before, ...but I am pretty sure I am following you.

Actually, I am having a major brainwave (heads-up)... but I am waiting to see what further comments, questions, and criticism may follow first (before I presume to shift gears).

I am very grateful for all the feedback and ideas that are being offered here (you, r2, + lie2... ) -- each thing has been very compelling.  Nothing's been wasted on this end.  I hope the final result will reflect that.

Cheers,

In it's simplest form, (explanation wise), you create a forum on both BBS's. One will contain all of the content, the other will just be a placeholder as such. However, the fact that you have two physical forums allows the use of the permissions table locally on both BBS's, so you have granular control of whom can access from where. When you connect to the forum on the local machine, (when editing, posting, viewing etc.), it's connecting to the remote DB for the content of that forum, but checking the local permissions tables for the local placeholder forum which was created.

Nontheless, there still is the problems with users etc. Since users from both installs can post in that particular forum, you would have to use both forum tables in that query.

In my second idea there is only ever one -native- forum table that is used, so normal native permissons may be applied without issue.

Matt's method appears to always reference the foreign table directly, so it is also dealing with "only one table", but because no unique records are being setup locally for the foreign forum there is no natural way (I have yet figured) to set native permissions for that. (a little more clarity appears below)

And if you meant BBS tables, I think I addressed this in the last post.

Matt's ideas have been critically inspiring for me (thank you, Matt!).
I think Matt's suggestion implies you do not need to edit or add any tables.  No column is added in the native forum table, and that no, the admin doesn't mark or choose foreign forums, you/me the coder set this manually in the config file.

------------------------------------------------------------
I am currently walking down some relevant scenario(s) using Matt's base ideas...
I think it best to wait on posting those, but it may do well to mention a couple things for clarity...

1) This line of reasoning appears to take off from my original [first post] suggestion, and requires that we first enter foreign BBS prefixes and forum_ids into the/a config file. 
-- the admin doesn't have to choose foreign forums through an interface, they will simply and selectively be made available through Matt's "require", and
-- no forum table entries are made,
-- no special column for said "alt" flag is created because alt is set when running the code on any given page.

2) Upon view/post/edit/etc_xx.php page load, Matt's "require" pulls the foreign forums referencing in.

3) A wrapper function is setup to facilitate running queries with the foreign prefix + forums references (so queries run first natively, and then run wrapped).  This could probably be done without wrapping each code instance, but implementing it somehow globally (say, at the db class).

This is how I am understanding and working on Matt's ideas.
I have worked up two or three (logical) method scenarios, and they look very compellingly simple and elegant, but I am wrestling slightly with permissions issues with this method.   
However, there may be a method thats somewhat a cross between Matt's idea and my (the second) idea that can tame this issue, while also removing the need for the database hacks proposed in my 2nd idea ;^)

I want to keep this short for now, so there you go. If still relevant, I will share these 2 method workups later in the conversaton.

Nope. Think about it... when users at 'thisBBS' are accessing a forum, permissions management has nothing to do with anyone at any other BBS. Same thing applies over at 'thatBBS'.
The BBS doesn't care about managing foreign permissions. (see next)

Described in 3rd Section --> "NEW IDEA" / 'Details'  / at #1. "Create a Method for the Admin to choose..." foreign forums with a checkbox.

To Re-Summarize My/The 2nd idea (skippable):
- In 3.1: in config.php any foriegn BBS prefix identifier-labels are manually assigned into a new array variable. Those get 'parsed' into a new table where they are given numeric labels.  Those will later be pulled for use.
- In 3.2: Admin_forums.php plugin pulls in full foreignBBS forums into a list (based on new table data from 3.1) The admin is provided selecting via checkboxes.
- That foreign forum list has all the needed identification info including a numeric value that identifies a foreign BBS (in place of its prefix name ;^), and then also each foreign forum id number.
- When a foreign forum is selected, a query runs and the forums_table update runs in the usual way creating a 'f_id'...,
- A new function takes and tweaks that auto-assigned value into the new/unique 'identifier code' **using the foreign prefix + f_id numbers obtained above, and replaces the auto-generated f_id.

Lastly, since the forums are now included in the natural way (in the native forums table), permissions assignment can be handled normally.
- admin logs into 'thatBBS', creates a forum, sets permissions for her users there, etc...
- admin logs into 'thisBBS', picks a 'thatBBS forum, sets permissions as usual for her users here.

The BBS will only ever use its native prefix.  Non-natives are always handled via an identifier-code.  So when viewing and posting, the added db query function discovers and then parses any foreign identifier codes in order to query the correct tables.

Hmmm... yeah, you are right.  However, I was reading somewhere that sql will allow decimals to be placed into the Integer value structured records, ...I have to sort out if thats true.
That made me think, hey, the table always auto-updates one full ineger value, but we can change any value to a unique code by adding a fractional-decimal number.  In this way there could always be full id-separation between foreign and native ...and right there within the native forum table.

If that won't work, then I think I would have to either...
1) create a new foreign forums table... but that would then change the method and require editing lots of queries,
OR
2) insert those new identifier numbers as integers either starting at some ridiculously high level (say 1,000,000,000), or using negative values,  might do just as well.

...I am still pondering a couple other points you brought up...
Really appreciate these ideas and this feedback.