I went ahead and tried to create a solution to my problem. It didn't return any errors to me from my code, but it wouldn't let me compile because it said it was missing resource files 'Administration.ascx.resx', 'PageRatings.ascx.resx', 'Ratings.ascx.resx'. None of which I used or edited, funnily enough. Also, Administration.ascx.resx is there, in the App_LocalResources folder. I'm looking at it, in fact. Has the 'ActivateCommentsChk.Text' stuff all set and ready to go. I'll try moving it around and see if it'll like it somewhere else.
Anyways, I've never compiled a project quite like this before. I already compiled DNN and added the references needed for the DonNetNuke.dll (Library) and the Microsoft.ApplicationBlocks.Data supplied in the DNN Components. So all of my references are filled. Not sure what I'm missing for it to compile. Apart from those 3 missing reference files. 2 of which I'm quite sure did not come with the source.
However, I figured I'd post my code so that, if someone can compile the wiki, perhaps they can lend me a hand. Or maybe the group might want to add it after tinkering with it a bit. Or have someone tell me that there's something blatantly wrong with what I've written and get it fixed. But overall, I hope someone could help me out with the compiling issue. :)
This is the code I edited in the 01.00.04.SqlDataProvider file. I can't really vouch for the accuracy of these edits, since I modified my tables and my stored procedures manually when I was originally mapping out my thought process. However, I'm pretty certain that my modifications are correct. Obviously, these should be placed anywhere the latest modifications of the same tables and stored procedures. Only edited the Wiki_Topic table, adding the CreatedByID column and GroupName column. The edits to the procs are pretty straight-forward. In the INSERT command, added the CreatedByID and GroupName columns to be filled. We don't need a CreatedByID value to be passed in, since in the Add function, the UpdatedByID carries the same meaning. However, we will need to pass in a GroupName param later on. I also had to change all the Get procs to search for the CreatedByID and GroupName cols, as, from what I've read in the code, that's how the TopicInfo object properties get populated.
This is from the DataProver.vb file. The function names are still the same, so they shouldn't be hard to find. For that reason, I did not add any code that was found before or after it. The ... above and below mean, obviously, that these edits were made in the middle of the file. I am not adding line numbers as modifications in the source would just make them confusing. Anyways, here was just the basic addition of the GroupName String to the Wiki_TopicAdd and Update subs. You don't need the CreatedByID to be sent in, as the Wiki_TopicAdd already has this value via the updatedByUserID value.
Updates in the TopicController class are very similar to the edits in the DataProvider. Just adding the GroupName to be sent in to the Wiki_TopicAdd and Update functions. Again, we don't need to send in CreatedByID, as the Stored Procedure will be getting that from the UpdatedByID value passed in during the Add proc.
TopicInfo had to add the CreatedByID and GroupName properties. Also, had to add their respective variables. I added some previous code to make it easier to locate where it was that I made the edits. This object is the one I am most concerned with. From the code I read, the properties of this object are loaded in the DNN CBO class (FillObject method). I have never seen it done that way before, and from what I understood, the order of the properties in the object being filled is important. If that be accurate, then I believe that the code edits I've made above (and below) are in correct order. However, I'm not familiar with this code and so I cannot say. Again, this is where I'm most concerned the edits will break the wiki.
Edits made to the WikiData are pretty text-parsing-straight-foward. I had to do a bit of repeatitive code just because I thought that it would make the flow of the code a little bit better with the properties in TopicInfo. In WikiText, I made sure that the group info would not be visible in the Cache but still available in the Content. Later on, the ProcessGroupPermission method used a lot of the same code in WikiText to just find and return the last group given permission. I did not add functionality for multiple group permissions. It's either one group, no groups, or all groups. For one group, one would just put in (-groupname-) in the wiki. For no groups, only creator and superusers, the user would plug in an empty or invalid group (-groupthatdne-). And for all groups, just don't add the group syntax in there. I may have made a logic mistake with that because I've been trying to digest all this code quickly for my boss, but I'm relatively certain it's accurate.
SqlDataProvider edits were also pretty straught forward of adding the GroupName parameter to the method's list. Again, the method names are the same, so I did not include 'before' code. It should be pretty easy to find.
In the WikiControlBase, I wasn't really sure how much I needed to edit and whatnot, but I just went ahead and did what I thought felt right with the rest of the code. I added variables for the CreatedByID and GroupName values, but I don't think they were really necessary, as they really aren't edited in this object at all, so keeping a carbon-copy of them is a bit redundant. But I used the variables later on in Router instead of going throgh myPage.Topic.GroupName, etc. Here I did add some prior code a bit to make it easier to find where I made my edits.
Last but certainly not least, Router. Here I added the basic logic as to whether or not a user had permission to edit the page or not. It's a very small If/then statement under the ' Added for group auth comment. I put it outside of the main CanEdit if/else/then clause because I wanted it to be available whether people chose to use DNN settings or not. I'm not sure if that works well with the rest of the code, but I don't see why it wouldn't. So just a quick run-down. First, it only does a check if the user would be allowed to edit the topic under normal circumstances. If they can, then the logic checks if a) the user is a superuser or b) if the topic does not have a groupname restriction. If both of these return false, then the logic checks if the user is in the role specified by GroupName. If they are not, they don't get to edit the page. However, they do get a chance at redemption down the line if they happen to be the user who originally created the topic.