Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Host (Super User) Override FunctionalityHost (Super User) Override Functionality
Previous
 
Next
New Post
10/20/2006 9:09 AM
 

professorcw1, do you have any additional thoughts to my reply?

To others, there are many reasons why it doesn't make sense to create a sub-Admin group (Admin #2) and only give that out as the highest level permission to the customer.  Too many of the "admin-like" tasks require admin access to actually perform the task. 

I have spent much time testing and creating a new security group called "Admin #2" and duplicating the Admin Tab and sub menus only with pages and tasks that I want them to perform; only to find out that while I may be able to achieve 98% of what I am hoping, there will always be that 2% that will have holes with things you don't realize until there is extreme QA activity.

For instance, when Admin #2 creates a new page and forgets to give himself "edit" privelages on the new page.  Whollaaaaa, they just created a new page that they cannot edit (because by default only the "admin" group has edit privileges to a new page unless more are selected).  This is just one of many reasons why this approach is not practical.

professorcw1, you are on the right page with your thought process.  Can you continue your thoughts to my initial reply?

Much appreciated to all!

 
New Post
10/21/2006 10:10 AM
 

First of all, I generally agree with the Admin #2 approach.  To me, this group ranks 3rd in the priv hierarchy (host > admin > admin 2).  This isn't what I understood you wanted.  What I think you are asking is for a way to drop on a module that prohibits Admins from editing a page.  Basically, you want a host level page that can be viewed by all (or specified groups) and only edited by hosts.  Is that right?

Presuming my assumption is right, I thought I'd try it out.  I hadn't really thought about the PA approach, but when it was suggested I couldn't think of any reason it couldn't be done.  So I tried.  I built a module that has no interface but simply runs some sql to adjust the priv settings.  I get close.  For some reason, though, if the page is located outside the host structure (child of host), it automatically resets the page privs everytime you update Settings.  When it does this, it grants Admin edit access again.  I'm not sure why that is.  Maybe someone can figure that out.  The approach I took was to mimic TabPermission settings for host pages and then add a View priv to All Users.  I can't think of why this isn't possible, but I can't get it to work.

In my environment, we want control over what pages an Admin has access to, but we still use the regular Admin group.  All we're really doing is removing and adding pages under the Admin tab.

It seems like when you take the page out from underneath Host, something happens behind the scenes that says "Hey, Admins should be able to edit me" and it makes the priv adjustment.  I'll keep trying because I'm puzzled by not being able to do something (even if it's not the right approach).  For now, you may be stuck with the Admin 2 method.  That should work, just don't ever put someone in the built-in Admin role.

One other thing you could do is create a PA like I was trying that automatically sets edit privs to your Admin 2 role.  If you set this module on all pages it should take care of the issue of an Admin 2 person forgetting to assign Edit privs to himself.

 

 
New Post
10/23/2006 12:13 PM
 

You are absolutely correct.  As a HOST, I am looking for a clean and easy way to protect a page(s) from being edited by even the ADMIN group.

I think you are on the absolute right page with the Host Page logic you described above. 

Your continued help is appreciated!

 
New Post
10/26/2006 5:17 PM
 

Can I pay you to create this module for me?

 
New Post
10/26/2006 7:20 PM
 

I'd love to, but my whole team is currently on 100% retainers.  I'm sure there are several developers hanging out around here that can help you.  Post a pretty detailed spec; you'll get some bites. 

When I have overflow work I send it to Business Intelligence Force http://dnn.bi4ce.com  These guys are fast and reasonably priced.

 

 
Previous
 
Next
HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Host (Super User) Override FunctionalityHost (Super User) Override Functionality


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out