Forum OpenACS Development: Response to new bboard package

Ben, I've implemented most of what you are talked about in your original thread.

Functionality We need at least similar functionality to what we had in v3 (sadly, some of it was lost in v4). This includes:

1. bboard forums either Q&A or threaded (and certainly a simple architecture for other presentation styles)
2. categorization of postings (optional system-wide, and optional per forum)
3. ability to restrict posting of new questions
4. ability to moderate
5. ability to manage existing threads (mostly for deapproving/ deleting threads).
6. emailing a post to a friend (nice new feature of v4) editing your posts... although this should be optional per forum, as this is a hotly contested feature since it changes the historical trail of a thread.
7. incoming email submissions to bboard... another hotly contested feature, but certainly let's implement it as an optional thing.

1. I implemented a flat (UBB/Vbulletin) style bboard and threaded bboard. The data is always stored using the OpenACS 4 sortkeys. If you are in a threaded view, you can respond to sub-threads at any point and the system will know how to organize your threads. If you are in a flat view, you will automatically respond to the first message in that thread, though I also have a way for you to respond to any message in the thread. The user can switch between flat and threaded views at any time by clicking on a link.
2. I have a site wide categorization system for the modules I created for my client. It seems to work ok. You can create a hierarchial categorization system. For the forums, we only use the top level categories, but there is no reason why we can't use sub categories. All forums tied to the same category will be grouped together in the forum index page. I also have a mechanism for the administrators to reorder the sorting of the groups. For our news and articles sections, we allow the authors to choose the full category hierarchy. The plan is to allow users to be able to filter out content at any level of the hierarchy. Selecting a top level category will select all items in the sub-categories.
3. We have a "Close Thread" option which we've used a few times already. It prevents people from posting to that thread. We also have private forums, which are hidden from users who are not members of that forum. Private forum messages also do not show up in the searches unless you have read permissions on that forum :)
4. You can assign moderators to each forum and they can only control forums which they are moderators. Closing, editing and deleting threads is the main role of the moderator.
5. Not implemented.
6. We allow editing of posts. I have a trigger which automatically captures changes to the message and records it in an audit table. I haven't implemented the posting history yet, but that's on the list of things to do. I want to let moderators and other users have the ability to see changes made. After editing a post, the system reports the date when you edited it and who edited it. This is useful when moderators edit a users post.
7. Not implemented but would be very useful!

Under The Hood The biggest problem with the current v4 of bboard is the underlying architecture. We're proposing a far simpler, leaner, meaner architecture:

1. forums are objects scoped to packages
2. bboard postings are *not* objects, they're *not* CR items, they're *not* versioned. Thus, they're not permissioned individually, nor should they be. Only forums are permissioned.
3. use of sortkeys for message hierarchy

I'll stop there and see what people think :) I'll post more details as we spec them out, but these are the major lines of development. Nothing revolutionary except for the lean, mean, underlying bboard engine machine.

1. We still do this. It's scoped to the forums package.
2. Both forums and messages are objects, but we don't use the CR. We grant permissions on the forums, not on the messages.
3. Yup, did that :)

My take on editing is that it should be allowed, but you should keep a history of the edits. Any site that runs vBulletin will allow users to edit and DELETE messages. I am against users being able to delete messages, because you could lose good discussions that way. I wish my client's site was online so that you guys can see our sandbox site and play around with the admin functions, but the ISP they are using (friend of the client who runs that datacenter) is flaky. I am willing to send to send the code to you if you guys want to poke around it. I plan on releasing it in the next month or so (not sure if I want to do GPL or BSD). Be aware that it will have minimal documentation and some parts are not yet "clean". :)