Uploaded image for project: 'Jira Service Management Cloud'
  1. Jira Service Management Cloud
  2. JSDCLOUD-9270

Preserve URL Parameters Across JIra Service Desk Portal

    XMLWordPrintable

Details

    • 4
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              ea582e71db54 G
              Votes:
              72 Vote for this issue
              Watchers:
              35 Start watching this issue

              Dates

                Created:
                Updated: