I want to download mails that matches the in-place eDiscovery. I do a GetDiscoverySearchConfiguration(), then I execute SearchMailboxes() for each mailbox that GetDiscoverySearchConfiguration() returns. SearchMailboxes() returns SearchPreviewItems() where I can get the real EmailMessage Id but this does not have the email body, so I have to do another retrieve using FindItems() to get the EmailMessage object.
This is a very slow process, are there any other way to do this?
I would like to get all the mails that I can see in the
preview
Instead of FindItems(), use the ExchangeService.BindToItems() method and provide a collection of the message ids you want in batches. Restrict the property set to only the properties you need. A couple of other thoughts:
- Limit the preview response shape to just the item identifiers since you'll call BindToItems for the properties you need.
- FindItems will only return the first 512 characters of the body.
- Use paging with SearchMailboxes(). Optimal page size will depend on the property set. You'd have to test different page sizes to optimize.
Related
Is there a way to get the members to a certain response of poll without the need to create segments?
I am sending mails and have a poll included (basically participating at an event).
Now I would like to easily collect the respondents for an event from various mails (announcement, invitation, reminder 1, reminder 2,..)
Currently I need to create segments for each response where I need to reference the campaigns individually. So whenever I send a campaign (email) I need to update all segments as there need to be a segment per question, which I would like to avaoid.
Hope thats clear enough.
I had a similar question and after a review of the mailchimp API docs, in particular the reports section I realized there was not a way to retrieve poll results.
After my review, I followed-up with mailchimp and they mentioned access to poll results via API is not available - detailed comments with image attached below:
MailChimp Response - Start
"To be completely honest and transparent, there currently wouldn't be a way of accessing the campaign poll result data directly through the report... With that being said, it would be possible to use the API to create segments based on poll response, then call those segments to view the number of responses for each option, as well as the specific subscribers who chose each individual option.
More info here: https://developer.mailchimp.com/documentation/mailchimp/reference/lists/segments/
MailChimp Response - End
As you can see, although accessing poll results via the API is not available, there is a work around using a method.
Good luck!
I want to send some custom properties in the attachment for interactive messages and retrieve them back in the action response. is there a way to do this?
Yes, that is possible. However, it only works well for small sets of data.
Assuming we are talking about buttons the normal approach would be to use the value field of an action to transfer custom data based on which button the user clicked back to your app. The field is a normal string within a JSON message, which is send by POST request to your app. So it can in principle contain a whole data set, not only a single value. All you need to do is include it in the button attachment that is send to Slack and your app will receive the respective value field back. (depending on what data you want to send you might need to encode it, e.g. you want to encode binary data into base64, so that is can be transferred as JSON string)
I have used it successfully in one of my apps to transfer serialized objects containing information about the user's application context.
There is one caveat though, that caused me to later abandon this approach again. As I found out the field length is limited, so if your string is too long you might end up with truncated data. In my estimation the limit is about 2.000 chars, but I do not have a definitive number.
Instead of transferring all data in the attachment, I now keep the user application context in a server session (PHP) and only transfer IDs through the value field of my buttons.
Conclusion: If you have small sets of data you can transfer them through the value field. If you have larger sets of data I would not recommend it.
I'm trying to learn how to use Parse and while it's very simple, it's also... not? Perhaps I'm just missing something, but it seems like Parse requires a lot of client-side code, and even sending multiple requests for a single request. For example, in my application I have a small photo gallery that each user has. The images are stored on Parse and obtained from parse when needed.
I want to make sure that a user can not store any more than 15 images in their gallery at a time, I also want these images to be ordered by an index.
Currently it seems like the only viable option is to perform the following steps on the client:
Execute a query/request to get the amount of pictures stored.
If the amount is less than 15, then execute a request to upload the picture.
Once the picture is uploaded, execute a request that stores an object linking the user that uploaded the PFFile.
This is a total of 3 or? 6 requests just to upload a file, depending on if a "response" is considered a request by parse too. This also does not provide any way to order the pictures in the gallery. Would I have to create a custom field called "index" and set that to the number of photos received in the first query + 1?
It's worse than you think: to create the picture you must create a file, save it, then save a reference to the file in an object and save that, too.
But it's also better than you think: this sort of network usage is expected in a connected app, and some of it can be mitigated with additional logic on the server ("cloud code" in parse parlance).
First, in your app, consider a simple data model where _User has an array of images (represented, say, by an "UserImage" custom class). If you keep this relationship as an array of pointers on user, than a user's images can be fetched eagerly, when the app starts, so you'll know the image count as a fact along with the user. The UserImage object will have a file reference in it, so you can optionally fetch the image data and just hold the lighter metadata with the current user.
Ordering is a more ephemeral idea. One doesn't order objects as they are saved, but rather as they are retrieved. Queries can be ordered according to any attribute, and even more to the point, since you're retrieving all 15 images, you should consider ordering them for presentation a function of the UI, not the data.
Finally, parse limits your app not by transaction count, but by transaction rate, with a free limit low enough to serve plenty of users.
A web application sends an email on behalf of a UserA to UserB, using the new Gmail API (Users.messages: send).
The synchronous response contains threadId, messageId which are stored in the database.
We then query the history API for any changes in user's inbox (Users.history: list).
Is there an efficient way to get all the updates since last sync (new replies, read/unread changes)?
One implementation that we tried was to filter the history API results through a custom label. Unfortunately, we noticed that once a thread/message is tagged with a specific label any subsequent responses are not labeled automatically and new replies are not included in the history API response.
A second approach was to query threads using gmail advanced search for a particular label and date (e.g. after:2014/08/29 label:MY_LABEL). The problem was that gmail does not return threads that were created before 2014/08/29 but had a reply on that date.
Any scalable suggestions would be greatly appreciated.
Not sure I understand here, users.history.list was made exactly for this. Given a previous historyId, you can then call history.list(previousHistoryid), iterate through the results to find all the message Ids that have been updated since the previous historyId. Then call messages.get() on all of those--for any messages you already knew about you can just call format=MINIMAL (to see label updates), and for new messages you can use a different format to get the message content if you need it.
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.