Making a comment to an issue via Postman with token

Hello!

I’m trying to make a comment to an issue (excuse the space, new user-limitation):
https ://org.atlassian. net/rest/api/2/issue/[issue-id]

Using postman, I’ve been able to comment by Posting to:
https://org.atlassian.net/rest/api/2/issue/[issue-id]/comment
through Basic Auth using admin email and api key for Username/Password

I would like to able to comment to this issue using a token.

I’m trying to Post to:
https://api.atlassian.com/ex/jira/[cloud-id]/issue/[issue-id]/comment/
with Bearer auth using an access_token.

Is there a way to do this?

The current response I’m getting is:
OAuth 2.0 is not enabled for this method

Thank you for the help :slight_smile:

@ChristopherCasares,

You POSTed to https://api.atlassian.com/ex/jira/{cloudId}/issue/{issueId}/comment/, but that’s not the correct URL to an API; hence, “OAuth 2.0 is not enabled…”

I was able to use an OAuth 2.0 bearer token POSTing to https://api.atlassian.com/ex/jira/{cloudId}/rest/api/3/issue/{issueId}/comment. I think it should work just as well if you prefer the v2 API.

Thank you for the response!

Yes, I just got it to work with v2 (easier to make the body)

I had to add the scope

write: jira-work

However, in the docs, it states that is being deprecated in Aug '22:
https://developer.atlassian.com/cloud/jira/service-desk/rest/api-group-servicedesk/

The other write scope listed in the response I got was write:comment:jira, However I get an error when adding that scope.

@ChristopherCasares,

Yes, we’re in the middle of a confusing and only partially documented change, then rollback:

Sorry for the confusion. Yes, write:jira-work is the scope that works for me.

Thanks for all your help and insight. I have one more question if you will

Is this endpoint deprecated or still in use? And if it is in use, how does it differ from the endpoints above?
https://api.atlassian.com/ex/jira/[cloud-id]/rest/servicedeskapi/request/[issue-id]/comment/

@ChristopherCasares,

The endpoint is not deprecated. Only the older scope for authorizing the request (and not until the future).

The difference is subtle. That whole set of API endpoints is the approximation of the portal user interface. It should be used on behalf of “customers” (the users who are not JSM agents); however, there’s currently a missing capability where OAuth 2 doesn’t work for customers. If you wanted to use that API to build a new service portal UI, you would have to use Atlassian Connect.

Since that API is meant to be the portal, the API also doesn’t support ADF, the rich formatting that Jira agents use on their ticket view (the portal doesn’t have that editor). In JSM, comments can have permissions, but they can’t be set/changed by customers in the portal, so the API doesn’t support that either.

The most obvious difference is that API will only work for JSM projects, while the Jira platform one will work with all Jira projects.

Apologies if this is not-related.

So if I want a “customer” to be able to leave a comment under their name instead of the jira admin, I should use the endpoint:
https://api.atlassian.com/ex/jira/[cloud-id]/rest/servicedeskapi/request/[issue-id]/comment/
And since that endpoint doesnt support OAuth 2, I should be using a JWT instead?

@ChristopherCasares,

It does exist for the admin, or any agent. For them, I would recommend the more powerful Jira platform equivalent instead. Yes, for customers there is no OAuth 2 so you would need to build an Atlassian Connect App and use JWT auth.

Hey again!

With the endpoint previously mentioned above:
https://api.atlassian.com/ex/jira/{cloud-id}/rest/servicedeskapi/request/{issue-id}/comment/

When trying to make a comment, I get the following response:
{“errorMessage”:“The request type you are trying to view does not exist.”,“i18nErrorMessage”:{“i18nKey”:“sd.customerview.error.vpOriginMissing”,“parameters”:}}

What is the “Request Type” and where can I view it?

I’m just trying to figure out why I can comment via some endpoints and not others (or figure out what they need)

Thanks!

@ChristopherCasares,

To explain “Request Type”, let me work the API analogs from the customer perspective using a service desk. Your client can get request types for a service desk using GET /rest/servicedeskapi/servicedesk/{serviceDeskId}/requesttype. And your client can get all request types using GET /rest/servicedeskapi/requesttype. When a request is created (either in API or portal UI), it will store that request type on an underlying issue in a custom field. To know which field, your client can search fields using GET /rest/api/3/field/search?query=request%20type. For me, that returns:

{
	"maxResults": 50,
	"startAt": 0,
	"total": 1,
	"isLast": true,
	"values": [
		{
			"id": "customfield_10023",
			"name": "Customer Request Type",
			"schema": {
				"type": "sd-customerrequesttype",
				"custom": "com.atlassian.servicedesk:vp-origin",
				"customId": 10023
			},
			"description": "Holds information about which Service Desk was used to create a ticket. This custom field is created programmatically and must not be modified.",
			"key": "customfield_10023",
			"isLocked": true,
			"searcherKey": "com.atlassian.servicedesk:vp-origin-searcher",
			"screensCount": 0,
			"contextsCount": 1,
			"lastUsed": {
				"type": "NOT_TRACKED"
			}
		}
	]
}

Now, I can reverse the process. If I have an issue, customfield_10023 will have a value if it was created through a service desk (again, either by API or UI portal). If that field doesn’t have a value, then JSM doesn’t know it as a request and you can’t comment. So, it’s possible to “break” requests by nulling the request type.