Sitekit Forums

Hi Andy,

I can get you a partial answer for now, the features are as follows and are in the context sensitive help.

• Pin - this keeps a particular discussion at the top of the initial table view, if there are multiple pins then they are ordered by their most recent updated one.
• Lock - this prevents any users adding additional comments to a post.
• Manage - opens a thread in admin and allows you to see and edit it's comments.
• Edit - allows you to edit the comments or the main forum post
• Delete - self evident, but deleting the initial post also deletes the comments
• Sink - Tricky to explain. Basically the initial forum table will always be ordered by the most recent post with the post that was most recently responded to (commented) at the top (pinned posts excepted). This can be annoying if a contentious post attracts a lot of ongoing comments that add nothing to the discussion but keep the post 'elevated'. Clicking on sink means that subsequent comments on that post do not change its order on the page and so as new posts are naturally added to the forum the post will gradually 'sink' off the bottom of the table.

On your structural point, yes we did that deliberately it seemed to reflect the way that a lot of modern forums operate and while I'll freely admit it makes it easier to build I'd argue it also makes its easier to manage for an end user. The simpler structure will also be handy when we add the ability to edit forum posts.

Polling buttons are more complex, we were going to put a simple implementation in for 10.1 but then looking at it we realised there's a lot of subtle variants from voting up and voting down, where a count can be incremented both way, or only positive votes or star rating where the voting is restricted to a fixed range or 'stars'. There also the 'like' and 'not like' approach also. Basically we were short of time and couldn't fit it in and we're still trying to think what should go in 10.2 so I'm open to your input here. The other complexity with voting is that each vote needs tied to a user to prevent duplicate voting so we need a data structure for that and voter need to log in to vote. That said at the moment you can create a voting system with a custom integer field on a post and some script to count up votes added to that field by front end posters, you can also use a guid per user or set a local cookie to do some rudimentary duplicate post prevention, I don't have any examples though.