Hi everyone,

I should have created this right when Adam told me, but I just put in this suggestion to maintain these parameters across the service desk:  https://jira.atlassian.com/browse/JSDCLOUD-9270

Feel free to vote on that one if you are interested.  We need to be able to maintain details about our customers that we already know about them as they navigate around our portals.  Huge thanks to Adam for getting us started and giving us what we have today for single request types!  Hopefully we can get this followup portion implemented to make customers lives better.

I agree, Dmitry.  That definitely is a huge bummer.  Adam Hynes implemented a wonderful change that plugged a hole in a widespread deficiency and we are truly thankful.   A true Engineer for the people.  If anyone else sees this, carry on the torch and make simple changes like this that have a huge impact.  Iterate quickly.  Listen to your power users and don't chase the things that look shiny to attract unsophisticated users (that leads to a lot of churn in customers).  I somehow missed his last message to me on March 18th and I truly appreciate the response.

It's sooo sad to see that Adam Hynes is inactive =( 
You made a great job, thanks a lot. I hope you'll see my message, bro

Hi greg.draper310998593,

Unfortunately, implementing this would require us to preserve URL parameters as a user navigates the portal. Some pages, like the My Requests page, have their own URL parameters that are used for pagination or result filtering, so we would have to make sure we don't interfere with existing parameters if we implemented this.

Because of this complication, while it's possible, implementing what you ask for would require some extra work than just preserving URL parameters across all pages. Unfortunately I won't have time to implement this myself. If you feel you need it, then go ahead and create a new Suggestion ticket.

Thanks,

Adam

Hello again, Adam.  Still very very happy with this.  Is there any way to maintain the URL parameters through navigation from the top level of a portal?

e.g.  atlassian.net/servicedesk/customer/portal/2?summary=test  will then go to atlassian.net/servicedesk/customer/portal/2/group/37?summary=test and then to atlassian.net/servicedesk/customer/portal/2/group/37/create/140?summary=test as a user clicks through the portal

Was hoping we could do that somehow to maintain values as users navigate between multiple different request types.  I know this is generally possible to do, but it is currently not setup to do this in Jira Service Desk from what I am seeing.  Thanks!

This goes to the production right away. Thank you sooo much! 

I have been waiting for so long for this. It works great! You are awesome! Thank you so much!! 

Hi greg.draper310998593, cheers for the kind words, I would gladly accept that drink!

I did a quick test and yes, you can pre-populate the "Email confirmation to" field. That field has a field id of email, so all you have to do is add an email=newuser@test.com URL parameter and it should work.

Adam Hynes, I owe you a drink! This is one of the most critically needed features in the Jira ecosystem. If Jira Service Desk continues to get the love like this that it needs, Atlassian will be unstoppable. Definitely kudos to you for realizing that and you deserve a ton of praise. Now we finally have some sort of way to know who our customer is and pre-populate fields relevant to them on requests.

I will be implementing this in a bunch of places today and it feels like Christmas morning to me. One question... are we able to pre-populate the “Email confirmation to” on a login free portal? That’s me asking for the cherry on top (but I’ll still be happy if the answer to that is no). Someone give Adam a raise immediately.

Thanks for the kind words aragot1463073100.

For the components field, you need to use the component id. From your example it looks like you're using the component value as your URL parameter. From my test request create page, I have the following data for the components field in the JSON payload:

{
  "fieldType": "multiselect",
  "fieldId": "components",
  "fieldConfigId": "",
  "label": "Components",
  "description": "",
  "descriptionHtml": "",
  "required": false,
  "displayed": true,
  "values": [
    {
      "value": "10003",
      "label": "Active Directory",
      "selected": false,
      "children": []
    },
    {
      "value": "10004",
      "label": "Analytics and Reporting Service",
      "selected": false,
      "children": []
    },
    {
      "value": "10005",
      "label": "Billing Services",
      "selected": false,
      "children": []
    },
    // ...more components
  ]
},

If I want both "Active Directory" and "Billing Services" to be selected, I need to add two parameters like so: &components=10003&components=1005.

The same applies to the single select field. On my test request create page, I have a "priotity" single select field, with the following data in the JSON payload:

{
  "fieldType": "select",
  "fieldId": "priority",
  "fieldConfigId": "",
  "label": "Priority",
  "description": "",
  "descriptionHtml": "",
  "required": false,
  "displayed": true,
  "values": [
    {
      "value": "1",
      "label": "Highest",
      "selected": false,
      "children": []
    },
    {
      "value": "2",
      "label": "High",
      "selected": false,
      "children": []
    },
    {
      "value": "3",
      "label": "Medium",
      "selected": true,
      "children": []
    },
    {
      "value": "4",
      "label": "Low",
      "selected": false,
      "children": []
    },
    {
      "value": "5",
      "label": "Lowest",
      "selected": false,
      "children": []
    }
  ],
  "noneOptionRequired": false
}, 

So to set this field to "Lowest", I'd use the url param priority=5.

For your case, try to find "customfield_11011" in the JSON paylod and see what "value" corresponds to what you want.