Multi project security exception reports - Oracle Primavera P6 Collaborate 14

COLLABORATE 14 Copyright ©2014 by Monks Project Solutions Page 1
Multi-Project Security Exception Reports Will Keep Your Users Happy
and Your Data Safe
Robert C. Monks
Monks Project Solutions
Abstract:
Managing project security permissions in Primavera Contract Management (PCM) can be a daunting
task, and the software doesn't make it any easier. This presentation shows how custom reports can be
used to audit user security, if you administer a PCM solution. Solutions will be demonstrated using both
InfoMaker and BI Publisher making the content valuable to a wide audience of PCM administrators.
Participants will be offered the opportunity to receive the reports demonstrated.
Security in Primavera Contract Management
Security in PCM is implemented through three interrelated features: access templates, user settings and
project assignments. This paper concentrates on managing project specific security settings, rather than
global security.
Access templates contain permissions for modules. Access to each PCM module is controlled. Access
rights include View, Add, Edit, Export and Delete. Each right is managed individually for each module. In
addition, process permissions are included in access templates. The abilities to Reject/Close Change
Management or Update Submittals from Schedule are examples of process permissions.
Finally, access templates control whether a user can approve various PCM documents such as contracts,
purchase orders and daily reports. Additionally, a monetary limit can be set for approval authority on
contracts, purchase orders, change orders and requisitions.
Best practice dictates that access templates be defined by role and are thoughtfully constructed to restrict
access based on the defined responsibilities of each role involved with a project. If the PCM system is
accessed by both internal and external (non-employee) users, we recommend clearly differentiating
access templates designed for internal use from those designed for external use. This will simplify the
process of auditing project permissions over the life of the project. An example of this would be to
prepend “Int-“ or “Ext-“ to each access template name to differentiate templates designated for internal
versus external users.
Every person accessing PCM must be assigned an individual user account. Each user account requires
a company abbreviation and initials tying the login name back to the company and contact information.
Coordinating this information between the information entered through the PCM Administration module
and the Projects module is critical for controlling project access for external users. It’s also required to
properly manage alerts, inbox and approval notifications, if any projects use the approval process in
PCM.
Each user account also contains non-project level (user level) access privileges governing such items as
workspace customization and whether or not they can define cost codes, or custom fields, spec sections,
etc. These privileges are not the focus of this paper.
Every user account must be assigned at least one access template; however users may be assigned
multiple access templates. This would often be the case if an individual plays different roles on different

projects to which they are assigned. Or if everyone is granted limited access to a “Group Companies”
project or company standards projects. Finally, users are assigned to projects using one of their
assigned access templates. This is done through the PCM Administration module.
Projects are the third feature implementing security in PCM. Clearly, there is some overlap between each
of these, but what’s unique about PCM projects is that they have a project administrator assigned.
Initially, this is the user who added the project, but it can be reassigned by a PCM administrator
(someone who has all rights to all projects). The project administrator has the ability to administer project
access (both module and process) only within projects they create or are assigned to. They can also
change their own access rights and copy access rights from any project to projects they create or to
which they are assigned. The important takeaway from this is that a project administrator can change a
user’s access rights within a project such that it is no longer aligned with the access template from which
it was assigned. This can only be accomplished from the project access pop-up dialog within the PCM
application module, not the PCM administration module.
The final interesting bit of functionality, associated with projects, is the ability to further restrict a user’s
project access by company abbreviation. This effectively reduces any module access to only those
documents either to or from the company the user works for. This feature is especially useful for limiting
access to external users. A use case for this would be that I want all of my subcontractors to be able to
access the RFI module and create RFIs to me, but I don’t want them to be able to see RFIs created by
other subcontractors, or RFIs from me to the owner, unless I specifically reference them in the RFI.
PCM’s project security model contains a number of potential exposure risks. First, an administrator could
inadvertently assign the wrong access template to a project for a particular user. This is most likely to
occur when users have multiple access templates associated with their user account. When assigning a
new project to a user from the PCM Administration module, the default template is chosen by default and
the administrator must select the correct one, if it’s not desired. Therefore, a best practice would be to
ensure that the default template has limited or no access to modules by default.
More relevant to this paper is the potential that the access rights have been modified after the access
template has been assigned to a user for a project. This is easy to do, but difficult to detect. A simple
example will illustrate the point. Let’s assume that company policy exists that no documents may be
deleted from the PCM database to ensure data integrity and continuity. An exception might be that if a
document was created totally in error, an administrator may delete it immediately after creation. It’s not
hard to envision a case where a user requests that a project administrator delete a document for a user,
but the project administrator is too busy to accommodate, so he or she temporarily grants delete rights to
the module for the user, just so the user can delete the erroneous document and get on with his or her
job. Unless the project administrator remembers to remove this right immediately after the document has
been deleted, the possibility exists that this user may have permanent delete rights to this module. All
this would be in violation of company policy, but difficult to notice without a security audit.
An equally undesirable exposure results from the failure to assign a company restriction after assigning
project rights to a user via the PCM Administration module. This is easy to forget, as one has to log out
of the Administration module and log in to the Project module. It’s less than an elegant process under the
best of circumstances. Failure to assign a company restriction effectively allows the user to see all
documents, regardless of whether their company is a to-party or from-party in the document.
Perhaps a less likely, but equally undesirable result would occur if the company abbreviation didn’t match
the company restriction in a project. This potentially could result in an employee of ABC Plumbing seeing

