To illustrate how an administrator might implement policies and permissions at a specific site, consider xyzBusiness, a company with two major software projects under development.

The xyzBusiness DemoApp team is an established operation producing an application that is crucial to the health of the company. The DemoDotCom project, on the other hand, is experimental looking into new online products and areas of future diversification. These two projects require different management approaches and operating policies:

The following sections show how the administrator at xyzBusiness might set up the ACLs for configuration management taking into account the critical aspects of DemoApp while allowing the freedom and innovation needed for DemoDotCom.

The environment at xyzBusiness supports two divergent sets of development practices. The first thing the administrator must do is to establish control parameters for the entire site. The management team at xyzBusiness, however, wants to apply strict locking to its development environment to better protect valuable data. The outcome is that all member files are write-protected to maintain the integrity of the revision control process.

To implement these rules, the administrator enables and enforces an exclusive locking policy in the global configuration management policy options. For details, see “Configuration Management Policy Options”.

The next step is to provide appropriate permissions to the developers on each project and to guarantee there are no overlaps that could result in a security breach.

After studying the needs of various users, the administrator decides all registered users should be permitted to perform the following actions:

To accomplish this, the administrator first restricts site-wide permissions by defining the following set of ACL permissions in the everyone group on the mks:si ACL.

With this permission, the administrator ensures that, unless project ACLs assign additional permissions to them, users registered at the site can perform only the desired operations. Users who are not registered have no access to Integrity Lifecycle Manager’s configuration management functionality.

The final step is to assign appropriate permissions to the members of each project team.

Most programmers at xyzBusiness work on one project or the other, but some work on both. The administrator’s challenge is to establish ACL entries that give different permissions to programmers on each team without letting them overlap.

Because some programmers work on both projects, the administrator decides to create a role called DemoApp Developer and a role called DemoDotCom Developer in the network authentication system. By defining different permissions for the role in each project’s ACL, the administrator can assign the same programmer different permissions for each project.

At xyzBusiness, the administrator defines the allowed permissions for the Developer group for each project.

Next, the administrator assigns users in each role. Programmers on the DemoApp team receive only those permissions defined in the Developer role in the DemoApp project, while the DemoDotCom’s programmers receive those defined in the DemoDotCom project.

The result is that programmers for DemoApp can work freely with their project and its member files. They can create Sandboxes, check in, check out, and so forth, but they cannot:

These permissions satisfy management’s need for control, while leaving programmers free to update files as required.

For a detailed description of configuration management permissions, see “Configuration Management Permissions”.

The Developer group for the DemoDotCom project is different. Its permissions allow a more open access to the project for all team members. Because the DemoDotCom project is exploratory and creative in nature, it does not require the more conservative restrictions set for DemoApp.