Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 1 addition & 32 deletions _docs_integrate/data-model-overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ The enmeshed data model can be divided into three parts:

The following diagram gives you an overview of all the existing types and how they are connected to each other. The subsequent chapters describe these types in more detail.

<div style="width: 100%; height: 480px; margin: 10px; position: relative;"><iframe allowfullscreen frameborder="0" style="width:100%; height:480px" src="https://lucid.app/documents/embedded/f7c98621-98a7-4e31-8c54-c2974031029e" id="uPhuT48AMcNp"></iframe></div>
<div style="width: 640px; height: 480px; margin: 10px; position: relative;"><iframe allowfullscreen frameborder="0" style="width:640px; height:480px" src="https://lucid.app/documents/embedded/f32afee5-014a-4cfb-9a9f-91c974b77d9a" id="ksXuAN~ZRo~g"></iframe></div>
(note that you can click on each type in order to navigate to the paragraph with the corresponding description)

At a first glance the amount of types is overwhelming. But in the following chapters all of them are explained in detail.
Expand Down Expand Up @@ -434,16 +434,6 @@ This will be the case, if the peer already accepted the DeleteAttributeRequestIt
| deletionStatus | `"DeletionRequestSent"` \| `"DeletionRequestRejected"` \| `"ToBeDeleted"` \| `"ToBeDeletedByPeer"` \| `"DeletedByOwner"` \| `"DeletedByPeer"` | The deletion status of the peer's counterpart of the shared Attribute. For own shared Attributes it may only be set to `"DeletionRequestSent"`, `"DeletionRequestRejected"`, `"ToBeDeletedByPeer"` or `"DeletedByPeer"`, whereas for peer shared Attributes only the values `"ToBeDeleted"` and `"DeletedByOwner"` are allowed. |
| deletionDate | `string` | The point in time<br>{::nomarkdown}<ul><li>the Request with a DeleteAttributeRequestItem was sent (for <code>"DeletionRequestSent"</code>).</li><li>the Response with a RejectResponseItem was received (for <code>"DeletionRequestRejected"</code>).</li><li>an upcoming deletion is planned (for <code>"ToBeDeleted"</code> or <code>"ToBeDeletedByPeer"</code>).</li><li>a completed deletion has been notified (for <code>"DeletedByOwner"</code> or <code>"DeletedByPeer"</code>).</li></ul>{:/} |

## LocalAttributeListener

