Create / Share a Topic in More Than One prefixed-Forum

twohawks · 2009-07-08 04:32:40

HA! - - That was a "good okay", my man! Just soaking it in.

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,

MattF · 2009-07-08 09:27:25

I may well have forgotten to mention that bit earlier. What's in the mind and what actually ends up being typed sometimes bear little resemblance.

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.

twohawks · 2009-07-08 18:01:14

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)

twohawks · 2009-07-08 18:53:43

ADDENDUM to IDEA #3
Assigning prefixes unique id's for use in some of the new functions.

• 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.

twohawks · 2009-07-10 19:03:21

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)?

twohawks · 2009-07-18 02:00:12

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

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,

MattF · 2009-07-18 03:09:25

twohawks wrote:

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.

twohawks · 2009-07-18 04:48:11

Thanks Matt.

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.

Franz · 2009-07-19 12:24:37

You're gonna have quite big queries...

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?

twohawks · 2009-07-21 22:39:42

lie2815 wrote:

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).

lie2815 wrote:

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?

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.

Last edited by twohawks (2009-07-21 22:41:56)

Forums

#26 2009-07-08 04:32:40

Re: Create / Share a Topic in More Than One prefixed-Forum

#27 2009-07-08 09:27:25

Re: Create / Share a Topic in More Than One prefixed-Forum

#28 2009-07-08 18:01:14

Re: Create / Share a Topic in More Than One prefixed-Forum

#29 2009-07-08 18:53:43

Re: Create / Share a Topic in More Than One prefixed-Forum

#30 2009-07-10 19:03:21

Re: Create / Share a Topic in More Than One prefixed-Forum

#31 2009-07-18 02:00:12

Re: Create / Share a Topic in More Than One prefixed-Forum

#32 2009-07-18 03:09:25

Re: Create / Share a Topic in More Than One prefixed-Forum

#33 2009-07-18 04:48:11

Re: Create / Share a Topic in More Than One prefixed-Forum

#34 2009-07-19 12:24:37

Re: Create / Share a Topic in More Than One prefixed-Forum

#35 2009-07-21 22:39:42

Re: Create / Share a Topic in More Than One prefixed-Forum

Board footer