Windows Server 2008
MSSQL 2008 R2
mojoPortal 2.3.6.6

Admin View Permissions and Child Pages Site Map

According to http://www.mojoportal.com/rolesandpermissions.aspx, "if you explicitly set a view/edit permission to admins only then members of Content Administrators cannot edit/view it."

However, this does not hold true in practice.  I set up a test user with a Authenticated User and Content Administrators roles ONLY, set the view permissions on a page to Administrators only, but the Content Administrator was still able to access the page.

Also, when I check "Show Child Pages Site Map" in Page Settings, no site map is being displayed on the page even though all of the child pages have "Include In Child Pages Site Map" enabled.

The child site map appears to have been fixed on the demo site which runs 2.6.3.9.  However, I was still able to reproduce the permission issue on your demo site: http://demo.mojoportal.com/admins-only

if you log in as admin@admin.com, you can see the page, but I also created a testuser@test.com  (password: mojotest009), which belongs to the content administrators and authenticated user roles ONLY.  Even though the view permissions on that page are set to Administrators only, testuser@test.com is still able to view the page.

2.3.70 has fixed the issue reported originally.  However, we ran into nasty issues with our "Content Administrators" here and I had to take a closer look.

Here is what I noticed on the Demo Site:

When "Administrators" is the only role selected under "Roles that can edit this page"
- "Content Administrators" can still:

1. Go to "Page Settings"
2. Go to "Edit This Page"
3. Go to any content's "Settings" residing on this page which allows them to go into "Security" tab of that content and add themselves to "Roles that can edit content"

Q1: Why would a Content Administrator be allowed to go into the Page Settings, Edit This Page,  and Settings of any content (module) residing on the page if "Administrators" had exclusive rights under "Roles that can edit this page?"

Q2: Should module security settings override the security settings of the page on which it resides?

Now here are the issues that we are currently facing with "Content Administrators" after having updated to 2.3.7.0:

1. Can't uncheck "Administrators" checkbox under "Rules that can view this page," "Roles that can edit this page," and "Roles that can create pages below this page."  Somehow I'm able to uncheck "Administrators"  under "Roles that can only edit this page as draft."  Strangely enough, the "Administrators"  checkbox gets checked automatically under those three areas even when I create a brand new page at the root (to avoid inheriting from a parent page).  What's even more peculiar is that despite checkboxes being checked in those three areas the page permissions do appear to be changed, so this is a UI issue as after "Save" is hit, the "Administrators" boxes should be unchecked and they simply aren't. I was not able to reproduce this behavior on the demo site.
2. "Content Administrators" can't access content (module) settings of any content on the site no matter what the page permissions are.  In other words, even if "Content Administrators" can edit the content (module), they can't access the settings still. I was not able to reproduce this behavior on the demo site.

Jamie, that setting is strictly for General & Security tabs to be hidden from non admins, it does not prevent "Content Administrators" from going into settings.  It was set to true, I tried setting it to false just to double-check and it did not make any difference.

Your latest definition of a "Site Editor" is a bit different from what's in the help file which indicates that "Site Editors" have the rights of "Administrators," but limited to a particular site instead of all sites  when "UseRelatedSiteMode" is enabled:

When using Related Sites Mode, all sites in an installation use the same set of users and roles. Therefore a user in the administrators role is an administrator of all sites. Site Editor roles allow you to specify roles that can edit a single site within a multi site installation using related sites mode without making the user an administrator in all sites. Users in these roles will effectively have administrative permissions in a single site whereas if you add them to the administrators role they would have admin permissions in all sites.

Also enforceRelatedSitesMode property in mojoPortal.Business\Role.cs seems redundant to me as you already have UseRelatedSiteMode property that you are checking; the following lines could be adjusted:

