Adam Hynes thankfully implemented the Pre-filled values for fields in a request.  This was a huge gap that existed in the Jira Service Desk customer portal.  Now we can send someone a form link and pre-fill values that we already know about our own customers (the service plan they are on, their email address, any relevant custom field values, etc.).  It is wonderful!

Example of parameters:

/servicedesk/customer/portal/2/group/22?summary=This+is+awesome&description=So+glad+we+can+supply+parameters+and+pre-fill+values&email=coolcustomer@gmail.com&customfield_123=test

However, if your customer navigates to another part of the portal (switches request type or back to the search of the portal), all of these super helpful parameters are cleared.

Acceptance Criteria

• URL query parameters supplied in a URL are maintained as the user navigates across the service desk
  • At the very least, switching a request type should keep the parameters, but they really should follow you throughout
• If the user navigates to another screen that uses parameters, they are appended to the ones in your URL to maintain that functionality
  • Login screen has parameters that should maintain what was supplied
    • ?destination=portal%2F2%2Fgroup%2F22
  • Requests page has parameters
    • ?page=1&status=open
  • Approvals page has parameters
    • ?approvalQueryType=myApproval&page=1

If you must clear the parameters when the user goes to the Login, Requests, or Approvals pages, that is fine as a first implementation.  We really just need users to be able to switch between request types, groups and portals within the instance, with request types being the most important to maintain the parameters.

The most common use-case is that a customer will land into a specific portal, drill down into a group (if you have groups), then into a request type.  We want to be able to send them to that top level and have the parameters follow them down each level and be maintained as they navigate around.