I am looking to use the Exchange API for conversations and feeling confused between the difference between conversations and threads. There is no documentation available around the same. Can someone please help to explain the difference?
You need to be familiar with Outlook entities to understand these terms better.
Conversations
The Conversation object is an abstract, aggregated object. Although a conversation can include items of different types, the Conversation object does not correspond to a particular underlying MAPI IMessage object.
A conversation represents one or more items in one or more folders and stores. If you move an item in a conversation to the Deleted Items folder and subsequently enumerate the conversation by using the GetChildren, GetRootItems, or GetTable method, the item will not be included in the returned object.
To obtain a Conversation object for an existing conversation, use the GetConversation method of the item.
Threads and Conversations are interchangeable. Sometimes in the UI may see a column named as threads. But from the developer point of view, it is still a conversation. Posts are items in the conversation.
Related
The use case:
We are creating a system which analyses mail content. If we are able to categorize and archive an email based on its content, we want to automatically categorize subsequent emails in the same conversation / thread.
The issue is that the conversationId we get as part of the (mail)message is not unique when we query on behalf of different users.
An example:
A: The conversationId for a given thread in my inbox.
B: The conversationId for the same thread, but in a different user's inbox.
Values:
A:AAQkADUyZWYxNzljLTc4NjItNGMzYy1iZDYwLTE4NWEzNDg1OWUzZQAQABlanHOPI0v1ukA7KePaYv4=.
B:AAQkAGVkNGRjNWNmLTAwNTItNDA2NC1hOThhLTU5NTUyNGFjNTM5ZAAQABlanHOPI0v1ukA7KePaYv4=.
Can I use parts of this conversationId to identify the same conversation across different users? The pattern seems to be that the last 25-26 characters are unique for the given conversation. The rest is a Guid + a postfix of some sort.
Edit: My question is related to usage of the Microsoft Graph API. There are questions answered on SO related to ConversationIds and Outlook emails, but these describe cases getting emails direct from the outlook client (or maybe through the outlook api). For instance are properties like the ConversationIndex and ConversationTopic not in the message I get from the Graph API.
I am developing using the Microsoft Mail Graph API I'd like to provide conversation actions.
For example, if a conversation has several unread messages, marking as read the last one doesn't mark the whole conversation as read (like I'd want).
I didn't see any conversation-level API to mark as read / mark as unread or delete whole conversations.
What would be the best way to achieve conversation updates?
Thanks!
I'm afraid there are not APIs specific to email conversations. In order to process a batch of emails within a conversation, you'll need to update each message individually.
You can determine which messages belong in the conversation using the conversationId. Keep in mind however that a "conversation" is a somewhat loosely defined entity. Exchange generally gets good results but it isn't foolproof by a long shot (for example, a conversation with 10 participants, forward it to an 11th and you often end up with two threads in a single "conversation").
I would suggest using JSON batching for something like this. Batching allows you to bundle multiple Graph commands into a single call. Using batching you could update up to 20 messages at a time.
Writing a slack bot and I would like to be able to get a list of all the channels my bot is a member of. One way to do this is to call https://slack.com/api/channels.list, get a (potentially large) list of all channels and then search for the channels that the current (bot) user is a member of. This works fine, but seems very heavy handed.
Is there a better way? To get just the channels that a given user is a member of?
I think users.conversations is what you're looking for. Without additional params it will return all public channels the calling user is a member of.
No, there is no shorter way to get this information.
Actually, Slack recommends to use the new conversations methods for this task, since the members property in all other methods, e.g. channels.list has recently been changed to only return a truncated user list. See here for details.
With conversations you have to make an additional call per channel to get all channels a user is a member of. However it will work with all types of channels (e.g. public channels, private channels) at the same time.
The basic approach is:
Get the list of all conversations from conversations.list
Get the list of members per conversation form conversations.members.
So if you want your Slack app to be future proof and also work with large number of users better use the conversations methods for your task.
FYI you can now list user channels/conversations using:
https://api.slack.com/methods/users.conversations
I would like to use the Outlook REST API to display the messages in a mail folder and group messages by conversations, like you have in any modern webmail.
For example with inbox, I would request using a first query such as <mailuri>/inbox/messages?$select=ConversationId (by default it is reverse chronological order)
It is not sufficient to group this request results by ConversationId because some emails may not be in inbox (think of sentmails) or they may be paginated and not returned in the first page.
Consequently, for each distinct ConversationId I need to perform another REST request, for retrieving participants or simply counting the emails in the conversation. I may use the new batch request to do this.
There are a lot of requests involved. Is there a better solution ?
As you've probably realized the REST API doesn't directly provide a way to work with conversations as an entity. This is something that we have on our roadmap to improve.
With the current state of the API what you're describing is basically the right approach. You could possibly defer the second request to "fill in" a conversation until the user selects it.
You can actually use this endpoint to cover both inbox and sentitems
https://outlook.office.com/api/v2.0/me/messages/?$select=ConversationId & $filter=ConversationId eq '${params.conversationId}'
I have a message model and I want it to have several receivers, possibly a lot of them.
I would also like to be able to tell for each receiver if the message was viewed or not (read/unread). Also I would like a receiver to be able to delete the message.
The two possible solutions are the following, for each I have a Message model an User model.
For the first (using the ideas presented here http://www.google.com/events/io/2009/sessions/BuildingScalableComplexApps.html)
I have a MessageReceivers class which has a ListProperty containing the users that will receive the message and set the parent to the message. I query of this with messages = db.GqlQuery('SELECT __key__ FROM MessageReceivers WHERE receivers = :1', user) and the do a db.get([ key.parent() for key in messages ]).
The problem I have which this is that I'm not sure how to store the state of the message: whether it is read or not and a subsequent issue whether the user has new messages. An additional issue would be the overhead of deleting a message (would have to remove user from receivers list property)
For the second: I have a MessageReceiver for each receiver it has links to message and to user and also stores the state (read/unread).
Which of this two approached do you consider that it has a better performance? And in the case of the first do you have any suggestion on handling the status of the message.
I've implement first option in production. Drawback is that ListProperty is limited to 2500 entries if you use custom index. Shameless plug: See my blog bost http://bravenewmethod.wordpress.com/2011/03/23/developing-on-google-app-engine-for-production/
Read state storing. I did this by implementing an entity that stored unread messages up to few months back and then just assumed older ones read. Even simpler is to query the messages in date order, and store the last known message timestamp in entity and assume all older as read. I don't recommended keeping long history in entity with huge list property, because reading and storing such entities can get really slow.
Message deletion is expensive, no way around that.
If you need to store state per message, your best option is to write one entity per recipient, with read state (and anything else, such as flags, etcetera), rather than using the index relation pattern.