We are creating a project in Jira Service Management using shared settings through the API. However, when the project is created via the API, default request types are appearing even though they do not exist in the reference (shared settings) project.
These request types also do not seem to have any connection with the shared settings project. We would like to understand which project settings are being referenced when these request types are created by default.
Additionally, what is the best approach to ensure that the request types from the shared project are copied exactly as they are?
Hi @sankalp_khare ,
Here's a list of entities that are shared when you create a new service space: Create and edit a service project
As for copying request types, they may not always be copied exactly due to current platform limitations, and currently, there is no built-in way to guarantee that they are copied exactly as they are in the reference space when creating a new space via API.
There are two feature requests that relate to this:
As for the API you're using, I'm guessing it depends on the actual calls you're using. I've never built something like that, but as work types are global entities (when talking about company-managed spaces), there should be some attribute that you can set when 'copying' request types that determines which work type it is assigned to 👀
If you could share part of the API call that creates this part, we could take a look at it.
Cheers,
Tobi
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@sankalp_khare Hmm, I'm guessing the system then pulls default request types into the new space based on the template you've used (or based on another space you've copied). By looking at your POST request, you don't specify the request types that will be 'added' there.
I did take a look at JSM REST API, and after some looking, I realized there's no endpoint to actually update the existing request type. There is, however, a feature request for it: JSDCLOUD-4609: Ability to update Customer request via REST API
All in all, I would say that the only 'workaround' is to manually connect those request types with work types (ex issue types) after the API does its thing. 🫤
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I agreed with @Tomislav Tobijas statement, since I am not heavy REST Apis user, I always uses the UI for project permissions.
From your perspective, once when a project is created via REST Apis... I would recommend that you actually conduct a manual check on the Request Type setup to ensure the shared configurations are all in place before releasing it to your users.
Hope this also helps.
Best, Joseph
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Tomislav Tobijas @Joseph Chung Yin
I wanted to ask one thing: if the request types are showing up from some default projects
So, need to understand why this type of behaviour is the one I have shared on the image above
At least those request types should work on that part
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey @sankalp_khare ,
Even when using shared settings, Jira Service Management may add default request types based on the project space template or system defaults. This can result in request types like "Customer support," "Employee exit," "IT help," and "New employee" appearing in your new space, even if they do not exist in the reference space.
As stated above, it would seem that some configurations and connections are copied, while others are not (such as connections of request types to work types 👈)
Definitely not ideal, but in the end, it's a platform limitation.
It would seem your space is using some kind of template and that's why you're seeing these request types, but in the end, until something like this:
is developed (again, this is my best guess), it would seem that you'll have to adjust this specific config manually.
You could check with Developer community if someone has found a solution/workaround related to this 👀
I mean, you could also reach out to Atlassian Support and see what they will say about this issue you're seeing.
Cheers,
Tobi
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.