A LocalAttributeListener is created when you accept an incoming Request with a [`RegisterAttributeListenerRequestItem`](#registerattributelistenerrequestitem). It is used to keep track of which Attribute Listeners currently exist and what they are listening for.

| Name | Type | Description |
| ----- | -------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| id | `string` | {% include descr_id class="LocalAttributeListener" prefix="ATL" %} |
| query | [`IdentityAttributeQuery`](#identityattributequery) \| [`ThirdPartyRelationshipAttributeQuery`](#thirdpartyrelationshipattributequery) | The query the Attribute that is listened to must match. Note that you cannot send a [`RelationshipAttributeQuery`](#relationshipattributequery) here, because it doesn't make sense: by definition, both parties know about a RelationshipAttribute right from the beginning, because one party requests its creation, and the other one accepts it. |
| peer | `string` | The address of the peer that requested the Attribute Listener. |

## AttributeTagCollection

The AttributeTagCollection is defined by the Backbone and specifies which `tags` are allowed for which [IdentityAttribute]({% link _docs_integrate/data-model-overview.md %}#identityattribute) `value.@type`.
Expand Down Expand Up @@ -657,19 +647,6 @@ For more information you should check out the section [ReadAttributeRequestItem
| mustBeAccepted | `boolean` | The mandatory `mustBeAccepted` property is used to differentiate between required and optional RequestItems within the Request.<br>{::nomarkdown}<ul><li>If <code>mustBeAccepted</code> is set to <code>true</code>, the peer cannot <a href="https://enmeshed.eu/use-case-consumption-accept-incoming-request">accept the Request</a> without accepting this RequestItem.</li><li>If <code>mustBeAccepted</code> is set to <code>false</code>, the peer can <a href="https://enmeshed.eu/use-case-consumption-accept-incoming-request">accept the Request</a> even though the RequestItem is rejected.</ul>{:/} |
| requireManualDecision | `boolean` \| `undefined` | To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step, the requireManualDecision property can be set to true. |

#### RegisterAttributeListenerRequestItem

For more information you should check out the section [RegisterAttributeListenerRequestItem of the Request and Response introduction]({% link _docs_integrate/request-and-response-introduction.md %}#registerattributelistenerrequestitem).

| Name | Type | Description |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| @type | `"RegisterAttributeListenerRequestItem"` | Specifies the type of the RequestItem for internal processing. |
| query | [`IdentityAttributeQuery`]({% link _docs_integrate/data-model-overview.md %}#identityattributequery) \| [`ThirdPartyRelationshipAttributeQuery`]({% link _docs_integrate/data-model-overview.md %}#thirdpartyrelationshipattributequery) | The structured query of the Attribute the sender would like to query. |
| description | `string` \| `undefined` | An optional, human readable description for the RequestItem. |
| metadata | `object` \| `undefined` | The metadata property can be used to provide arbitrary JSON content by the sender of the Request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the Request which helps you identify the correct internal process at the time of receiving the Response. |
| mustBeAccepted | `boolean` | The mandatory `mustBeAccepted` property is used to differentiate between required and optional RequestItems within the Request.<br>{::nomarkdown}<ul><li>If <code>mustBeAccepted</code> is set to <code>true</code>, the peer cannot <a href="https://enmeshed.eu/use-case-consumption-accept-incoming-request">accept the Request</a> without accepting this RequestItem.</li><li>If <code>mustBeAccepted</code> is set to <code>false</code>, the peer can <a href="https://enmeshed.eu/use-case-consumption-accept-incoming-request">accept the Request</a> even though the RequestItem is rejected.</ul>{:/} |
| requireManualDecision | `boolean` \| `undefined` | To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step, the requireManualDecision property can be set to true. |

#### ShareAttributeRequestItem

For more information you should check out the section [ShareAttributeRequestItem of the Request and Response introduction]({% link _docs_integrate/request-and-response-introduction.md %}#shareattributerequestitem). Furthermore, all details on how to use the ShareAttributeRequestItem and examples of use cases for it can be found in the [Share Attributes with peer]({% link _docs_integrate/share-attributes-with-peer.md %}) guide.
Expand Down Expand Up @@ -807,14 +784,6 @@ Receiving an AttributeSuccessionAcceptResponseItem, the respective shared LocalA
| attribute | [`IdentityAttribute`]({% link _docs_integrate/data-model-overview.md %}#identityattribute) \| [`RelationshipAttribute`]({% link _docs_integrate/data-model-overview.md %}#relationshipattribute) | The IdentityAttribute or RelationshipAttribute that will be shared with the peer. |
| thirdPartyAddress | `string` \| `undefined` | If the Attribute to be shared is an already existing [RelationshipAttribute](#relationshipattribute) of another [Relationship](#relationship), this property must contain the address of the `peer` with whom the sender of the Attribute has the Relationship in which context the RelationshipAttribute exists. |

##### RegisterAttributeListenerAcceptResponseItem

| Name | Type | Description |
| ---------- | ----------------------------------------------- | -------------------------------------------------------- |
| @type | `"RegisterAttributeListenerAcceptResponseItem"` | The type of the ResponseItem. |
| result | `"Accepted"` | The only possible value here is the string `"Accepted"`. |
| listenerId | `string` | The id of the created AttributeListener. |

##### ShareAttributeAcceptResponseItem

| Name | Type | Description |
Expand Down
1 change: 1 addition & 0 deletions _docs_integrate/migration-from-v6-to-v7.md
Original file line number Diff line number Diff line change
Expand Up @@ -54,6 +54,7 @@ The step-by-step instructions can be consulted to start the migration to version
The property `reference` was introduced to group the property `truncated` with the additional property `url`, improving structure and better organizing related data.
- The `title` property of the [File]({% link _docs_integrate/data-model-overview.md %}#file) became optional and should no longer be relied upon to be set.
- The `ownershipToken` property of the [TransferFileOwnershipRequestItem]({% link _docs_integrate/data-model-overview.md %}#transferfileownershiprequestitem) became mandatory. This ensures that the ownership of the original File on the Backbone is transferred instead of applying a copy-based workaround. If the ownership of a [File]({% link _docs_integrate/data-model-overview.md %}#file) ought to be transferred, that doesn't have an `ownershipToken` yet, it will need to be [regenerated]({% link _docs_use-cases/use-case-transport-regenerate-file-ownership-token.md %}).
- All data structures around the Attribute listener feature were removed (`LocalAttributeListener`, `RegisterAttributeListenerRequestItem`, `RegisterAttributeListenerAcceptResponseItem`).

### Changed Behavior of Known Features

Expand Down
Loading