Sorry to hear that. We are working on a fix here, but I think it might be easier if we rolled back the request type configuration (you'll still get the Issue Type and Request Type drop downs).
Could you email me at jgonsalkorale@atlassian.com ?
I'd be more than happy to roll that part of the change back to sort this out in the short term.
That is a very good question. There absolutely is. We are soon to release a Feature Lab feature that will allow you to set a default request type for issues per project. The first iteration will not cover the create experience as it is designed for ensuring that the request type is not lost when tickets are moved (whether across issue types or projects).
We will be working on updates to that experience in the following weeks to allow for default request types to appear in the create experience. I'll provide an update on that once we get the estimates (I want to make sure we don't overpromise).
We have Sandbox and Production environments, Issue create experience is different in both instances now, In Sandbox when a request type has field with required option enabled, it applied in both portal and agent screen. In Production this behavior ur is not same
We currently in the process of moving a JSM project to production, all demos and training are done in sandbox and the production is not working same as sandbox :-(
@Jehan Gonsalkorale Is there a way to have the Request Type be cascaded/filtered from the Issue Type.
Our users would like to select Incident and then have the Request Type filtered to just show those issues that are Incidents and not have to scroll through the entire list that includes requests, changes, problems, etc. Or if they want to submit a change, they don't want to have to scroll through all of the incidents and requests.
That's a very reasonable request. We are definitely looking at improving this experience further and this is a very good point. We considered a cascading list before but there were many customers who had a large number of issue types and a (relatively) small number of issue types. This made finding the right request type extremely difficult.
But that's just explaining why we didn't do that for now, we can definitely look into it as you are not the only customer who mentioned this.
We will provide updates on Community when we have more improvements coming.
I am new in JIRA configuration of our company service project and I am looking for a way to modify the No Request type as I want to make the field Components mandatory.
I do believe it needs to be done through Field Configuration where attribure Required needs to be picked for Components. You need to be a Jira admin since this change is done in Jira administration.
Then in Field Scheme you need to specify on which Issue types this mandatory condition applies.
However this solution will apply on Issue Types not Request Types since No Request layout cannot be modified.
I am not aware if it is possible to do anything with No request. In tickets its value is represented as None so I doubt it is even represented as a configurable object in Jira data therefore most configurations would be inhereted from Fields and Screens.
If you are Jira admin I suggest you to get more familiar with Fields, Screens and Layout Configuration.
Though you need to be Jira admin to have a power over these configuration (maybe layouts are exception, I am no sure now).
60 comments