Cannot pass "In-Reply-To" parameter to Microsoft Graph sendMail - microsoft-graph-api

I allow users to send emails with their Outlook account by using Microsoft Graph API, but it seems to be creating multiple threads on the other side.
When using Mailgun API to send the user emails, I am able to pass the In-Reply-To message header that references the previous message Message-ID, and threads are clustered properly by clients on the other side (Outlook/Gmail etc)
But when using Microsoft Graph API I try to pass the In-Reply-To and it is not accepted by the API
graph_url = 'https://graph.microsoft.com/v1.0'
headers = {
'User-Agent': 'api/1.0',
'Authorization': f'Bearer {outlook_token}',
'Accept': 'application/json',
'Content-Type': 'application/json'
}
# Create recipient list in required format.
recipient_list = [{'emailAddress': {'name': name, 'address': address}} for name, address in recipients]
reply_to_list = [{'emailAddress': {'name': name, 'address': address}} for name, address in reply_to]
# Create email message in required format.
email_object = {
'message': {
'subject': subject,
'body': {
'contentType': content_type,
'content': body
},
'toRecipients': recipient_list,
'replyTo': reply_to_list,
'attachments': [{
'#odata.type': '#microsoft.graph.fileAttachment',
'contentBytes': b64_content.decode('utf-8'),
'contentType': mime_type,
'name': file.name
}],
'internetMessageHeaders': [
{
"name": "In-Reply-To",
"value": in_reply_to
},
]
},
'saveToSentItems': 'true'
}
# Do a POST to Graph's sendMail API and return the response.
request_url = f'{graph_url}/me/microsoft.graph.sendMail'
response = requests.post(url=request_url, headers=headers, json=email_object)
https://learn.microsoft.com/en-us/graph/api/user-sendmail?view=graph-rest-1.0
I get the following response:
{
"error": {
"code": "InvalidInternetMessageHeader",
"message": "The internet message header name 'in-Reply-To' should start with 'x-' or 'X-'.",
"innerError": {
"request-id": "7f82b9f5-c345-4744-9f21-7a0e9d75cb67",
"date": "2019-05-03T04:09:43"
}
}
}
Is there any way of having the emails sent in the same thread for recipients clients?

Even if this thread is old, maybe it will help someone:
With the latest graph version you can now also send e-mails with MIME content. With this API you can set the in-reply-to header and other header fields, which was not possible with the JSON upload.

You can't manipulate standard message headers this way. The internetMessageHeaders collection will only accept "custom headers". These are message headers that begin with x- i.e. x-some-custom-header).
In order to reply to a message, you need to use the /createReply endpoint:
POST https://graph.microsoft.com/v1.0/me/messages/{id-of-message}/createReply
This will generate a message with the appropriate headers. You can then update this message to add additional content/attachments before you send it:
PATCH https://graph.microsoft.com/v1.0/me/messages/{id-of-reply}
{
"body": {
"contentType": "HTML",
"content": body
}
}
POST https://graph.microsoft.com/v1.0/me/messages/{id-of-reply}/send

Related

Update message in google chat from Jira

I am trying to create a notification in google chat whenever the status of a jira ticket changes. I have managed to sort the automation so that a message is sent to google chat every time the status changes but it creates a new thread each time. I would like to either update the original message with the new status or add a new message to the same thread.
I have the Automation configured to Send web request as follows has anyone managed to do this?
Webhook URL : https://chat.googleapis.com/v1/spaces/xxxx/messages?key=xxxx&token=xxxx
Header : Content-Type - application/json; charset=UTF-8
HTTP method : POST
Webhook body : Custom data
Custom data
"cards": [
{
"header": {
"title": "{{issue.key}}",
"subtitle": "{{issue.summary}}"
},
"sections": [
{
"widgets": [
{
"keyValue": {
"topLabel": "Reported by",
"content": "{{issue.reporter.displayName}}"
}
},
{
"keyValue": {
"topLabel": "Status",
"content": "{{issue.status.name}}"
}
}
]
},
{
"widgets": [
{
"buttons": [
{
"textButton": {
"text": "View Ticket",
"onClick": {
"openLink": {
"url": "{{issue.url.customer}}"
}
}
}
}
]
}
]
}
]
}
]
}
Example of what is happening
To create a new message under the same thread, you need to provide the thread as part of the message body
When you send the first message, the response contains a message resource that contains a thread resource
Include the thread name you obtain after sending the first message into the message body of the subsequent messages - this will enforce threading
To update an existing card, you need to follow the documentation:
Use the actionResponse.type UPDATE_MESSAGE instead of NEW_MESSAGE
I am not sure how you trigger an action response in your situation, but if you have a functionality that is able to trigger a new message, you can just as well trigger UPDATE_MESSAGE instead

insert multiply records to a form, from JSON file using postman

