Channel Partner Web (CP Web) is a Microsoft (MS) internet site that is used by three groups of people. The first group consists of organizations around the world that buy licenses for MS software. These people are considered to be external users. The second group consists of individuals working at MS subsidiaries around the world. These people are referred to as internal users. The third group is made up of a handful of people who are in charge of maintaining the site on a global level, the global admins.

CP Web is a database driven website that is intended to deliver material to the users of the site. The content on the site is profiled so that that each user only sees information that is intended for that user. Profiling can be done on the country, organization, and individual basis. By profiling the content, the organizations are able to view/download content that is specific to them without seeing content intended for other organizations. This includes information relating to software licenses that organizations have purchased. Similarly, the subsidiaries are able to download pricing lists that are specific to their area without seeing pricing information for other subsidiaries.
 

 
I have worked on several projects for CP Web. For one of these projects, I was asked to improve to administrative pages on the site. The administration pages were only used by internal users (who were specified to be admins) and the global admins. Part of the project was to create a new set of admin tools for external admins. This would allow organizations to maintain their own users without having to send requests to the global admins to have changes made.

One of the tools allowed the internal admins to assign themselves to other organizations in order to confirm that content intended for that organization was profiled correctly. The problem with this tool was that an internal admins could select users other than themselves and assign other users to different organizations. This is useful for the global admins because they oversee the entire site, but the internal admins did not need this ability. If fact, it led to problems when some users were inadvertently assigned to different organization.

(click image to zoom)
 


(click image to zoom)
 
Another problem, was that the tools were slow. One tool that the global admins used was to assign admin rights to internal users. In order to do this, every user would be listed on one page with a checkbox next to the name. With over 40,000 users, this page took a while to load. Only one user at a time could be assigned admin rights, which meant that the entire page had to load again in order to select the next user.

What I did was to allow the global admins to access users in a couple of ways. First, I made a search page in which criteria such as name, organization, and email could be used to find a user within the database. The search criteria can also be a partial string so that everyone whose name starts with "nic" could be listed. From there, the global admin is then able to select the name of the user that s/he is looking for.
 

 
After finding the correct user, the global admin is able to modify/delete the user. The screen will look different depending on whether the user being viewed is an internal or an external user. External users only have a checkbox to specify whether or not they are an admin. If an external user is an admin s/he can add/modify/delete user within his/her organization.

Internal admins, on the other hand, are assigned rights to specific tools explicitly. If they are an admin, an extra box will appear listing the individual tools that are available. One feature of this system is internal admins are only able to assign rights for tools to other admins if they have been given rights to the tools themselves. That way, if an internal admin has rights to add users, but not to delete users, then when that admin adds a user, s/he can give the new user add rights, but not delete rights.

(click image to zoom)
 


(click image to zoom)
 
In order to keep track of who was assigned to which admin tools, I had to create two new tables. One table held a list of the available tools, while the other was a correlation table that recorded which admins were able to use which tools by matching the existing user table to the admin tools table.

There were additional security precautions added to make sure that external admins would not be able to access the internal admin tools, and that internal user would not be able to access the external admin tools.

The result was improved performance and improved efficiency when dealing with maintaining CP Web user accounts.