You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The viewpoint pattern provides the ability to manage an individual status of a shared object for multiple independent actors.
7
5
8
-
## Problem
9
-
10
-
Often in an organizational context a group of people receives a common messages but different users act on this messages at a different point of time.So that if user1 read and deleted the message, for user2 this is still unread. usually it happens when a shared item is presented in an individual context.
6
+
*The viewpoint pattern provides the ability to manage an individual status of a shared object for multiple independent actors.*
11
7
8
+
## Problem
9
+
A shared resource, such as a website or a group message, may have different states for different users who access it at different times in an organizational context. For example, user1 may read and delete a message, while user2 may not have seen it yet. This usually happens when a shared item is presented in an individual context.
12
10
## Solution
13
11
14
-
*Describe how to implement the solution to solve the problem.*
12
+
The viewpoint pattern provides a solution to how to model an individual user context on a shared resource using a `viewpoint` structural property on an API entity type.
13
+
For example, the `viewpoint` property can indicate whether a message is read, deleted, or flagged for a given user.
14
+
The consistent naming convention ensures that when a developer uses Graph APIs all ‘viewpoints’ structural properties represent type specific user context across different M365 services and features.
15
15
16
-
Represents user view points data for a serviceUpdateMessage.
17
-
Represents user viewpoints data of the service message. This data includes message status such as whether the user has archived, read, or marked the message as favorite. This property is null when accessed with application permissions.
This pattern simplifies the API client logic by hiding the state transition details and providing state persistency on the server side. The server can manage the different viewpoints for the shared resource without exposing them to the client. You should also make this property filterable.
17
+
## Issues and considerations
21
18
22
-
*Describe when and why the solution is applicable and when it might not be.*
- Because the `viewpoint` property reflects an individual user's context, it is null when accessed with application permissions.
20
+
- Sometimes, the viewpoint can be computed on the server. In this case, an API producer should add OData annotations to the property to provide more information for downstream tools, such as SDKs and documentation generation.
- An alternative to this design would be to store the user state on the client side. However, this may be problematic in some cases, because of the many devices that a user may have and the need to synchronize the state across them.
The following example demonstrates how to define the 'viewpoint' property for the `chat` entity, where a chat is a collection of chatMessages between one or more participants:
"lastMessagePreview": null, // No message was sent in this group chat yet
81
+
"chatType": "group",
99
82
"viewpoint":{
100
83
"lastMessageReadDateTime": "0000-01-01T00:00:00.000Z" // User hasnt read anything since no message was posted
101
84
}
102
85
}
103
86
]
104
87
}
105
-
```
88
+
```
89
+
### Updating a viewpoint
90
+
91
+
You can update the `viewpoint` property only if the server does not compute it automatically. Updating the `viewpoint` property usually has a side effect, so you should use an OData action to perform the update.
92
+
93
+
The following example shows marking a chat as read for a user:
94
+
95
+
```http
96
+
97
+
POST https://graph.microsoft.com/beta/chats/19:7d898072-792c-4006-bb10-5ca9f2590649_8ea0e38b-efb3-4757-924a-5f94061cf8c2@unq.gbl.spaces/markChatReadForUser
0 commit comments