There are several things going on with the forum module although development has been solely focused on wrestling any bugs exposed in the 3.20.05 -> 3.20.08 releases. These releases came out fairly rapidly for any of the subprojects producing 4 releases in 2 months. I am now debating what major item should be overhauled next and wanted some community feedback on what you think is most important. I first want to add that the next version is already set in my mind and will not involve any of these enhancement ideas. It will be another on exposing work I have already done and fixing any outstanding bugs above a level I call "Yellow" or elevated.(Insert joke about US Terror Alert System) 

Before we begin, allow me a moment to explain what is slated for the next release.

• I will be exposing the Private Messaging Feature
• Making better use of Client API
• Fixing any bugs I consider "Orange" or higher.
• Depending on the html provider for images and smiles.
• Enhancing Search Sytem of module.

Enhance Module Permissions

Current Status

The module permissions now have simply Edit and View permissions on it. When a user is using DotNetNuke but is new to the forums module, they expect the module to behave a certain way based on expectations made using DotNetNuke modules. It is very uncommon for any module to allow the majority of users (people in the registered users role) have edit permissions on a module. This is the number one support question received here on the forums and in blog postings.

What Are We Going to Change?

This entails using the core Permissions table to store the permissions for using the module. This allows users to use the current module settings to set permissions on the module because the module itself has several various levels of access beyond Edit and View. The way this works is it shows the checkboxes in module settings with new columns each representing a new permission set like Forum Admin, Global Moderator things like this which you would likely want to use the core's role grouping for. The current setup requires giving all users you want to be able to post somewhere in the module edit rights to the module.

Time to Implement: 2 months

Reasons For Wanting This Enhancement

The current setup is not the typical way other DotNetNuke modules function. Although the forum is much more complex than other core modules in terms of permission requirements (having several various levels beyond edit and view), this is not very intuitive to the end user.

Coding against this is very easy for developers. It just makes more sense and requires less code. Another thing is, this is already loaded into the module settings so you do not have to make another call to retrieve it AND the caching of it is handled for you.

I think this enhancement would also open the door to re-writing other role based aspects of this module. What I mean is here is that we should also use a permission grid set at the forum level. I would do this at the same time as above as I know the above would only three good days of work which includes testing.I hate those popups there now and I am planning on implementing the clientapi user lookup control which 'looks up users as you type' in an ajax fashion. (For selecting individual forum moderators) This helps increase usability in safari and firefox.

Email Notification System Enhancement

Current Status

Currently there is lots of things going on when a forum post is posted. Depending on what exactly happened (moderated post, non-moderated, etc) emails fire off. Each time an email is fired off there is two lookups done. One grabs a list of users and returns them as an arraylist. A file on the server is parsed and its contents are loaded into memory. This object in memory is now being parsed and replaced for a series of different things. The object is returned, and along w/ that arraylist, it is passed to a send mail function. This is done one at a time in a For loop until all emails are sent. This also occurs in the same thread of the application and really hinders performance especially for the person who just posted. This also has a current limitation of 100 email addresses per notification, so it won't throw an error.

What Are We Going to Change?

What we need here is a way to queue emails and fire off in a seperate background thread. Because it is in a seperate thread, it will not hinder performance of DotNetNuke at all nor will it result in a performance hit (where they sit and wait for the 100 emails to send out) before they are returned. Running in a background thread would also allow us to remove the 100 email limitation. This will also run as a scheduled task if possible so it can be turned on/off at will. We also want to store the email template in the database for faster access and fewer hits to the file system (slower than hitting db).

Time to Implement: 3 months

Reasons For Wanting This Enhancement

I think this is a no brainer. You remove the email limitation (currently 100) and you increase performance.

Opens the door to reviewing every other aspect about email system of this module to elminate any overlooked items or minor outstanding bugs.

This could eventually make its way into the core where other modules would be able to use it (like a service).

Forum Module Skinning

Current Status

Right now if you want to make a forum theme, there are definately some limitations. For one, it is not very intuitive to designers and considering the module is mostly rendered in code it is hard to make UI changes for most developers and designers. This also leads to confusion for those developing the module. Chaning the current themes now is something I have seen very few do and I know for certain the defaults don't match most site designs.

What Are We Going to Change?

We would make the module work more like skinning. The module would have its own set of tokens which would hopefully be extensible eventually. The admin type pages that already exist as ascx controls will be altered only slightly and there would not be any skin objects or custom theme here. These will look like other core dnn admin modules. The items which are seen by moderators, however, would be skinnable. We will use the current DotNetNuke skinning engine which would allow ascx or html skins. If a file is broken, we will load one of the defaults. (this is what core does too)

Time to Implement: 3.5 months (if I get team help)

Reasons For Wanting This Enhancement

This will allow much more control in a more familiar environment for developers and designers. Designers can place columns, controls wherever they like. The hard part here is documenting everything so designers know how to implement it. Everything here will lead to seeing forum theme become more publicly available too.

This will take lots of complexity out of the code. Many developers see the code which generates the UI and nobody wants to touch it. I also feel at times that building the UI in the code is like re-inventing the wheel. This is also lmiting how flexible the system can be in terms of custom look and feel.

I think coded properly this too can increase performance. In parts only an admin would see, we would be cutting down load time by showing in a more generic manner (no pics and depend on container/skin of site). At the same time, being generic allows the admin controls to blend in with a sites current skin. Avoiding admin skin objects and parsing for them reduces the risk of error.

Well, there are your three choices. Please use this thread for any responses and let me know what you feel is most important and why.

Chris,

I vote for the permission rewrite. I know, that this is the feature with the least effect to usability, but it improves most further developement and in the long term saves most developement capacity for other features.

An eMail Queue would be great when you have lots and lots of users like I do.

I would add some additional thoughts on the eMail Queue requirements: 1) eMail Queue needs to be automatically recoverable upon system crash or incorrectly timed shutdown,

2) need to have an auto page refresh function of Queue (or some other page) to keep the worker process running while eMails are going out -- in this way you can walk away from the computer and have 10,000 eMails go out over night,

3) eMail Queue could be designed such that each entry in the queue represents a batch of eMails sent to be sent to each address as a seperate eMail, and do all of the subsitute and replace of TAGs like name, address and so on.

4) would like to have the ability throttle or limit the number of eMails per minute via a delay or some such? to control bandwidth consumption on a per batch basis with a max-min Queue limits set by host, and

5) can we actually make a version that is a a real windows service instead of a DNN scheduled task for those folks who have dedicated servers -- in this way we don't have to worry about the worker process going down and the eMails not going out (I assum this still a limitation of the DNN Scheduled tasks?).

Also, for me personally, I like the current permissions scheme and it is how forums work! On thing that would be nice to be able to setup roles that you could designate as an admin of the module without having to be in the admin role group. (If this can already be done -- can you tell me how?)

Thanks for your thoughts and good work on the Forum Module.