People, Organization and Security Startup Data | ||
| ||
What Is Startup Data?
P&O and Security startup data are essentially default persons, security contexts, policies and rules.
An ENOVIA VPM Multi-Discipline Collaboration Platform installation provides the data in the form of a set of MQL script files, containing data creation statements, that are integrated into the installation procedure and executed against the ENOVIA VPM Multi-Discipline Collaboration Platform repository during the installation.
Note:
MQL is the native query language provide by the ENOVIA V6 application infrastructure. Please refer to the Matrix Query Language (MQL) Guide for details concerning the specifications of MQL.
This set of P&O and Security data includes both MANDATORY data and SAMPLE data:
- MANDATORY data are system data which are alwways installed and are essential for the system to operate: this data must not be edited; for example, roles are always installed
- SAMPLE data are, for example the demo data you may have unloaded at installation: persons, projects, organizations and security contexts (this data is for demonstration purposes only and is not intended to be deployed for production purposes).
In fact, installing the ENOVIA VPM Multi-Discipline Collaboration Platform installs a sample customization of ENOVIA V6.
The sample customization is intended to be used as a starter and to understand how the PLM core model works. The sample customization is in no way intended to be deployed for production purposes.
Additional P&O and Security data may be authored subsequently using either:
- the VPLMPosImport batch administration tool (to import P&O data)
- or MQL scripts (to author security data).
Refer to the section Authoring People and Organization Data in this guide for more details.
Default Startup Data
P&O and Security startup data are provided to address the needs of companies requiring both an out-of-the-box solution and also more advanced security setup and administration tools.
The startup data include objects of the following types:
- projects
- organizations (companies and business units)
- roles
- persons
- filters
- policies (and rules)
- secured commands.
You now have a basic understanding of projects, organizations, roles and persons, and the central role played by the security context: all of the latter are P&O data. Filters, policies, rules and commands are all security data.
Checking the option Set Up VPM People and Organization Demo Data during the installation installs demo data comprising persons, projects, organizations and security contexts for demonstration purposes only. The check box is checked by default. If you decided not to install the VPM demo data, the demo users, etc. will not be created.
People and Organization Data
The following tables summarize all the P&O data installed by default and visible to end users and administrators at logon time.
Projects
These are the projects:
| Project Name | Description |
|---|---|
| Default | Default project |
| Standard | Standard project |
| Engineering | Engineering project |
Organizations
These are the organizations:
| Organization Name | Description |
|---|---|
| Company Name | Default (installed with kernel, but re-used by VPLM) |
| Supplier1 | Supplier1 (only if demo data checked at installation) |
Roles
Roles are always installed (even if demo data checked at installation).
These are the roles:
| Role Name | Description |
|---|---|
| Local Administrator | Role for local administration |
| DemoLocalAdministrator | Demo local administrator (only if demo data checked at installation) |
| VPLMAdmin | VPLM administration role |
| VPLMDesigner | VPLM designer |
| VPLMLeader | VPLM project leader |
| VPLMReviewer | VPLM reviewer |
Security Contexts
Security contexts are not native ENOVIA V6 objects: they are created at installation to allow persons to log onto VPLM applications with the appropriate accesses.
Security contexts are visible in the ENOVIA V6 Business application and are identified by the prefix ctx:: like this, for example:
ctx::VPLMDesigner.Company Name.Standard
This is the list of security contexts:
| Security Context Name | Description |
|---|---|
| Local Administrator.Company Name.Engineering | (only if demo data checked at installation) |
| Local Administrator.Company Name.Standard | (only if demo data checked at installation) |
| Local Administrator.Supplier1.Engineering | (only if demo data checked at installation) |
| Local Administrator.Supplier1.Standard | (only if demo data checked at installation) |
| VPLMAdmin.Company Name.Default | VPLM administration context, accessible only to the VPLM administrator |
| VPLMAdmin.Supplier1.Default | VPLM administration context, accessible only to the VPLM administrator |
| VPLMDesigner.Company Name.Standard | VPLM designer context for Company Name standard project |
| VPLMLeader.Company Name.Standard | VPLM leader context for Company Name standard project |
| VPLMReviewer.Company Name.Standard | VPLM reviewer context for Company Name standard project |
| VPLMDesigner.Company Name.Engineering | VPLM designer context for Company Name engineering project |
| VPLMLeader.Company Name.Engineering | VPLM leader context for Company Name engineering project |
| VPLMReviewer.Company Name.Engineering | VPLM reviewer context for Company Name engineering project |
| VPLMDesigner.Supplier1.Standard | VPLM designer context for Supplier1 standard project |
| VPLMLeader.Supplier1.Standard | VPLM leader context for Supplier1 standard project |
| VPLMReviewer.Supplier1.Standard | VPLM reviewer context for Supplier1 standard project |
| VPLMDesigner.Supplier1.Engineering | VPLM designer context for Supplier1 engineering project |
| VPLMLeader.Supplier1.Engineering | VPLM leader context for Supplier1 engineering project |
| VPLMReviewer.Supplier1.Engineering | VPLM reviewer context for Supplier1 engineering project |
| Local Administrator.Company Name.Standard | Context for local administrator for standard project |
| Local Administrator.Company Name.Engineering | Context for local administrator for engineering project |
Note: The parent-child relationship between P&O objects implies that the security access definition is inherited from parent to child, as provided natively by the ENOVIA V6 security infrastructure. This means, for instance, that any access defined on the project Standard will be automatically inherited by security contexts VPLMDesigner.Company Name.Standard, VPLMLeader.Company Name.Standard and VPLMReviewer.Company Name.Standard. This mechanism makes it possible to share and factorize security access definitions between several objects.
Default Users
Several default users have been delivered and created at the installation, in order to ease administration and to perform quickly some demonstrations.
| User | Assigned Context |
|---|---|
| DemoDesigner | VPLMDesigner.Company Name.Standard |
| DemoLeader | VPLMLeader.Company Name.Standard |
| DemoReviewer | VPLMReviewer.Company Name.Standard |
| DemoSupplier | VPLMLeader.Supplier1.Standard |
| DemoLocalAdministrator | Local Administrator.Company Name.Standard |
Note: Administration User (not in the above table) is not a VPLM user: it is reserved for use by CBP applications. Refer to the section "Persons" in the Studio Modeling Schema Reference Guide.
The default VPLM administrator user PLMADM is also created during the installation of the ENOVIA VPM Multi-Discipline Collaboration Platform. Note that you can customize this name during the installation procedure. The VPLM administrator user is assigned to the context:
VPLMAdmin.Company Name.Default
If you installed the demo users, you also have the option of alternatively deactivating or activating them by checking/unchecking the Active option in the person's properties using the administration console.
Security Data
All security objects are ENOVIA V6 administrative objects: Policies and Rules. There is no business object to represent security concepts.
Policies
A policy is an ENOVIA V6 administrative object. It defines a set of rules that govern business objects, such as who has access to an object, what levels of access are available, and when access is permitted. Policies define the lifecycle of objects and the conditions required to move through the stages of its life.
The security model is based directly on the ENOVIA V6 administration model. Please refer to the ENOVIA V6 documentation (for example, the Business Modeler Guide) for details concerning the ENOVIA V6 administration model.
A number of default policies are provided at installation. These policies can be used as is and require no further customization.
They govern the various PLM types defined in the PLM model:
- PLM Connection
- PLM Product
- PLM Representation
- PLM Port
PLM instances:
- PLM Representation Instance
- PLM Product Instance
are governed by rules.
The principal default policies governing PLM types are:
| Policy Name | Description |
|---|---|
| VPLM_SMB | Default VPLM policy governing all PLM reference types |
| VPLM_SMB_PORT_CX | Default VPLM policy governing all PLM port and connection types |
| VPLM_UNSECURED_CX | Default VPLM policy governing unsecured PLM connection types |
| VPLM_SMB_SR | Default VPLM policy governing internal PLM semantic relations |
| Policy Name | Governs | Needs Administration |
|---|---|---|
| VPLM Project Template | VPM Project Template objects | No |
| VPLM_Action | VPLM Action objects | Yes |
| VPLM_MappingModeler | Coexistence objects | No |
| VPLM_PRIVATE | Private PLM types | No |
| VPLM_PosResourceRef | P&O Resource reference objects | Yes |
| VPLM_PosResourceRep | P&O Resource representation objects | Yes |
| VPLM_Replication | Replication objects | No |
| VPLM_SMB | VPM sample custom reference objects | Yes (sample) |
| VPLM_SMB_Chapter | VPM Requirement Chapter reference objects | No (deprecated) |
| VPLM_SMB_Comment | VPM Requirement Comment reference objects | No (deprecated) |
| VPLM_SMB_DOCUMENT | VPM sample custom document objects | Yes (sample) |
| VPLM_SMB_PORT_CX | VPM sample custom port & connection objects | Yes (sample) |
| VPLM_SMB_Requirement | VPM Requirement reference objects | No (deprecated) |
| VPLM_SMB_RequirementSpecification | VPM Requirement Specification reference | No (deprecated) |
| VPLM_SMB_VS_ActivateDeactivate | Configuration dictionary object | No |
| VPLM_SMB_WorkspaceRootRef | Design Workspace root reference object | No |
| VPLM_SR | Semantic Relationship objects | No |
| VPLM_SignoffAction | VPLM Signoff Action objects | Yes |
| VPLM_TaskAction | VPLM Task Action objects | Yes |
| VPLM_UNSECURED_CX | Unsecured connection objects | No |
Note:
Lock/Unlock
VPLM policies do not enforce strict locking, i.e. unlock is secured as all other accesses: no check is made to prevent users from unlocking data they did not lock themselves.
However, strict locking may be implemented by adding an expression such as:
('$ACCESS' != 'unlock') || (reservedby ==context.user)
to the relevant policy filters, in order to test that the reservation (Lock) user is the same as the current user when trying to unlock an object.
The following policies govern rules:
| Policy Name | Governs | Needs Administration |
|---|---|---|
| VPLM_SMB_INSTANCE | VPM sample custom instance objects | Yes |
| VPLM_UNSECURED_REL | VPM unsecured relationships | No |
| VPLM_SMB_UNSECURED_INSTANCE | VPM unsecured instance objects | No |
Filters
Expressions are provided in the startup data. These expressions can be referenced in policy states in order to define security accesses. Expressions are referred to also as filters.
The role of expressions is to determine access to objects based on object ownership.
Access rights are based on data ownership. Data can be owned by the person who created the data, the project to which the person is assigned, or the organization to which the person belongs.
Secured Commands
By default, commands not listed in the table below are available to ALL users.
For example, being able to read data does not necessarily meant that you are authorized to export data, so securing commands such as data import/export commands in VPLM applications is essential for security reasons.
However, since the set of existing accesses on policies (e.g. Read, Show, etc.) cannot be extended to include importing and exporting, startup policies cannot be used to secure such high-level commands which are unknown to the ENOVIA V6 security infrastructure. Consequently, the startup data include a number of ENOVIA V6 commands which are ENOVIA V6 administrative objects.
These commands are the only way of securing data import/export operations on the VPLM client. The ENOVIA V6 administrator must customize the commands so as to limit their access to particular sets of users.
Apart from the import/export commands, other VPLM application commands can be secured. The (non-exhaustive) list of commands is as follows:
| Command | Description |
|---|---|
| ADMINISTRATION | VPLM Administration command |
| DATABASEDETACH | Database Detach command |
| DisableChangeControl | Disable Change Control command |
| Duplicate | Duplicate command |
| DuplicateUsingDistantData | Duplicate Using Distant Data command |
| Edit workspace content definition | Edit workspace content definition |
| EnableChangeControl | Enable Change Control command |
| EXPORT | VPLM export command |
| IMPORT | VPLM import command |
| NewVersionUsingDistantData | New Version Using Distant Data command |
| RepairSiteOwnership | Repair Site Ownership command |
| SAVE | Save command |
| SynchronizeAndTransferToMatrix | Synchronize And Transfer To Matrix command |
| SynchronizeWithMatrix | Synchronize With Matrix command |
| Transfer Ownership | Transfer ownership to user on same project and organization |
| Transfer to User | Transfer ownership to user on same project |