|
Joined: 5/30/2007
Posts: 10
|
|
|
FINISHED!
Ok, so a few forewords. First and foremost, I have not followed any coding standards the dev team have assigned for themselves, mainly because I did not know them. I only made my modifications where I saw they were needed. For that reason, I do not necessarily encourage the installation of this module as it stands. I also don't discourage it because my company is using it (which is why I had to write it :P, and so I can verify that, for the past week at least, it has been working well.
Another reason I discourage the usage of this is because it will conflict with future updates from the Wiki Dev Team. I'm mainly posting this in hopes that the idea will be admitted into the project, and so that those of you interested on how I went about my modifications can understand it.
First, here are the important links:
SOURCE: www.thedivineforums.com/files/Wiki_Source.zip
INSTALL: www.thedivineforums.com/files/Wiki_Install.zip
Now, for the info:
DataProvider.vb
Had to update the override subs and functions to include the GroupName string.
ORIGINAL NEW
Router.ascx.vb
This edit isn't so much necessary for my GroupAuth mod, but a fix. I noticed that when the admin chose to make the wiki have seperate edit settings than the page, no one could actually edit the topic. This fixes that issue. NOTE THAT I CAN NOT BE CERTAIN IF THIS CONFLICTS WITH ACTIVE DIRECTORY AUTHENTICATION! However, as far as database auth goes, this has worked perfectly. The difference is from where you get the user info. Context doesn't seem to wanna play nice. It doesn't load the user's DNN roles.
Start.ascx.vb
This is VERY horrible coding. I should've put this elsewhere, such as making CanEdit a .NET Property and making this check there, but I just left it here because it worked for the time being. The reason it's here, however, and not in Router (where CanEdit is originally set) is because in Router, you can't check the GroupName property. IOW, the TopicInfo object property in WikiControlBase hasn't been initialized yet, and returns an Object Reference Exception. Also, the MyModule property (of type DotNetNuke.Entities.Modules.PortalModuleBase) has also not been loaded, but that's not as important, as Router loads this automatically. Anyways, as a side note, just remember that I do not promote the direct usage of this mod. While I'm certain that it works (my company is using it now), it has not been written to any standards for updates that the Wiki team has set up. Please wait to see if they want to impliment this idea, or else use this at your own discretion. I am, however, available for questions. Anyways, what it does: This is where the page checks if the user is actually in the group specified. If not, link shows only if either (inclusive or) the author of the page or a superuser.
WikiControlBase.vb
It was during this process that I discovered that the Topic object (of type TopicInfo) does not load during Router's PageLoad event. Pretty straight forward of checking for a GroupName and CreatedByID. If null, look in TopicInfo. If not, send the info.
WWWikiDB.vb
TopicInfo Class
Just added the private variables to contain the author's ID and the GroupName.
When the content for the topic is rendered, the GroupName should also be parsed and set.
Added the GroupName and CreatedByID properties to the Topic.
TopicController Class
Changed the Add function to include the GroupName. CreatedByID does not need to be added because it's the same as the original 'Updater'
Again, added GroupName to the end of the update comman.
WikiData Abstract Class
Adds the Group constant, between which one would add the authorized group.
Just added the RenderedGroup property.
Adds the code that will get rid of the (-GroupName-) from the display content.
Added a function that will return the name of the first group in a (-Group-) tag.
01.00.04.SqlDataProvider
Just added some updates down at the very bottom. Updates include modifying the table, editing stored proceedures to get the GroupName and CreatedByID, etc.
|
|
|
|