Allow Read-access to Any Public Content

This access rule determines if users logged into a collaborative space and organization can access public content created in other collaborative spaces that belong to the same organization. This access is called cross-collaborative space visibility.

This access rule is activated by default.

This access rule only affects the non-restricted baseline access roles.

This page discusses:

Activated or Deactivated

When this access rule is activated, a user logged into Org1 and CollabSpace1 can access public content in CollabSpace2 as long as that collaborative space also belongs to Org1. This access rule honors organization hierarchies. That is, if Org1 is a parent to Org2, then a user logged into Org2 and CollabSpace1 can also access public content in Org1. If Org1 is not an ancestor of Org2, then the user cannot access the public content in Org1.

For security reasons (for example, when a supplier is working on an OEM site), you might not want to share all public content of the enterprise with collaborative space members. You can deactivate this access rule to restrict public visibility of content across collaborative spaces.

If this access rule is deactivated, that user cannot access public content in any other collaborative space (for which the user has no credentials), regardless of the organization that owns it. The user can only access content in the collaborative space of the current login session and those of their passive credentials.

How Access Is Determined

This access rule works in combination with the Allow users read-access to any content in any other collaborative space rule (activated by default).

The examples in this section show a user with these sets of credentials:

  • Author.Org1.CollabSpace1
  • Author.Org3.CollabSpace3

The user chooses a set of credentials at login. That set of credentials becomes the active credentials (Author.Org1.CollabSpace1 for this example).

The example content in the examples are owned by these organizations and collaborative spaces:

  • Org1.CollabSpace1
  • Org1.CollabSpace2
  • Org2.CollabSpace1
  • Org2.CollabSpace2
  • Org3.CollabSpace3
  • Org3.CollabSpace4
  • Org4.CollabSpace3
  • Org4.CollabSpace4

The examples describe what content the user can access depending on the combination of these access rules.

You can keep the default settings for both access rules:

  • Allow Read-access to Any Public Content is activated
  • Allow users read-access to any content in any other collaborative space is activated

When the user logs in with Author.Org1.CollabSpace1, the user can access any (that is, public or private) content in CollabSpace1 regardless of the owning organization. That user can also access public content in any other collaborative space (CollabSpace2) owned by Org1 and owned by Org2 (when Org2 is a parent organization of Org1).

The passive credentials Author.Org3.CollabSpace3 also provides access to any (that is, public or private) content in CollabSpace3 regardless of the owning organization. It behaves like the active credentials Author.Org1.CollabSpace1.

You can deactivate this access rule:

  • Allow Read-access to Any Public Content is deactivated
  • Allow users read-access to any content in any other collaborative space is activated

If the user logs in with Author.Org1.CollabSpace1, the active and passive credentials still provide access to any (that is, public or private) content in CollabSpace1 and CollabSpace3 regardless of the owning organization. The user cannot access public content in other collaborative spaces, even if the content is owned by the same organization.

You can deactivate the collaborative space access rule:

  • Allow Read-access to Any Public Content is activated
  • Allow users read-access to any content in any other collaborative space is deactivated

If the user logs in with Author.Org1.CollabSpace1, the user can access public and private content owned by CollabSpace1 regardless of the owning organization. That user can also access public content in any other collaborative space (for example, CollabSpace2) owned by Org1 and owned by Org2 (when Org2 is a parent organization of Org1). The passive credentials Author.Org3.CollabSpace3 only provides access to public content in any other collaborative space (for example, CollabSpace4) owned by Org3 and owned by Org4 (when Org4 is a parent organization of Org3).

You can deactivate both access rules:

  • Allow Read-access to Any Public Content is deactivated
  • Allow users read-access to any content in any other collaborative space is deactivated

If the user logs with Author.Org1.CollabSpace1, the user can access public and private content owned by CollabSpace1 regardless of the owning organization. That user cannot access public content in any other collaborative space (different from those of his credentials, for example CollabSpace2 and CollabSpace3). The user's passive credentials Author.Org3.CollabSpace3 allows that user to access public content owned by Org3.CollabSpace3 and Org4.CollabSpace3 (when Org4 is a parent organization of Org3).

Granting Access to Specific Users

Although you might not want all users from an organization to access public content in a specific collaboration space, you might want to give selected users that access. The Administrator can grant access (search/open) to public content owned by another collaborative space AND organization.

To grant access to an external user, the Administrator edits the user to add them to the collaborative space using the Public Reader role. For reference, the platform stores the credentials as VPLMSecuredCrossAccess.<ORG_NAME>.<COLLABORATIVE_SPACE_NAME>.

The user can log in using any set of credentials (role, organization, collaborative space), and does not need to switch to the Public Reader role. The logged in credentials is referred to as the active context. The user inherits all rights from all assigned credentials. Any other credentials assigned to a user are referred to as passive contexts.

If a public content structure crosses different collaborative spaces, the user must be explicitly assigned to all sets of credentials to see the overall content structure.