It would be great if a user could be part of multiple groups. For example, you could have a regular user and a moderator - but both are picked to test something on a private subforum. You don't want to revoke the moderator's permissions elsewhere, but you can't give them to the regular user. It would be nice if we could have more than one group assigned to a single user.

Unfortunately, this would require significant changes to the database structure and making the software significantly more complicated (thereby increasing the complexity and decreasing the performance).

Currently, the query to retrieve user/group information is very simple (source):

$result = $db->query('SELECT u.*,g.* FROM `futurebb_users` AS u LEFT JOIN `futurebb_user_groups` AS g ON g.g_id=u.group_id WHERE u.id=' . $id)

However, that only works because the "group_id" field for each user is a single number. Making it work as multiple numbers would mean I need to split that up into multiple queries and increase the complexity of the software. Also, the current structure of forum permissions only works if a the user is in a single group.

Finally, this would result in conflicts with the various elements in each group, such as which title to use, which groups are visible on the user list, how promotion works, among other things.

That being said, unfeatures are actually a very important thing to have in a piece of software. It is important to mention what is not included as well as what is included. Everything is a trade-off between complexity and usability, and in this specific case I don't think this would provide more benefit than the significant overhauls it would require.

Jacob G.
Executive director and co-head developer

Have it work like MediaWiki. MW can have you be in multiple groups.

MediaWiki is much more complicated, though. One of the design principles of FutureBB is to be as lightweight as possible, and as I explained above, adding this would make it much more complicated. Also, there are some things that can't just be overlapped, such as the user title, post flood settings, promotion settings, and the visible groups on the user list.

Jacob G.
Executive director and co-head developer

Is this something that could be implimented by an extension? Something like:
if(in_array(SECRET_USER_LIST,$user->id))
{
$futurebb->forums['secret_forum_about_nuclear_war']->accessible=true;
}
else
{
$futurebb->forums['secret_forum_about_nuclear_war']->accessible=false;
}

Or more compactly:
$futurebb->forums['secret_forum_about_nuclear_war']->accessible=in_array(SECRET_USER_LIST,$user->id);

(Yes, arrays can be constants - php.net/define section "tags")

That could be implemented as an extension, but it can't be included in the core because of the way forum permissions work. FutureBB actually for the most part doesn't use an object model, but instead uses a variable-driven and procedure-based model. The way that forum permissions are stored in the database is like this:

That means that the groups with id numbers 1, 2, 3, and 4 can see the forum. This means that selecting the forums that a user can view is very easy (just find one where that field has "-<GROUP ID>-" in it). However, allowing users to be in multiple groups would require a much more complex system.

Jacob G.
Executive director and co-head developer

Then maybe there sh/c ould be a "full" and "light" version.

I HAVE THE SOLUTION! All you need to do is make a "Forum Tester" group and a "Forum Tester and Mods" group and use them respectively.

That would require having two branches of the software, though. It's already difficult just maintaining and supporting one branch with all the updates and stuff, it would be much more difficult to support two branches that are very similar.

Jacob G.
Executive director and co-head developer

Just make the "light" version be something as simple as "delete this folder"

This is a lot more complicated than you seem to think, especially when there is a whole separate database layer involved. It's simply not possible to do something like that without making the software grossly inefficient by having unnecessary files and potentially unused database structure. Instead, the paradigm we are using is having a relatively simple core with additional functionality added by extensions, and it is theoretically possible to develop such an extension, though it would involve making significant software changes.

Jacob G.
Executive director and co-head developer

Your scratch confirm account mod had both of those things (as it did not use the biography, resume, etc)

Yes, but I know how that is going to scale. FutureBB needs to be designed to scale basically infinitely, and as it scales, that becomes more and more important. I also don't know the resources people will have available, and I want to maximize them. I have a rough idea of what is on the Scratch Wiki server.

Jacob G.
Executive director and co-head developer

How? You don't have ftp access to the scratch wiki server.

I never said I know exactly what is available or have direct access to it, but I still have a ballpark estimate of the resources of the Scratch Wiki server when compared to the amount of users requesting accounts.

Jacob G.
Executive director and co-head developer

How does having the ability to confirm accounts let you know the limits of the server?

Given our small userbase and the performance of the server, combined with the fact that we've never received any complaints about using too much space or having been asked to conserve space, I know that space is not currently a limiting factor on the Wiki and is probably in abundance (at least for now).

Jacob G.
Executive director and co-head developer

Well, that's probably because it's on the same server as on a website with over ten million zip files that can be 50MB big.

Back on topic, I think just making 2 more FutureBB user groups will work.