Hi
I am exploring forge. I’ve adapted some of the example apps to pull some data from Salesforce and present it in a table in an Issue Panel.
My next step is to use some of the issue’s custom field values to send requests to Salesforce API.
I am using the code below to retrieve the issue data.
async function getIssueData() {
// Fetch issue fields to translate from Jira
console.log(`/rest/api/3/issue/${issueKey}`);
const issueResponse = await api.asApp().requestJira(`/rest/api/3/issue/${issueKey}`);
await checkResponse('Jira API', issueResponse);
const issuedata = await issueResponse.json();
return issuedata;
}
This is working fine with a Jira Software project. But when I use the app on a Service Management project is fails with a 404 error.
“There was an error invoking the function - Error from Jira API: 404 {“errorMessages”:[“Issue does not exist or you do not have permission to see it.”],“errors”:{}}”
I am sure the API key is valid as it works for Jira Software Projects, and my user account associated with the key can access and browse the Jira Service Desk project through the web UI and can retrieve issues using Postman and the REST API.
I’ve also tried the Forge Issue Translator example app and it appears to have the same problem when used on the Jira Service Desk project.
Does Forge support retrieve issue data from a service desk project? Can anyone offer some help or examples of code retrieving issue data?
UPDATE: I tried installing the app on another cloud site. This time it worked with a JSD project. I was able to retrieve the issue.
I then checked the permission schemes in Site A (not working) and Site B (working). I found that in Site B, I had a permission scheme in the JSD project which provided Browse Project permissions to anyone with a JIRA Software license.
I applied the same permissions in Site A and I was able to read the issue.
Why do I need a JIRA Software license to read an issue in a Jira Service Desk project. This doesn’t make sense to me?
I added more code to update the JSD issue. But this fails with the error “customfield_XXXXX cannot be set. It is not on the appropriate screen or is unknown”. I’ve verified that the field is on all screens and can update this field using the same API call from Postman.
I suspect that either JSD projects are not yet supported properly in Forge, or there is something wrong with the Oauth authentication.
Sorry for the late reply. We have a follow up question to better understand where the problem lies. How the browse project permission is given to the user on site A e.g. through role/application-access/group? If it is possible to attach screenshots of permission scheme it would be perfect.
We are returning 404 in case user lacks browse permissions so we’d like to double check whether this is the case for the site A.
I encounter the same problem.
When I deploy a Connect App, a user is created and this user is automatically added to the project role “atlassian-addons-project-access”. By granting rights to this project role, apps are able to make the changes required.
When deploying a Forge-app, the user is created but unfortunately not added to this specific role across the projects.
You say " * Grant browse/edit permissions to the single user that has been created while deploying your forge app". I don’t see any user created by my Forge App. Where can I see this? Or do you mean the user that has installed the app?
The TL;DR on the root cause is as follows, but I strongly recommend to read the detailed description for context and two possible workarounds:
Due to an underlying limitation, additional permissions for the app system user are not configured when the app is installed.
If you app attempts to read, write, or manage content using .asApp() authentication in a container (project or space) that is not accessible to default user group, that API call will fail.
I missed your reply - apparently my notifications are not configured properly.
I’ll describe the steps that I did in order to find a solution for consultancy client I was serving. If you are trying to roll this out to customers where you don’t have access , you’ll have to do some digging using the rest api.
When you deploy a Forge app, a user is being created automatically. The actions that your app takes, are being recorded as done by this user, eg changing a field on an issue. The name of this user is the same as the key provided in your Forge app descriptor. If you are not certain which name that would be, you can easily find this one:
In the Product Settings page, look for the Connected apps item. When you click on it, you’ll see all Forge-installed products (and some others) in that list. Validate the your app is installed and note the name that you see here (this is the same as you defined in your descriptor)
Jira used to have a dedicated users section where you could look up all users (end users and system users like those from products), but unfortunately this page is gone. To get some details using the UI, go to eg the Project Roles config page. Click on one of those “Manage Default Members” links.
(Side info: The project role atlassian-addons-project-access can’t be edited - whenever you install a Connect app, a user is created and automatically added to this role)
On this profile page, you can already fetch the account id in the url. If you would want to see some more info, you can click on the … and on Manage access
Clicking on this link will take you to the dedicated user page in the administration - where you can easily see the project roles configured for this user, id etc.
Important to note: the underlying user id is different when you deploy a development/staging/production version, although the name will be the same. This caused me some trouble.
When you have this is, you can start adding the required permissions in permission schemes. If it’s only for 1 customer you can do this manually (if did it with a set of curl commands).
Otherwise I’d like to refer to the snippet that Atlassian had provided here: [FRGE-212] - Ecosystem Jira
Important to note: the underlying user id is different when you deploy a development/staging/production version, although the name will be the same. This caused me some trouble.