Web\Admin\RoleManager.aspx.cs(116):                role.EnforceRelatedSitesMode = WebConfigSettings.UseRelatedSiteMode;
  mojoPortal.Business\Role.cs(57):        private bool enforceRelatedSitesMode = false;
  mojoPortal.Business\Role.cs(143):        public bool EnforceRelatedSitesMode
  mojoPortal.Business\Role.cs(145):            get { return enforceRelatedSitesMode; }
  mojoPortal.Business\Role.cs(146):            set { enforceRelatedSitesMode = value; }
  mojoPortal.Business\Role.cs(209):            if (UseRelatedSiteMode && enforceRelatedSitesMode) { siteID = RelatedSiteID; }
  mojoPortal.Business\Role.cs(327):        //    bool enforceRelatedSitesMode = false;
  mojoPortal.Business\Role.cs(328):        //    return GetbySite(siteId, enforceRelatedSitesMode);
  mojoPortal.Business\Role.cs(331):        public static Collection<Role> GetbySite(int siteId, bool enforceRelatedSitesMode)
  mojoPortal.Business\Role.cs(333):            if (UseRelatedSiteMode && enforceRelatedSitesMode) { siteId = RelatedSiteID; }

How do you prefer to deal with code changes?  Would a mercurial generated  (hg diff) patch be preferable or Codeplex fork w/ pull requests would work better?

I don't know that code changes are necessarily worthy of a forum post... unless it is a behavioral/logical bug that needs to be mentioned/discussed first.

That setting is not meant to take away powers from Administrators or Content Administrators so setting those roles there would not have any effect, just the same as those roles do not need to be checked to allow editing by Administrators or Content Administrators. I should probably filter those roles out for that setting, I'll look into doing that.

Personally, I think having "Administrators" role showing up under all settings is a bit misleading as they [Administrators] can do anything regardless of whether the checkbox next to them is checked or not.  I would take it out everywhere and instead select "Content Administrators" for every newly created page/module by default.  In cases where a non-root page is being created, it will simply inherit from the parent as it does now.

The admin only corner cases would apply when all of the checkbox are unchecked under any given setting. 

Doing this will make it clear to anybody that "Administrators" are godlike and you don't even need to bother messing with the checkboxes next to them.

Thoughts?

But not in other places like page settings because it is needed there for the case where you want to limit something to only administrators.

That is exactly the point I was trying to make.  You would just have all of the checkbox unchecked in which case it would automatically be "Administrators" only.  See what I'm saying?

I see what you are saying but that would require a lot of changes because if we add logic to set the roles to only admins when nothing else is checked, then Content Administrators would need to always be checked in order for content admins to have access whereas currently Content Admins can edit anything without having their role explicitly checked as allowed.

It sounds like "would require a lot of changes" is the primary reason and I would certainly be more than willing to submit a patch. I understand that having put in place WebUser.IsAdminOrContentAdmin  or '== "Admins;")' all over the source makes it a bit cumbersome to modify, but it would simplify the UI and that's all that matters at the end of the day.

You could have a couple queries in the update script to modify the database to reflect the way new UI works by checking which EditRoles are null or empty and setting those "Admins; Content Administrators;".  Your last point will be addressed since the update script will convert all null/empty  view/edit roles to  "Admins;Content Administrators;" and if the user DID want an Admin only scenario, they would have to uncheck "Content Administrators" or whatever other roles they had checked, so it would require them to perform an action and would not happen accidently. 

Speaking of accidently, the reason we ran into Admin only scenario was because those "Administrators" checkboxes were being checked by default due to the logic in PageSettings.aspx.cs and thus every time "Content Administrator" modified page settings, they would automatically lock themselves out of the page by creating an Admin Only scenario since the "Content Administrators" checkbox was not checked either.

Just trying to improve the overall product for the end user here, that's all.

In my opinion, the fewer UI elements the user has to deal with, the better.  Taking Admin and Content roles out will also spare you from having to answer questions like "How come I unchecked Content Administrator/Administrator box, but he/she can still view it?"  Because there certainly will be people that will try to create sections of the site for which they wouldn't even want Administrators to have access to. Any scenario is possible at the enterprise level.

Thank you for all of your hard work and patience.