Need this correction of bug as soon as possible !

Thanks

Hi,

I don't feel that this meets the use case that I'm looking to solve for. I'm trying to change the issue type on existing request types in the Admin panel. For example:

1. Request Type A = Issue Type A
2. Replace Issue Type A with another issue type because Issue Type A doesn't fit the needs properly. Let's call this Issue Type B. I do this by removing Issue Type A and adding Issue Type B. 
3. Request Type A shows invalid Issue Type <-- I can't modify the issue type at all to make it be Issue Type B now. 

Can we please address this use case?

Thanks!

Great, This was something we where waiting for. Glad that this is active and working!

I believe that, although this covers part of the problem, it doesn't actually cover the full problem.

Right now I'm running a migration and merge of several instances. This implies merging JSM projects into one, sharing the Issue Types and Request Types. Now, we have some Request Types that share the same Issue Type so, the problem here, is that it will not be possible to preserve the values after moving the issues from Project A to Project B.

Wouldn't it be better to offer the option during the Bulk Move, similar as "Project" - "Issue Type" but also offer something like "Request Type (Source)" - "Request Type (Target)"?

Works great and stable.

Any concerns while this issue is still in progress?

Hi 09f95f6ac926 , sorry for the late response. I didn't see an email, could you please get in touch at jgonsalkorale@atlassian.com ? 

Jehan - I emailed you last week (Aug 24). Did you receive my reply?
Thank you,
Glen

Jehan,

Thank you so much for finally releasing this feature. Works great for us. One recommendation on future features - can Atlassian also implement a GLOBAL feature configuration option so as to avoid having to configure each individual project. This way the admin has the option to do at global or project level. 

thanks again. 

Hi 09f95f6ac926, 

It sounds like many of these issues relate to our recent release that updated the create issue experience. Would you be able to email me your instance? I can turn off the flag that surfaces the request type's configuration in the issue create experience to resolve these issues immediately while we make changes to this experience to better suit your needs. 

You can email me at jgonsalkorale@atlassian.com

Looking forward to hearing from you,

Jehan Gonsalkorale

Product Manager, Jira Service Management

Hello Jehan,

While this solution does accommodate the overall requirement, its application is causing our team new struggles.

In the Issue View (or Issue Create) screen, being forced to select a Request Type also forces the screen layout to reflect the customer portal Request Form layout. This causes unexpected results which we are now dealing with.

1. One problem we had to immediately address was some field validation rules in the workflow. Where a field was required upon Create Issue Screen, this field was not added to the Request Form. Now that creating an issue forces use of a Request Type and using the customer portal Request Form screen, we had to remove the validation rule which compromises our teams' process.
   -Practically, one example of many, we have a custom field Responsible Team.
   --When an agent creates an issue they were forced to select the appropriate Responsible Team, thereby putting it into the proper Queue.
   --We cannot add this field to the customer portal Request Form as it isn’t appropriate for customers to see nor fill in.
2. We have many different Request Types and as a result, numerous fields are differently either required, optional, or simply not added to the request type.
   -Previously, the Issue View screen had all the fields in the right margin.
   -Now, having the Issue View screen reflect the Request Type layout, our agents never know where to look for a particular field as it could by anywhere depending on which Request Type is used.
   --One example of many: Due Date field is sometimes optional and added on a Request Form for the customer to fill in. However, on other request types, sometimes an agent will still add a Due Date on a request type which does not have the field available on the Request Form. Therefore, the field is either in the issue view screen (on various Tabs) or on the right margin.
   --The order or placement of the fields on the Issue View screen are also non-standard, again pending the Request Form.
3. On the Create Issue screen, we used to have fields in a certain, logical order. Now, using the Request Type (Form), some fields are prevented from being placed at the top of the form.
   -Eg, Custom field = Responsible Team or Assignee are forced to be a the end of the form, assuming that the logic is: Hidden fields go to the end of the Request Form.
   --This is simply irritating and especially illogical, now that we’ve had to remove its validation (Ref #1 above).
   --The Create Issue screen fields used to be in order: Summary, Responsible Team, Assignee, Reporter, then other fields.
   --NOW, the Create Issue screen fields, forcing Request Type form layout, the fields are in this order: Reporter, Summary, other fields, then at the very bottom—Assignee, Responsible Team and any other hidden fields.

Please consider these complications in the Feature Lab for refinement.
Thank you,
Glen