We're showing this isn't resolved either. The reporter assigned by the service desk agent still cannot see the issues via the portal or the link from the email.

I agree, this matter isn't resolved and it would save a lot of duplicated effort.

Yes, this issue has not been fixed as of July 2017. How can I manually edit Customer Request Types on tickets? Moving is not an option as several Request Types share the same Issue Type.

What was the resolution to mark this done?

Why is this set as closed ?

And most importantly, i don't see any difference between request type and issue type from an agen\support perspective. Request Type is for customer, Issue type is for agent. And in real world , a request can be several issue types. For example: Request Type- Access Request, issue type can be an issue(unable to login, permission issues), or New user(which has different workflow and include approvals),

What doesnt make sense though is that I cant map one request type to several issue types, which means if I want to keep my service portal "clean" with only one option for customers (simple internal support) but I would like several issue types for our own sake internally, thats not an option.

You can only switch to a request type, which is mapped to your issue type. If the current issue hasn't a mapping, you can't select a request type - which make sense.

Seems I have the similar issue. The screen allows you to change the Request Type but all the options are grayed out.

rlprasad The later versions of JSD have the ability to change request type after an issue is created. You can edit it on the View Issue screen as shown below

what is the solution for this issue? how to edit the request type after the issue is created?

Hi Oliver. Thk you for your suggestion.

I'm on Service Desk 2.2.1 and in my case it works like follows:

In Table customfiledvalue you must add a record referring to the issue, CUSTOMFIELD = 10000
and STRINGVALUE like you suggested.

bye

Thanks Oli - that is exactly where I though it should be.

I can see the cfname Customer Request Type in customfield, but this does not have any corresponding values in customfieldoption

I have gone straight into Service Desk 2.0.3 so perhaps the layout is different.

customfieldvalue has the stringvalues that you suggested - spaceKey/requestTypename - for each issue, but I just cannot find where these options are stored.

Matthew

In the table customfieldoption with an value like [spaceKey]/[requestTypename] e.g: projectA/task.

You can uise the automation add-on to set this by creation, if unset:

JQL (please make it more specific for your settings):

"Customer Request Type" is EMPTY 

EDIT ISSUE ACTION:
customfield_11230=$issue.getProjectObject().getKey().toLowerCase()/task

hope this helps
oli

Does anyone know where Customer Request Type is stored in the SQL structure?
Matthew

In evaluating Serice Desk I found this issue too. It is very important for us to have this as we raise tickets for customers also.

Hi,
creating tasks / tickets for customers is a daily need. I create requests from phone calls daily. It seems strange that I cannot change the request type in the issue manually.

Best regards

Jens

We have the same need, because the call center has to open a ticket for customer.

Any update on this one? I'm running into the same challenges with our customers. I posted https://answers.atlassian.com/questions/308468/what-s-the-best-way-to-handle-service-desk-requests-submitted-outside-the-customer-portal#, which summarizes our situation. I've implemented a workaround that uses a Custom Field containing all Customer Request Types combined with the JIRA Automation plugin to change the "Customer Request Type" field when it meets certain criteria. It seems to work, but doesn't feel like a clean solution.

@Brad Baker How upstream you thinking? Your comment was 8 months ago. All migrated tickets and all email-submitted tickets and their notifications are invisible to reporters. Would appreciate some insight on your workaround:

"...as a work around today I think you can add VpOrigin to the create screen." What is that? VPOrigin is a class not a field. What do you mean exactly?

This worked in 1.0 and 1.1 but not anymore in 1.2

@svante.gustafsson got the same issue as you. and already have screenshare with atlassian guys. no result. after every restart of jirа got new filed

Hi,

I have added a post-function as a last action in my create-transition setting the field and it works quite well. The issue will be mapped in the SD.
(this makes both issues created directly from JIRA as well JEMH created issues to show up in SD)

But, I cannot see the issue in "My Issues" page It seems that page looks for something else.

As a sidenote: in my development environment where I play around with this I now have 12 fields called Customer Request Type. Any idea why? I haven't re-installed SD that many times

Rgrds,
// Svante

+ + Completely agree with "Kenneth Söderlund"!!

As we are using OnDemand, JEMH is not an option. It would be great to be able to define the Customer Request Type in the email handler that creates the issues. Otherwise creating new issues via email works fine, but the issues are not mapped to Service Desk.

Can't this be done with script runner?

Brad - I created a single line test field called VpOrigin, and added it to the service desk screen, then set a default value for it of one of the valid customer request type values. If you create an issue through Jira or mail, that field gets set, but it doesn't carry over to the customer request type field.

I don't think user editing of customer request type is necessary (at least not for us), but there needs to be a way to set a default value so that when you create an issue from Jira or via mail, it gets assigned some value and makes it visible when users login to the service desk.

There is a long standing bug in JIRA such that IF a field is not on the create screen then it will not be considered for editing. This has been fixed for edit but not create.

ServiceDesk uses a bit of a hack itself today to work around this bug by squrrielling away the value in a thread local and fixing it up via default values

 /**
     * The other side of the create issue call for default values.  A design bug in JIRA prevents us being included
     * as a value IF we are NOT on a default screen so we cheat by squirrelling away the value in the JIRA request cache
     * and then re-instating it as a default value instead of a provided value.
     *
     * @return the thread local vpOrigin value from {@link #onCreateIssue(IssueInputParameters, com.atlassian.servicedesk.internal.feature.customer.requesttype.RequestType)}
     */
    @Override
    public VpOrigin onCreateDefaultValue() {
        return getGrievousHack();
    }

    private void setGrievousHack(VpOrigin origin) {
        JiraAuthenticationContextImpl.getRequestCache().put(VpOriginManager.class.toString(),origin);
    }

    private VpOrigin getGrievousHack() {
        return (VpOrigin) JiraAuthenticationContextImpl.getRequestCache().get(VpOriginManager.class.toString());
    }

We will be looking to fix JIRA up stream. But as a work around today I think you can add VpOrigin to the create screen.

As an insight to the name, the original project code name was "Viewport" and hence Vp this and Vp that.

At this stage I am leaning away from allowing "user editing" of the RT field as the user experience of that would be awful but then again never say never right?

Cheers
Brad Baker
Service Desk Architect

From what I can see at first glance, with JEMH setting the Customer Request Type custom field to an appropriate value such as 'test/default001' does not currently result in that field being set, which is unexpected. Further 'research' required. Any useful insight on how this field can be populated would be appreciated - given there is no source download for ServiceDesk?

Manually editing is only relevant for fixing this. More important is to be able to set those fields for incoming email, tasks added via capture or jira itself automatically.

The other option would be to be able to control the filters, so that there is a 1:1 relationship between issue type and request type, which would work perfectly for me (as I am not using more request types for an issue type). Maybe it can be solved to have a "default" request type for an issue.