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. The administrator may connect PowerDesigner to an LDAP server for authentication, an SMTP server for automating notifications, and specify a policy to control the strength and duration of passwords.

Repository rights give users access to general repository features, while permissions give them access to particular locations in the repository. The following rights and permissions are available:
Rights (Entire Repository) Permissions (Per Folder or Item)
  • List - View the document or folder in the browser and in search results, and open property sheets. Without this permission, users cannot even see the item.

  • Read - Also compare documents, and check documents out from the repository.

  • Submit - Also check the document into a changelist for review by a user with Write permission.

  • Write - Also check in (with or without a changelist), freeze, and lock document versions.

  • Full - Also manage permissions granted to users or groups and remove locks on documents.

  1. [optional] Connect the repository to an LDAP server to manage user access (see Connecting to an LDAP Server for User Authentication).
  2. [recommended] Connect PowerDesigner to an SMTP server to enable the automatic sending of emails for passwords, changelist submissions, and other notifications (see Connecting to an SMTP Server for Notifications).
  3. If some or all your users will not be managed by LDAP, specify an appropriate password policy (see Defining a Password Policy).
  4. Create high-level functional groups (see Creating Repository Groups) to organize users by type and assign appropriate rights to them to govern general actions that they can perform in the repository (see Granting Rights to Users and Groups).
    For example:

    Groups

    Rights

    Administrators Connect, Manage All Documents, Manage Users, Manage Repository
    Senior Architects Connect, Freeze Versions, Lock Versions, Edit PowerDesigner Portal Objects, Manage Branches, Manage Configurations
    Architects Connect, Freeze Versions, Lock Versions, Edit PowerDesigner Portal Objects
    Business Analysts Connect, Freeze Versions, Lock Versions, Edit PowerDesigner Portal Objects
    Stakeholders Connect (to provide read-only access via the PowerDesigner Portal).
    Note: There is no requirement to create groups - you can assign rights and permissions to individual users - but we recommend that in all but the smallest deployments, you do create groups to simplify the process.
  5. [optional] Use the supplied profiles or develop others and apply them to your groups as necessary to filter the PowerDesigner interface to hide or render read-only types of models, objects, and properties, and to specify defaults for interface elements, options and preferences for different kinds of users (see Using Profiles to Control the PowerDesigner Interface).
    In our example, business analysts need only contribute to requirement models, enterprise architecture models, and conceptual data models and all other types of models are hidden from them. We could imagine dividing the Architects group into subgroups such as enterprise architect and information architect and hiding or rendering read-only models that do not concern them.
  6. Create an appropriate folder structure in the repository (see Repository Folders) to enable you to group documents by project or in any other appropriate way, and to simplify the granting of permissions.
    In the example, the team will use the library folder to share reference models and other documents, and to push targets, extensions, and other resource files to users (see Deploying an Enterprise Library). In addition, two modeling projects are proposed, and all the documents related to them will be kept in the two top-level folders.
  7. Determine your review policy either at a global or project by project level. PowerDesigner supports the following kinds of policy:
    • Simple review - Change lists submitted by users with the Submit permission are reviewed by a single user with the Write or Full permission.
    • Peer review - Users with the Write or Full permission voluntarily submit change lists for review.
    • Direct check in - The Submit permission and change lists are not used, and users all check in changes without review.
  8. Create development groups and implement your review policies by assigning appropriate permissions to control what actions users and groups can perform on particular repository documents and folders such as your library, glossary model, and modeling projects.
    In the example, we propose:
    • A Compliance Committee who can modify the reference models and shared resource files contained in the library and can submit changelists for inclusion in the glossary model.
    • A Terminology Committee who can modify the glossary model.
    • For each project, lead architects are able to check in changes to the project (and submit changelists for inclusion in the glossary), and regular architects can submit changelists to the project.
    • A cross-project stakeholder groups with read-only access (though we could imagine sub-folders within each project for which these users would have write or submit permission for storing their own documents).
    Group Library Glossary Model Project A Project B
    Administrators Full Full Full Full
    Compliance Committee Write Submit Read Read
    Terminology Committee Read Write Read Read
    Project A Leads Submit Submit Write Read
    Project A Team Read Read Submit Read
    Project B Leads Submit Submit Read Write
    Project B Team Read Read Read Submit
    Business Stakeholders Read Read Read Read
  9. Create as many users as necessary either manually (see Creating Repository Users) or via LDAP (see Creating Repository Users Managed by LDAP) and assign them to appropriate groups (see Adding Users and Groups to a Group) according to their roles and project responsibilities.
    There is no limit to the number of groups to which a user or group can be assigned, and users benefit from the cumulative total of all the rights and permissions they receive. In our example, if a business stakeholder is also a member of the Terminology Committee group, then she will have Write permission on the glossary model.