all of the change orders for XYZ Electric. This might result from copying an existing user account when
creating a new user account and forgetting to change the company abbreviation in the copied record.
Finally, it’s a potentially significant security risk that a project administrator might just ignore company
security policy and assign additional rights to users beyond the assigned template.
So, what is required to effectively manage project security in PCM? Administrators need to know what
users are assigned to what projects and what access templates users are assigned for each project.
They also need to know what privileges each access template grants each user. And finally,
administrators need an easy way to determine when a user’s access in a project differs from the access
granted to him by the access template.
Security Exception Reports
PCM ships with two standard security reports: Details Security Report (r_sec_login_group_report_01) and
Security Access Report (r_sec_access_report_01).
The Details Security Report is accessed from the PCM Administration module. It reports on all projects
assigned to a user. It does not show the access template assigned and shows nothing about the access
granted to the project.
The Security Access Report is accessed from the PCM Projects module. It reports on all rights granted to
each user on a project. It prints one page per user per project. It is a single project report; therefore, it
must be run for each project. Unfortunately, it provides no easy way to compare project rights versus
access template rights.
Revised Details Security Report
The Details Security Report would be more useful if it reported on the access template assigned to each
project. This modification is easily accomplished by adding the security and user_projects tables to the
report’s data model. The group_name field from the security table contains the name of the template
assigned to the project. The PCM 14.0 MSSQL Server SQL select statement for the original data model
is shown below:
SELECT LOGIN_NAME,
SECURITY_VIEW.GROUP_NAME,
SECURITY_VIEW.PROJECT_NAME,
GROUP_PROJECTS.PROJECT_TITLE
FROM SECURITY_VIEW,
GROUP_PROJECTS
WHERE SECURITY_VIEW.USER_NAME = :USER_NAME
AND GROUP_PROJECTS.project_name = SECURITY_VIEW.PROJECT_NAME
ORDER BY LOGIN_NAME

The SQL select statement for the revised data model is shown below:
SELECT V.LOGIN_NAME, V.GROUP_NAME, V.PROJECT_NAME, G.PROJECT_TITLE,
s.group_name AS template_name
FROM SECURITY_VIEW as V, GROUP_PROJECTS as G,
SECURITY as s,
USER_PROJECTS as u
WHERE V.USER_NAME = ‘:USER_NAME AND G.project_name = V.PROJECT_NAME
AND G.group_name = V.group_name
AND u.group_project_key = v.group_name + '_' + v.project_name
AND u.user_name = v.user_name
AND u.template_key = s.master_key
ORDER BY V.LOGIN_NAME
In the revised SQL select statement, the security and user_projects tables have been added and joined
via the where clause; and the group_name field aliased as template_name added to the data set
returned. This allows the report to be easily modified to include this information; thus, making the report
much more useful for managing user access.
New Security Access Report
We also created a new report to display the rights granted by each of the access templates. This report
was copied from the existing Security Access report, with very minor formatting changes, so it wasn’t a lot
of work. We changed the WHERE clause of the SELECT statement so that it pulled template rows, rather
than project assignment rows. Template rows are actually stored in the same table, but the template
rows have a 1 in the is_template field, whereas the project assignment rows have a zero. The biggest
effort revolved around changing the SQL data model to pull from the security table, rather than the
security_view. I discovered this change in behavior from 13.1 to 14.0 while preparing for this
presentation; therefore, this is a change specific to PCM 14.0. In PCM 13.1 the security_view contains
the rows for the templates, but in PCM 14.0 that changed. I’m not sure what the reason behind this, but
it’s not a huge issue.
New Template Project Differences Report
This is a new report entirely built from scratch. It links each user’s project permissions back to the current
template definition assigned to that project, and then reports on any discrepancies. The report checks all
module permissions, all process permissions and all approval permissions. It even compares any
monetary limits on contract or change order approvals.
It also examines the first three characters of the template name and if the template name begins with
“Ext” (representing an external user), the reports if the assignment has a missing or mismatched company
restriction. The report does not identify specifically what discrepancy exists—it merely reports the
discrepancy.
Applying this Concept to Other Areas of PCM
In my experience, most companies struggle with maintaining consistency within a PCM database.
Everything from telephone number format to whether to use the Postal Code state abbreviation or fully
spell out the state or province seems to offer a myriad of opportunities for inconsistency. While these can
be annoying, or cause documents to look less professional, they aren’t as damaging as missing key data.

The absence on an email address, for instance, will prevent a contact from appearing in the pick list when
trying to send a PCM document via email. I’ve even experienced a case where a user added a contact
on the fly, because she assumed that the person wasn’t in the company and contacts for the project since
they didn’t show up when she searched for them from the email dialog. Of course, they were there, it’s
just that no one had bothered to enter their email address, so PCM doesn’t show contacts who have no
email address in the email dialog.
With this concept in mind, the following list represents examples of multi-project exception reports that we
have written for clients so that administrators can identify nonstandard or missing data. Ideally, these
reports also exist as single project reports so that the individual responsible for the project can perform
self-diagnostics on his or her project data, rather than having the deficiencies pointed out by the
administrator.
Companies missing a Key Contact
Companies missing a Tax ID Number
Contacts missing an email address
Contacts missing a Mobile phone number
Contacts missing address information
Unapproved Budgeted Contracts
Unapproved Committed Contracts
Unapproved Purchase Orders
Unapproved Change Orders
Malformed Cost Codes

Multi project security exception reports - Oracle Primavera P6 Collaborate 14

More Related Content

What's hot (16)

Viewers also liked (18)

Similar to Multi project security exception reports - Oracle Primavera P6 Collaborate 14 (20)

More from p6academy (20)

Recently uploaded (20)

Multi project security exception reports - Oracle Primavera P6 Collaborate 14