Chapter 5. Real World Example

Table of Contents
Sample Organization
Users and User Groups
Creating Principals
Creating Contacts
Creating Local User Groups
Creating Users
Assigning Group Memberships
Objects created by ceo
Objects created by sales-repA1
Selective Readonly Sharing
Co-operating Sales Teams

This example is built around a small company with several departments. We first configure a basic security setup around the organizational structure of the company following some common sense rules. Later on we will look at a few improvements of the security configuration to implement more advanced access rules. The structure of this chapter is as follows:

Sample Organization

This example is built around a small company structured as shown in the following organizational chart:

Figure 5-1. Organizational Chart

The sales department (Sales) features a head of sales (head-sales) and 2 sales teams (SalesTeamA and SalesTeamB). Each sales team consists of 2 sales reps (e.g. SalesTeamA consists of sales-repA1 and sales-repA2). Similarly, there is an accounting department (Accounting) with a head of accounting (head-accounting) and an accountant who is the only member of the team AccountingTeam.The structure of the production department is identical to the structure of the accounting department. The company has a board (Board) with three members: ceo, cfo, and coo.

Please note that the above organizational chart does not contain any security-related information, i.e. it does not tell us anything about permissions and such - an org chart is an org chart and nothing more when it comes to security (even though it is probably not wrong to assume that sales-repA1 should not be allowed to see any objects owned by the ceo unless the ceo has granted such permission explicitly). Before we get started with setting up security let us make a few assumptions about the desired "default security settings" of this organization (please note that the following "rules" really are assumptions, i.e. there is nothing in openCRX that would force you to adopt such rules; we just need a set of rules for the sake of this example enabling us to show how security-related rules can be implemented.):

every board member should be granted permission to access any object (browse/delete/update), including those created by any other board member, i.e. ceo, cfo, and coo have full access (browse/delete/update) to all objects
SalesTeamA and SalesTeamB do not co-operate (i.e. objects created by a member of SalesTeamA cannot be accessed by members of SalesTeamB and objects created by a member of SalesTeamB cannot be accessed by members of SalesTeamA)
department heads have full access (browse/delete/update) to any object created by a member of their department (e.g. head-sales has browse/delete/update access to all objects created by sales-repA1)
there are "Chinese walls" between departments, i.e. objects created by a particular department are not accessible (browse/delete/update) by any other department (e.g. objects created by the sales department cannot be accessed by neither the accounting department nor the production department
users are never automatically granted access (browse/delete/update) to objects created by users on a higher organizational hierarchy (e.g. sales-repB2 is not granted access (browse/delete/udpate) to objects created by head-sales or board members like the cfo)
all members of a particular organizational unit should have the same permissions (e.g. sales-repA1 should have the same permissions as sales-repA2, but permission of sales-repB1 may very well differ from those of sales-repA1)