Network announcements

Jason · Posted: Mar 04, 2008 9:25pm Post subject:

will do

ButtaKnife · none Joined: 26 Apr 2005 Posts: 38

PingBad · Guru Joined: 05 Feb 2005 Posts: 2075 Location: New Zealand

Truth be told, I'm in the process of working on my own CMS/Forum hybrid as I write this. And you're right... dealing with permissions management is a real hoot Wink

katsklaw · Guru Joined: 28 Jun 2004 Posts: 1122

Anarchy · Posted: Mar 07, 2008 7:26am Post subject:

na its cause i smell bad Neutral

he dont want to be in the same channel as me Razz

Jason · Posted: Mar 07, 2008 7:41am Post subject:

I write much more complex systems that handle software development, business logic, and a lot more, for a fortune 500 company in the top 15. Permissions for forums are a pain, but not overly difficult. Usually perms are based on groups. So you have a table that identifies groups, a table that identifies permissions, and a linking table to link perms into groups. Finally, you have a fourth table to map users to groups.

When I first started using SQL, I would have found it to be a nightmare. But when you start dealing with intricate table structures with hundreds of foreign keys over several hundred tables, it becomes one of the easier things to deal with.

I started the forum, and went fairly far with it, but I coded without thinking first, and ultimately there wouldn't be much gain to swap besides the ability to say "I made that!" I would need it to be significantly better to bother going all the way. Especially since I'd need to import all the old forum posts/users, and both searchirc and ircimages rely on the phpbb structure for several things including control panel, and signing in.

PingBad · Guru Joined: 05 Feb 2005 Posts: 2075 Location: New Zealand

I was thinking along the lines of having a groups table where the group leaders and members both go into the form of ([UG]\d) and as a semi-colon delimited list

U denoting a user entry, and G denoting a group entry into the membership of a given group

Jason · Posted: Mar 07, 2008 5:42pm Post subject:

always a bad idea to put anything in a db that has to be parsed before it can be useful

PingBad · Guru Joined: 05 Feb 2005 Posts: 2075 Location: New Zealand

hrm... true, but i'm one for putting unparsed data into a database for 2 reasons:
1 - if the data were to be compromised for any reason, it (depending on how "unparsed" can be defined in the scenario) would be technically useless to the compromiser
2 - if something changes down the track, it'll likely be in one spot (the code) as opposed to all over a database or three

Jobe · Posted: Mar 08, 2008 7:23am Post subject:

At the same time it can also be much harder to add additional information to the unparsed data down the line. All the records with the old info (without the new) wont work as well as the new records (added after the change)

Where as adding an extra field to a table can let the DB engine handle default value for that field and fill all the users value for that with the default.

But with unparsed, you have to write a script to process all the records for you.

Jason · Posted: Mar 08, 2008 10:22am Post subject:

I am of the opinion that if you use a database, you use it for what it's good for. If you want to parse text, use a flat file :)

Some people also like to insert binary data (images) into a database. That doesn't mean it's a good idea.

Jason · Posted: Mar 08, 2008 11:08am Post subject:

ok I put in code that allows the original poster to reply to his own network announcement thread.

I didn't test it (since my account can reply anyway), so someone check it out and let me know if it works.

Jobe · Posted: Mar 08, 2008 12:05pm Post subject:

Well I cant confirm if you can reply to your own thread's as I have none to reply to but I can confirm users cant reply to someone elses thread.

PingBad · Guru Joined: 05 Feb 2005 Posts: 2075 Location: New Zealand

Well, with regards to the groups table I had in mind, it would be the following 5 fields:

GID (auto_increment, int(11), PRI KEY)
group_name (varchar(60), unique)
assoc_rank (int(11), def 0)
group_leaders (text, not null)
group_members (text, null, def null)

And as a sample...

GID = 1
group_name = "VIPs"
assoc_rank = 0
group_leaders = "GM;GA"
group_members = "G3;U15"

PS: GM = global moderators group (leaders is hardcoded as GA), and GA = administrators (leaders is hardcoded to U<value of site_founder config field in another table>). for both groups, group_members would be stored in the configuration table as "admins" and "moderators", allowing only users - altho groups may also be members of either