Controlling Repository Access

The repository administrator is responsible for controlling access to the documents stored in the repository, by creating users and groups and assigning them rights, permissions, and profiles.

By default, the repository has only one user, ADMIN, with all available rights on everything in the repository. This administrator is responsible for creating other users and groups. When you create a user, she is automacially granted the Connect right (see Granting Rights to Users and Groups) and assigned to the PUBLIC group which has, by default, Read permission (see Granting Access Permissions on Repository Items) on the repository root.

The following examples provide some suggestions for the rights and permissions you will want to grant to your development team.

Example 1: Granting Rights to Groups and Users

The following rights are granted to the groups and users who will work on a modeling project:

Groups or Users	Rights
Repository Administrator	Connect, Manage All Documents, Manage Users, and Manage Repository (to manage the repository and users)
Data Administrator	Connect, Manage All Documents, Manage Users, and Manage Repository (to manage repository data)
Project leader	Connect, Freeze Versions, Lock Versions, Manage Branches, and Manage Configurations
Developers	Connect, Freeze Versions, and Lock Versions
Designers	Connect, Freeze Versions, and Lock Versions

Note: Users who have the Manage All Documents right (typically data administrators), are implicitly granted Full permission on all repository documents. Such users can check in, freeze, lock, and even delete documents for which they have been explicitly granted only Read permission.

Example 2: Granting Permissions on Folders and Documents

The Y2K folder includes two sub-folders, Data and Specs. The Data sub-folder contains two models, Firstdraft (PDM) and Classes (OOM). The Specs sub-folder contains Overview.doc.

The following permissions are assigned to the groups and users working on the project:

Folder	Project leader (user)	Development leader (user)	Developer (group)	Design leader (user)	Designer (group)
Y2K	Full	Read	Read	Read	Read
Data	Full	Write	Read	Read	Read
Documents in Data	Full	Read	Write	Read	Read
Specs	Full	Read	Read	Write	Read
Documents in Specs	Full	Read	Read	Read	Write

Example 3: Granting Permissions on Packages

The model FIRSTDRAFT is divided into 2 packages, ANALYSIS and IMPLEMENTATION, which correspond to the different tasks the group of developers has to perform. Each of these packages is, in turn divided into two sub-packages, and one developer has responisibility for each sub-package.

The following permissions are assigned to users:

Package	Dev. leader	Dev.1	Dev.2	Dev.3	Dev.4
Analysis	Full	Read	Read	Read	Read
Global_ System	Full	Write	Read	Read	Read
Per_Dept	Full	Read	Write	Read	Read
Implementation	Full	Read	Read	Read	Read
Department	Full	Read	Read	Write	Read
General	Full	Read	Read	Read	Write

Creating Repository Users
The repository administrator is responsible for creating user accounts to enable users to connect to the repository and access the content that they need.
Creating Repository Groups
The repository administrator is responsible for creating groups of users in the repository. Users are added to groups in order to simplify the granting of rights and permissions and the use of profiles. You can create hierarchies of groups. For example, you could insert the Designers, Quality Assurance, and Documentation groups into the R&D group, to which you assign permissions to documents that all these groups must use.
Granting Access Permissions on Repository Items
The repository administrator or a user with Full permission on a document can grant permissions on it from the Permissions tab of its repository property sheet. You can grant permissions on the repository root, folders, PowerDesigner models and model packages, and external application files, but not on individual model diagrams or objects.
Controlling Repository Access with LDAP
A repository administrator can delegate the authentication of repository users to an LDAP server. Once the repository has been configured to permit access to users authenticated by LDAP, any such user can connect without further intervention from the repository administrator. The first time that an LDAP user connects to the repository, an account is automatically created for him in the External users and Public groups.
Defining a Password Policy
The repository administrator is responsible for defining a password policy to ensure that passwords are sufficiently secure and changed at appropriate intervals. To modify the password policy, connect to the repository and select Repository > Administration > Password Policy.
Specifying an SMTP Server for Notifications
The repository administrator can automate the sending of passwords to users by specifying an SMTP server for PowerDesigner to use. To specify an SMTP server, connect to the repository and select Repository > Administration > SMTP.
Auditing Repository Activities
Users with the Manage All Documents right can use the List of Activities to audit operations performed on repository documents, analyze user behavior patterns, and highlight activity sequences. Activities are actions that modify repository documents, such as check in, freezing, and deleting.
Querying the Repository Using SQL
Administrators can run basic SQL SELECT queries against the repository through the Execute Query window. For more complex queries, you should use your DBMS query editor.
Obtaining Emergency Access to the Repository
In the event that no administrator is able to log in to a running repository, it is possible to create an emergency administrator account to regain access.

Parent topic: Administering PowerDesigner