About Co-Review

The following tables summarize the different combinations of applications and connectors for which Co-Review is supported. Co-Review works only if both of the below conditions are satisfied.

Condition 1: Between Connectors

	Inviter: Any Connector (Except 3DXML)	Inviter: 3DXML Connector
Invitee: Same Connector	OK	---
Invitee: Different Connector	NA	NA
Invitee: 3D XML Connector	NA*	OK*

Condition 2: Between Applications

	Inviter: Navigation	Inviter: Examine	Inviter: CATIA
Invitee:	Navigate	Examine	NA
Invitee:	NA	Examine*	Examine*
Invitee: CATIA	Navigate	NA	Edit

* The Co-Review occurs in the invitee's current tab.

NA Not Applicable, the function is not supported.

Important: Co- Review with 3DXML-connector is possible when the Inviter and Invitee are connected with same 3DXML file locally saved on their machine.

The following functionality is available in a Co-Review:

• Baseline Capabilities
  • Viewpoint sharing
  • Selection in the tree or 3D
  • Redlining
  • Snapshot
  • Share mouse pointer
  • Unload
• Dedicated Capabilities per App
  • Product Finder: navigate, filter
  • Design Review: slides, measure, section
  • Natural Shape: design

Important: Any newly created 3DPart or object must first be saved to the database before it can be used in a Co-Review. Co-Review is an asynchronous process. It is possible for some events to be visible on the Observer's side before they are visible on the Leader's side. Each quadrant of the Compass can contain add-on categories that come with installed applications or with local customizations. If the Co-Review Leader chooses one of these add-on categories but the Observer does not have the associated application installed in his/her environment, then a warning message will indicate to the Observer that the application is not available. When modifications are performed during a Co-Review session in Live Validation, Live Compose or Live Shape, only the Leader should respond "YES" to a Propagate/Save operation. All Observers should respond "NO" to the Save/No/Cancel message that appears when changing from those apps to Explore.

It is now possible to share Filters in a Co-Review.

• Supported filter types are:
  • Attributes filter
  • Volume filter
  • Configuration filter (note: configuration handlers are not supported for 3D XML)
• The filter defined by the leader is visible in the 3D and tree views for all attendees.
• If a filter is applied by the leader before starting the Co-Review, when the co-review is started, the filter is sent and is reflected in the sessions of all attendees.
• Deactivated nodes in the filter panel are not shared between the leader and the attendees.
• During co-review, People and Organization criteria are taken in account. If an attendee does not have the rights to see certain content, that content will not be visible to that attendee.
• If the leader and an attendee have different index options on their machine, when the leader applies a volume filter, the results will not be consistent in the attendee session.

Snapshot sharing is now controlled by the corresponding User Information attribute (managed by your People and Organization administrator). If for a given user, the Sharing Snapshots attribute is "Denied", then he/she cannot share snapshots and a default snapshot (indicating that snapshot sharing has been denied) will be sent instead.

When you are working in the baseline behavior, only the following Business Roles are enabled to share snapshots:

• Experimenter
• Creator
• ProjectLeader
• ProjectAdministrator

Command availability is now managed to maintain greater coherence and clarity of actions that can be performed during a co-review by the leader and the observers.

• Commands that have implemented a collaborative behavior will only be available on the Leader side.
• Commands that have not implemented a collaborative behavior and impact Co-Review will be grayed out on both sides.
• Commands that do not impact Co-Review will be available on both sides, e.g. Help.
• If the Leader changes, the set of available commands will change for the new Leader.

In a Co-Review, tab management and content sharing must be clear and coherent. Whenever possible, the actions new/open/switch/close tab on the leader side are symmetrically reflected on the observer side. When not possible, an appropriate feedback is displayed if the observer couldn’t for any reason follow the leader’s tab actions.

Definitions

• The leader is in a Private Space when an observer cannot follow the leader tab switch. This status is specific to each observer (if you are working in N-way mode), as the ability to follow a switch is dependent on the local configuration and each observer can have a different local configuration.
• A Collaborative Window is a tab that can be successfully opened on the observer side following leader action and in which collaborative commands executed by the leader are successfully reflected in the observer's tab.
• Collaborative Commands are commands that when executed by the leader, are simultaneously reflected on the observer side.

Leader tab switch

• When the leader switches from a current collaborative tab to a collaborative tab created in the scope of the Co-Review session, the observer follows.

• If the tab switch on leader side is made on an command which is not collaborative, on the observer side the leader will be indicated as being in a private space.

Observer tab switch

• For the observer, any tab switch is blocked whether he/she is in a collaborative or non collaborative tab. A warning message at the top-right corner indicates that the action requires the observer to either leave the Co-Review or request the Co-Review lead.
• For the observer, any attempt to close a (collaborative) tab is blocked. A warning message at the top-right corner indicates that the action requires the observer to either leave the Co-Review or request the Co-Review lead.

Leader tab close

• When the leader closes a collaborative tab in the scope of the Co-Review session, the corresponding tab on the observer side is also closed.

Limitations

• Window position, size and layout are not collaborative.

• When the leader is seen as being in a private space, all messages (send modifications) from the leader continue to be sent to the observer side, but content modifications might not be seen depending on observer configuration: current tab, editor, product availability, app/command limitations.

• Until versioning capacity will be added in communication and stream protocols used to transit information from the leader to observers, collaboration will work only for users with the same application level (same release number, same service pack, same hotfix set installed on both leader and observer side).
• In the case where a tab switch is requested by the application (for example open a new content, activate an entity, close an inappropriate editor) then the application will first try to perform the action, then try to block it. Since the order of these actions is not fixed but based on events, a flick effect (a tab appears and disappears quickly) could happen when the switch is a context action.
• Only the current Co-Review leader should save modifications, other participants should exit without saving Window switch while opening a Live Shape content is not supported