How can I insert multiply records to a form using postman?
my data is in JSON file
and I use POST request:
"https://jrpostest.domjr.local/odata/Priority/tabula.ini/jrdf/SUPPLIERS"
getting the error below
You can use batch request in order to insert multiple records into a parent form with
one server call.
POST
https://jrpostest.domjr.local/odata/Priority/tabula.ini/jrdf/$batch
{
"requests": [
{
"method": "POST",
"url": "SUPPLIERS",
"body": {
"SUPNAME": "33445566",
"SUPDES": "33445566"
}
},
{
"method": "POST",
"url": "SUPPLIERS",
"body": {
"SUPNAME": "33445577",
"SUPDES": "33445577"
}
}
]
}
Please note that batch requests are available from Priority version 19.1.
In previous versions you will need to send two POST requests to the SUPPLIERS endpoint.

Create a surveymonkey webhook that triggers a workday studio listener endpoint

I am creating a surveymonkey webhook that sends data to a workday studio listener endpoint.
For those who have done this before, my question is:
how do I add the authorization header (username and password)?
Here's my JSON body:
{
"name": "Nasdaq_Webhook",
"event_type": "response_completed",
"object_type": "survey",
"object_ids": ["155794502"],
"subscription_url": "https://e2-impl-cci.workday.com/ccx/cc-cloud-repo/launches/INT057_Test/INT057_Test/StartHere"
}
{
"name": "Nasdaq_Webhook",
"event_type": "response_completed",
"object_type": "survey",
"object_ids": ["155794502"],
"subscription_url": "https://e2-impl-cci.workday.com/ccx/cc-cloud-repo/launches/INT057_Test/INT057_Test/StartHere",
"authorization": "Basic {username/pw hash}"
}
https://www.blitter.se/utils/basic-authentication-header-generator/

Pact verification: Failure/Error: expect(header_value).to match_header(name, expected_header_value)

Using pact to verify if the response header matches for the consumer and provider.
Running the pact verification on the provider side gives me the following error:
Failure/Error: expect(header_value).to match_header(name, expected_header_value)
Expected header "abc" to equal "xyz", but was nil
However, when I inspect if my response header, it gives me the expected value ("xyz").
Here is the sample pact file I'm trying to verify:
"interactions": [
{
"description": "a request to do something",
"request": {
"method": "get",
"path": "/example"
},
"response": {
"status": 200,
"headers": {
"abc": "xyz"
}
}
}]
I’m new to pact. Any help would be appreciated.
While this is an old post, I hope this will help anyone who views this.
I'm not familiar with ruby, however if your using a basic HTTP Rest request you need to add the accept headers on the 'withRequest' as well as the expected headers on the 'withRespondWith'. You can use Postman to view both request and response headers; JavaScript Example:
describe('When a request is made to get all <resources>', () => {
beforeAll(() =>
provider.setup().then(() => {
provider.addInteraction({
uponReceiving: 'a request to receive to receive all...',
withRequest: {
method: 'GET',
path: '/<resource>',
// Default headers from Axios documentation
headers: { Accept: "application/json, text/plain, */*" }
},
...
willRespondWith: {
// expected headers
headers: { "Content-Type": "application/json; charset=utf-8" },
...

JIRA API after POST returns { errorMessages: [ 'Internal server error' ], errors: {} }

I am trying to create a new issue utilizing the JIRA REST API and whenever I try, I get back the following generic error:
{ errorMessages: [ 'Internal server error' ], errors: {} }
I can successfully GET from the API, and the credentials I'm connecting with have full Admin access to JIRA (so it's not an Auth issue), but I get this error every time with POST. Below is a snippet of the JSON data I'm sending. Am I missing anything obvious?
Below is my JavaScript code. Note I'm using jira-connector from npm. (Real domain replaced with mydomain for this sample code)
const JiraClient = require('jira-connector');
const dotenv = require('dotenv').config();
function createNewIssue(fields) {
const encoded = process.env.JIRA_ENCODED_PW;
const jira = new JiraClient({
host: 'mydomain.atlassian.net',
basic_auth: {
base64: encoded
}
});
return new Promise((resolve, reject) => {
jira.issue.createIssue(fields, (error, issue) => {
if (error) {
console.log(error);
reject(error);
} else {
console.log(issue);
resolve(encoded);
}
});
})
}
Below is the JSON that's being passed into fields in the JS above. Note customfield_17300 is a radio button, and customfield_17300 is a multi-select box. For both cases, I've tried using the "id" and also the actual string "name" value. All IDs below were taken straight from a API GET of the same issue in question:
{
"fields": {
"project": {
"id": "13400"
},
"summary": "TEST API TICKET - 01",
"issuetype": {
"id": "11701"
},
"customfield_14804": { "id": "13716" },
"customfield_14607": "Hardware",
"customfield_17300": [
{
"id": "18322"
}
] ,
"customfield_16301": "Customer PO",
"customfield_14800": "LA, California",
"customfield_16302": "FEDEX 234982347g"
}
}
sigh I figured it out... other posts that said this cryptic error was due to a malformed JSON were correct.
In my route, I passed fields as coming from req.body.fields which actually dove into the fields values instead of passing it straight through. This made it so that when the JSON was sent to JIRA the fields outer wrapper was missing. I changed my route to pass along req.body instead of req.body.fields and all was well.
...that was a fun 4 hours...

Resources