Projects:Cross Organization Reference/Specs
Contents |
Functional Requirements
Use case
Assuming the following subtree for Organizations, where P is the parent organization of A and B which are sister organizations:
An order is created in Organization A to be later paid in Organization B.
Data hierarchy
The data should be structured according with next simplified tree, where organizations of each element is in brackets:
Visualization
 | No change in visualization is going to be done in the scope of this project. |
This information can be visualized in two different windows:
- Sales Order. A row in Payment Plan tab is created when the Order is processed, when it is actually payed rows are created in Payment Details.
- Payment In. It only has information once the payment has been done. It does not shown Payment Plan. Displays Payment as header and Payment Details as lines.
Assuming these different roles:
- Ra: with access to Organization A
- Rb: with access to Organization B
- Rab: with access to both Organizations
| Window/Role | Ra | Rb | Rab |
|---|---|---|---|
| Order | Partial data is shown. Payment Details part cannot be seen because it is in organization B. | No data should be visible as Order header is in A | All data should be visible |
| Payment | No info is shown as Payment is in B | All data is visible, though it would not be possible to navigate to Order window | All data is visible and navigable |
Current status
Data hierarchy
Currently it is not possible to define the tree defined above. Relationships between elements are always enforced to ensure referred object organization is in the natural tree of the one referring. The relationship Payment Plan [A] <- Payment Details [B], does not fulfill this rule (A is not in B’s natural tree), therefore it is not allowed.
Workaround
According to current restrictions, the following tree, where Payment Details are in Organization P that is in B’s natural tree would be allowed.
Though this workaround would work in terms of data structure, it can have other functional impacts that are not desired (ie. accounting for the Payment Details would be done in Organization P, but it should be in B).
Technical Specs
Column allowing cross org references
Not all columns will allow cross organization references, this will be rare cases that will be explicitly marked in Application Dictionary model. A new flag in AD_Column (allow cross org references) will be added to serve this purpose.
If a column that is a FK to another entity is marked with this fag, it will be allowed to reference rows in a different natural organization tree than the row it belongs to.
Cross organization reference admin mode
Even if a column is marked to allow cross organization references, it will only be possible to create a cross organization link programmatically (note UI is not planned to be changed to allow it) and to do it it will be necessary to set the context to a new kind of admin mode: OBContext.setCrossOrgReferenceAdminMode().
Retrieving DAL objects with cross org references
Currently there is not any enforcement to prevent retrieving linked elements that are in a non-accessible organization for the current role by navigating the links. This applies both for navigation one-to-many and many-to-one.
In order not to break current API, the same behavior will be preserved.
Known Issues
- Allowing cross organization references from the Platform point of view, does not warranty the processes dealing with those objects will properly handle the cases of actual cross organization links.
- Due to issue 32063 cross organization references are not currently checked by DAL on insertion.