You'll need to take it a few steps further to restrict access to the manager. You're not doing anything wrong really, but it is normal for a manager user to have full permissions at first and even assigning the role of Super User and Administrator user group does not grant further permissions over users in other roles and user groups that do not have restrictive ACL's.
When you refer to the permissions your users have, there are a few ways to restrict access to the elements and files trees, and also what menus the users see.
The next step is to begin to restrict this user group's manager permissions with a context access for the web, but not based on the standard content editor's permissions. You'll start with the Administrator Access Policy, and then begin removing permissions.
See Bob's Guides for more information -
http://bobsguides.com
An excerpt regarding restricting manager access:
Let's say you have a User Group called SubAdmins and you want the Users in that group to be able to use the Manager, but with restricted capabilities. Here are the steps you would take:
First, create a Role of SubAdmin with an authority level of 9.
Create the SubAdmins User Group and add the Users to it with a Role of SubAdmin.
Duplicate the standard Administrator Access Policy.
Edit the duplicate and change the name to SubAdmin.
On the Permissions tab, uncheck any Permissions you don't want your SubAdmins to have. Removing the access_permissions Permission will keep them from changing their own security level and those of other Users. Removing the element_tree and file_tree Permissions will prevent them from seeing those tabs in the left panel of the Manager. (Note: the element_tree and file_tree Permissions are only available in the SVN and upcoming RC versions of Revolution.)
Save the Policy
Update the SubAdmins User Group by going to Security | Access Controls | User Groups tab, right-clicking on the SubAdmins Group and selecting "Update User Group."
Go to the Context Access tab.
Add an ACL entry (by clicking on the "Add Context" button). Give it the following:
Context: mgr
Minimum Role: SubAdmin
Access Policy: SubAdmin
Go to Security | Flush Permissions
If you quit now and log in as one of the SubAdmin Users, the login would be successful but the Resource tree at the left would be empty because we haven't given our SubAdmin users access to the "web" context. We need to create another Context Access ACL entry with the following:
Context: web
Minimum Role: SubAdmin
Access Policy: SubAdmin
Now, our SubAdmins are real Manager users with restricted access to the Manager.
Note that we could have done this another way. We could have skipped creating the SubAdmin User Group and just added all our SubAdmin Users to the Administrator User Group with a Role of SubAdmin. Then, we'd have Updated the Administrator User Group and added the two Context Access ACL Entries listed above. The results would be the same and which way you do it is a matter of your overall Security strategy. If you will be restricting which Documents the SubAdmins can see, you'll probably want to create a separate User Group for them. If they will have access to all the Documents in the Manager, you might rather add them to the Administrator User Group.
I generally recommend *not* putting other admin users in the Administrator group. Giving them their own group makes things easier to understand and will give you more options for Form Customization.
Nothing you do in a Context Access ACL will affect which documents any user can see in the front end. That can only be done in a Resource Group Access ACL specifying a Context other than the "mgr" Context.
☆ A M B ☆
☆ A M B ☆