With 4.5 came the ability to add User Level access to pages.

Is it likely that this is going to expand so that we have User Level Deny Access ability to Tabs and Modules?

Or do I, saddly, have to try to hack job it out myself? Which will bring tears of infinite sadness. :P

I can understand that kinda plan on it. Though I was thinking that with the addition of the User level access; that it could be expanded so that setting deny settings at the user level would be possible.

For the project I'm currently working on, this is something I really need. I have groups that have access to 10 or 20 pages diferently than others, and occasionally 1 person in that group needs to not have access to 1 or 2 pages the rest don't. The deny ability is the simplest way to make it all nice and happy for everyone. I am enabling my own module level 'access' system, for my modules, which will block limit how much, if any is viewable, but it doesn't change if the page is viewable or not. And I'd rather not even let someone see that a control exists if I'm not going to give them access to it. I get a lot of questions about why they see but can't touch when that happens.

I haven't gone through the DNN code extensively yet, as I've lacked any need to do so. I'm pretty sure I could hack something into place that would do this for me, but it wouldn't be up to the quality, or fit in with the rest of the DNN code base. This isn't something I'm keen on doing, as I'd rather focus on my site, and with personal core changes, the site wouldn't be upgradeable, and the quality wouldn't likely be core-importable, since I'm not familiar with the code and styles.

If someone else has come up with a solution to this, elegant or not, that doesn't require core hacks, I'd be eager to hear it to see if it can fit my needs.

Just my thoughts. I will be looking into if I can add the Deny myself. I just don't think I know the core well enough (at all?) to do it cleanly.

VICTORY!
Actually this is the 2nd time I thought I achived victory, except this time things appear to work like they should.

I claim to have made it possible to apply a DENY role to individual users for TABS. (not modules yet, sorry). Technically it could be made to work with Roles on tabs... but... what's the point of that? Just remove view.

First - I'M NOT RESPONSIBLE FOR BROKENS RESULTING FROM USING THESE CHANGES!
!!!THIS IS A HACK JOB!!!
I did this on a test machine, using a FRESH Install of DNN 4.6.2 and a new Database. It is done merely as a proof of concept right now. I do plan to use it in a website in the future.
I do not know exactly how or if this will affect anything but the visibility of the tabs. I have tested this with 2 users (not including host and admin) and 1 top level tab and 1 tab under that. (at the time of writing) It appeared to be working correctly.
It is possible to use this to prevent ADMINISTRATORS from accessing the page. I have added code to continue to allow UserID 1 to access the page regardless but it can be modified to prevent even HOST from accessing the page.

CHANGES
There are 2 code modifications, 1 resource change and 1 row added to the database.

DATABASE CHANGE
A row needs to be added to the Permission table. Where # is the auto-generated ID
"#    SYSTEM_TAB    -1    DENY    Deny Tab"
When I added the row, # equaled 7. But any number that appears there (if you've added rows to that already) should work fine.

RESOURCE CHANGE
In App_GlobalResources\GlobalResources.resx add

<data name="Deny Tab.Permission" xml:space="preserve">
    <value>Deny Page</value>
</data>

I inserted it at line 208 (so the first line to add is line 208) in my file. It falls right under the Edit Page entry that way.

CODE CHANGE
DotNetNuke.Library\Controls\DataGrids\Permission Grids\PermissionsGrid.vb
Insert at line 505

                If objPermission.PermissionKey = "DENY" Then
                    Continue For 'Prevents the DENY checkbox from showing for roles
                End If

After that is inserted, lines 504 through 508 should look like

            For Each objPermission In _permissions
                If objPermission.PermissionKey = "DENY" Then
                    Continue For
                End If
                checkCol = New TemplateColumn

DotNetNuke.Library\Components\Tabs\Navigation.vb
Insert at line 284

                Dim objTabPermissionController As New Security.Permissions.TabPermissionController
                Dim objUserInfo As UserInfo = UserController.GetCurrentUserInfo()
                If objUserInfo.UserID = 1 Then 'Host always has access
                    Return True
                End If
                For Each str As String In objTabPermissionController.GetTabPermissions(objTab.TabPermissions, "DENY").Split(New Char() {CChar(";")})
                    If (str = "[" + objUserInfo.UserID.ToString() + "]") Then
                        Return False 'No more checking, current user is denied
                    End If
                Next

I went through and WinDiff'd the entire Library folder, and these are the only 2 code files that were modifed.

So, since there are only 4 changes total; I feel that this is a small enough number of changes for, what I consider, such a benificial tool, that it is something that would be worth release the information on.

Here is what my Permissions settings looks like for a Tab

Even a more minimal change set would be to not modify the GlobalResources.resx, or PermissionsGrid.vb. It would function EXACTLY the same way, the only difference would be on the settings page. The roles would have a DENY check box, and instead of Deny Page, it would say Deny Tab. If the Role Deny was selected, it would add a row to the database, but it wouldn't(shouldn't) have any effect on the tab loading or not.

The overall result of putting an account as DENY on a tab, it overrides ALL other visibility settings. I have a page set with all View Page checkboxes checked; The account I have set to DENY, cannot see that page when logged in.
Again - Setting a User Account to 'Deny Page' WILL prevent that account from seeing that page.

Any feedback on this, good or bad is appreciated and asked for.

And one more time - I'm not responsible for anything that happens for/when using these changes.