I am ideally looking for an API that returns all the messages posted(including replies) since a given timestamp.
conversations.history is supposed to be the one I should be using, but it does not return replies, it only returns parent message (only if the timestamp of the parent message satisfies the "oldest" param I supply - i.e. if the oldest supplied in the query is later than parent's ts but earlier than replies, neither parent nor replies will be returned).
Hence, I am trying to find if there is any other API that returns the threads based on "oldest" timestamp. i.e. all the threads which have replies since a given timestamp.
Note: I looked at conversations.replies, it is only useful if you know which thread's replies you are fetching.
Currently there is no API to do what you aspire to do.
The best work around is manually fetching all threads data in-memory and then applying filter.
Did you find an alternative solution to this question? I have the same use case and when contacting Slack support I received the same response that we need to use the combination of conversations.history & conversations.replies. This will be quite an intensive and continuously growing number of calls if we need to call conversations.replies for all threaded messages just to filter out the timestamps that fit the date range. This would be catastrophic in the long run.
Ideally slack need to update conversations.replies API to support getting all replies between oldest & latest parameter just like in history.
Another alternative I am considering is to change the implementation and use the Events API instead of the Web Client API and use queueing to store all incoming messages then this will make sure that all messages are captured and stored then apply the required filters.
Related
I am trying to put together analytics on Microsoft teams calls. I would like to get hold times, number of transfers, call time, etc. I came across this call https://graph.microsoft.com/beta/communications/callRecords and it gives me a list of calls with call times, but I can't find a way to get hold times, what line it came in on, etc. Greatly appreciate any pointers.
First of all, this end point https://graph.microsoft.com/beta/communications/callRecords only allows you to query a single call record using its ID, it does not support querying a list of call records for the whole tenant or for a specific user.
The only way currently to find this ID to query the call record is by setting up a web hook to receive change notifications. Refer to the following documentation for more info on change notifications.
To directly address your question, i am not one hundred percent sure but i believe the information you're looking for could be found inside the list of sessions and segments inside a call record.
I am migrating from EWS to Microsoft graph and having problem in replacing flow "ExchangeService.syncFolderItems".
ChangeCollection<ItemChange> changedItems = exchangeService.syncFolderItems(calendarFolder.getId(),
FirstClassProperties, null, 512, NormalItems, syncState);
This gives me all the changes since last sync state with change type.
Now I need to replace this with Microsoft graph.
I saw Get delta api in Microsoft graph and also how to call it recursively using stale token. My query is, Get delta api is not returning the change Item type. Could someone suggest me the best way to implement this in Microsoft graph? Maybe the Apis that I need to use for this?
Note:This flow will be called by my service to get changes after fixed interval of time. Also I saw subscriptions ( https://learn.microsoft.com/en-us/graph/api/resources/subscription?view=graph-rest-1.0 )but not sure that could be used in my case as my service will be making a call to get changes for a meeting room after a fixed scheduled interval of time.
I am stuck here. Please help. Thanks in advance.
Deleted events will have a #removed property and only provide the id of the object as denoted here https://learn.microsoft.com/en-us/graph/delta-query-overview#resource-representation-in-the-delta-query-response
Updated objects will only include the updated properties and added objects should include all the data available. It's up to the 3rd party application (your app) to maintain a state on it's side to be able to differentiate between updated and created objects when using Delta queries.
Combining webhooks with Delta to trigger the sync instead of relying on a timer is a good approach to provide an end user experience that feels more real time
Until now we used a SharePoint on-premise custom web service which delivered all users (approx 15,000) inclusive properties like aboutMe, skills, etc. and the direct manager. That job took approx. 15 minutes.
All the data was stored in a Lucene search index.
Now we have to switch to O365.
I am able to get all the desired information from Microsoft Graph but it would take way too long (3 - 5 hours):
Fetch all users via /v1.0/users (with paging)
Iterate through the collection and
get manager for given user via /v1.0/[user-id]/manager
get properties like aboutMe, skills for given User via /v1.0/[user-Id]?$select=aboutMe,skills
Is there any efficient way to do that task?
Ideally, you should just call Microsoft Graph for the data you want on-demand rather than attempting to sync it to your own database.
Assuming you can't do that, you can deduce the time this takes using /delta endpoint (Get incremental changes for users). When you use a delta token, you will only get back resources that have changed (adds, deletes, edits) since your previous request. So your first pass might take a few hours, but subsequent passes should take seconds.
You can control which properties you're "tracking changes" against using the $select query parameter. For example, if you only care about changes to the displayName then using /v1.0/users/delta?$select=displayName will ensure you only receive changes to that property. From the documentation:
If a $select query parameter is used, the parameter indicates that the client prefers to only track changes on the properties or relationships specified in the $select statement. If a change occurs to a property that is not selected, the resource for which that property changed does not appear in the delta response after a subsequent request.
Also, consider batching requests to improve your processes' overall performance. Batching allows you to send multiple queries to Microsoft Graph in a single request and get the complete results back in a single response.
Is there a way to get ALL the responses for a single day in one transaction for a specific survey? on the API doc, I know there is the /surveys/{id}/responses/bulk option, and even I can send the start_created_at variable.
But I think that the API response has a max number of records/data it can send, it that case, what could the solution be? Paging through the results?
I'm using the .net API, found at this site, but I can build my own wrapper if necessary.
Reference link to API doc: /Surveys/SURVEY_ID/responses/bulk
Yes you're right the /surveys/{id}/responses/bulk endpoint is what you're looking for, and you can use the start_created_at and end_created_at to filter data to a date range.
The SurveyMonkey API doesn't allow a full dump of all your data, it will always be paginated. By default it'll paginate 50 at a time, but you can change that by using the per_page GET parameter.
That max per_page varies by endpoint, for responses BULK it is 100. So you'll have to fetch 100 at a time, looping through the pages to get all your data.
One alternative is to use webhooks and set up a subscriber, that way you can get new responses in real time and fetch them one by one. That way you can keep your data updated on your side as new responses come in, rather than running a script or endpoint to bulk dump all your data. But this depends on your use case, if you're building something like an export feature, then you'll have to go through the paginated route.
Looking at Mailcore docs, I see a method to retrieve the sequence number of an email or emails by executing a fetch using the email UID. However, when looking at the Mailcore2 docs, I don't see any way to accomplish this. Is there a method for this in Mailcore2 that I am somehow not seeing, or a way to bubble up this information? I know it is possible in the command line, but I'd like to be able access it from inside my iOS app.
EDIT:
Here is why I am looking for this functionality:
We have a native iOS client that fetches the 10 newest emails at a time and saves them. Additionally, the client will fetch the next 10 older emails at a time and save them, as well as the lowest UID it has seen (minUID).
So we need to be able to continually fetch the next 10 older emails that exist on the server that the client has not yet stored or seen. (Therein lies the challenge).
Initially, we did this by fetching emails by UID in groups of 10, using our saved minUID minus 1 as the starting point for each fetch, and updating our minUID at the end of each fetch. However, as UIDs are not necessarily contiguous, the number of emails that was returned was inconsistent, and sometimes zero. To solve this problem, we thought it would be helpful to (before each fetch for the next 10 older emails), fetch the email with our stored minUID, check its current sequence number, and then fetch the next 10 older emails based on that sequence number.
To fetch messages based on a sequence number, you can use the following function syncMessagesWithFolder:folderName:requestKind:uids:modSeq:
The below example will fetch you all the new/modified messages for the folder folder above sequence number highestModSeq.
MCOIMAPFetchMessagesOperation * op = [self.imapSession syncMessagesWithFolder:folderName
requestKind:requestKind
uids:[MCOIndexSet indexSetWithRange:MCORangeMake(1, UINT64_MAX)]
modSeq:highestModSeq];
The documentation is not exactly the best place to find examples, but our wiki is increasingly becoming an excellent repository for that kind of information. What you're looking for is -[MCOIMAPSession fetchMessagesByUIDOperationWithFolder:requestKind:uids:], an example of which can be found under the IMAP examples wiki page.