Internal Errigal Collaboration Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Support Request Application Development ======
Updated by Yanjun Wang 09/12/2021
 
See also  [[SupportRequestPageScottyProWorkflowsandForms:support_request|ScottyPro Workflows and Forms]]

==== Overview ====

The Support Request Application is developed for auto-creating support requests in ScottyPro Ticketer, and for customers to easily access their requested tickets, which removal of manual operational and support work to enable the team to focus on triage of new tickets and non-repetitive work. The APP has been integrated with Errigal Common Header, CAS, Userprofile, also tracked by Google Analytics.

Repo: https://bitbucket.org/errigal/support-request/src/dev/

----

==== Access and Permissions ====

The APP has been integrated with CAS and Userprofile.

User can visit support-request from either the button on Support Page, or link directly
  * The APP link on the Support Page can also be turn-off by changing the url.support-request to "unknown" instead of the real link.
  * There are two types of links for visiting a ticket
    * The link with a ticket ID at the end can only be accessed by a login user.
    * The link with a ticket ID and correct external key at the end can be accessed by anyone. The external key is generated by system based on the ticket ID, it can be get from "Get Sharable Link".

{{ :development:applications:sr-btn-new.png?600 |}}

Permission control is handled by Userprofile.
  * Admin User: have access to the view of whole company tickets
  * Normal User: only have access to own tickets
  * SCO Full Access User: have access to all the tickets regardless company(for SCO env)

----

==== Details ====

All the tickets information are queried from Ticketer API.

View 1: Shows user's own tickets and company tickets
  * By clicking the **My Tickets/Company Tickets** button, the admin user can switch between the own tickets view and the whole company tickets view.
  * The user visibility is restricted by the env customer, which is defined on config_entry table: VISIBILITY and WORKFLOW. 
  * **My Tickets** will list all the tickets that Support Request Details form Requester Email/Point of Contact field value matching login user's email.
  * The 4 input/dropdown components are for filtering tickets based on Ticket ID, Ticket Priority, Ticket Summary/Description(the description field on Support Request Details form)/Title(initial issue title/summary that customer put when creating the request), Ticket Status. Only open tickets will be shown as default, but with the toggle turn-on, most recent closed tickets will be shown as well, default to last 28 days' tickets, and this is configurable.  The filtering will work with re-querying from API.
  * The tickets data table support global search within the current tickets list.

{{ :development:applications:sr-table.png?600 |}}

View 2: Ticket Details
  * By clicking each of the tickets on the table, or using ticket ID to access directly, the detailed info of that specific ticket will be brought back to the user.
  * Clicking each of the attachments on the ticket to download the file.
  * User can update some of the ticket info from here.
  * By clicking the link to **My Tickets** or **Company Tickets**, the user can return to the tickets list.

{{ :development:applications:sr-detail-new.png?600 |}}

  * User can get the URL to share by **Get Sharable Link**.
    * Internal Link: users who visit the ticket by this link need to login to IDMS first, and can view the full info of the ticket
    * External Link: users who visit the ticket by this link(with an external key) doesn't need to login, but can view limited info of the ticket

{{ :development:applications:sr-detail-share.png?200 |}}

View 3: Ticket Forms
  * The form on the top of the view is for customers to send updates(with attachments).
  * If the current status on the update form is **Awaiting Response from Customer** when an update is submitted, the ticket will be moved to **Customer Response Provided**, (real status name could be different).
  * The toggle of **Request Ticket Close** will be represented on the updated form, but won't close the ticket directly. The decision will be made by OPS.
  * The toggle of **Approve Billable Hours** will be represented on the updated form when the ticket is in Pending Approval status, which usually means the customer is approving the billable LOE.

{{ :development:applications:sr-form-new.png?600 |}}

  * Forms listed under update form simply list all the forms visible by customers, the form visibility is configurable(config_entry.name='CUSTOMER_VISIBLE_FORMS').
  * All the forms from the list are **read-only**. 
  * The user added the form is always shown as **User API Admin**, which is the user to make the update API call, this is because the user login to support-request is not necessary to be a user in ScottyPro(Ticketer).
  * Each form supports the following form components:
    * Textfield: for short text
    * Textarea: for long text, multi-lines
    * Checkbox: with check or times icon
  * Have the ability to show/hide certain fields from the form
    * Hide or hide for a certain value
    * The configuration can be done via form_config and field_config table
      * hidden: to define if a field is going to be hidden from the form view
      * matchValue: when matchValue is presented, the form field will only be hidden when its value match the matchValue

{{ :development:applications:sr-form-list.png?600 |}}


View4: Support Request Form
  * This is for users to send their support requests.
  * Priority options are querying from ScottyPro Ticketer priority configs.
  * Affected Applications options are querying from the Support Request Details form.
  * Point of Contact and CC Emails options are querying from Userprofile user emails. But the user can type their own emails as well.

{{ :development:applications:sr-request-new.png?600 |}}

  * Ability to render dynamic form fields; by selecting available Classification, dynamic form fields will be populated underneath 
    * OPS can define different types of request requirements on request_config table with json, example is below
<code>
  {
  "fields": [
    {
      "name": "title",
      "type": "TEXTFIELD",
      "label": "Report Title",
      "required": true,
      "error": "Please enter the title."
    },
    {
      "name": "purpose",
      "type": "TEXTAREA",
      "label": "Report Purpose",
      "required": true,
      "error": "Please enter the purpose.",
      "desc": "Outlined description of the intended purpose or usage of the report to assist in its development."
    },
    {
      "name": "critical",
      "type": "CHECKBOX",
      "label": "This is a critical issue.",
      "required": false
    },
    {
      "name": "option",
      "type": "DROPDOWN",
      "label": "Follow Call",
      "options": ["YES", "NO"],
      "required": false
    }
  ],
  "applications": [
    "Reporting Manager"
  ]
  }
</code>
  * **fields** to define all the form components to be rendered, 4 types of components are supported: TEXTFIELD, TEXTAREA, DROPDOWN, CHECKBOX
  * **fields** config
    * name: name of the field, should be **unique** for each form
    * type: TEXTFIELD/TEXTAREA/DROPDOWN/CHECKBOX
    * label: the label of the field, free term
    * required: true/false, is the field mandatory
    * error: the message to display when the field didn't pass validation
    * desc: tool-tip behind the field label
    * options: for DROPDOWN only
  * There are basic length limits on all the TEXTFIELD(<=255), TEXTAREA(<=15000)
  * **applications**: the suggested associate applications to be rendered in Affected Areas
  * When the request is submitted, all the info in dynamic fields will be stored in the description field on Support Request Details form as name/value pair.

----

==== Configuration ====

  * The configuration of the APP is placed at application.properties.
  * The configuration for each customer's workflow, visibility etc. are placed in the database named support_request, on the table: config_entry. The initial config of the APP can be loaded from project repo -> initial_db.sql based on the customer.
  * API are under ScottyProController in Ticketer/ScottyPro

----

==== List of Tools & Technologies ====

Backend
  * Groovy 2.4.3
  * Spring Boot 2.2.6.RELEASE
  * JPA
  * REST
  * Security, Includes CAS
Frontend
  * ReactJS

----

==== Appendix ====

For further information see requirements document[[https://drive.google.com/drive/folders/1laRr0Lw7-Oo5bpYuhP1VAnevH9x072_U?usp=sharing|here]]

[[https://bitbucket.org/errigal/support-request/src/dev/|Bitbucket Repo]]

R&D Doc: 
3.20 TBD
[[https://docs.google.com/document/d/1zDfQkwvafyM0-AdJkKEs-X5sXJeSW6jelddexkbj2mE/edit?usp=sharing|3.18]]
[[https://docs.google.com/document/d/1IARK-EqzDOA-wWcyVqp2duYQLr5yNJIwu-YrVTuwWH0/edit?usp=sharing|3.15]]
[[https://docs.google.com/document/d/1by_lWX-y1SdBVOlrseLPCZjVKiQSt4YGELoPNlZQHRg/edit?usp=sharing|3.14]]
[[https://docs.google.com/document/d/1wSALTdpIp_o2DFhfJxxcc9_FEjslpHilzEMpGdyCGwE/edit?usp=sharing|3.13]]

----

==== Operation Tips ====

__**Tips when navigating the Support Request Application.**__

  * Selecting the "Filter" option with no options selected is a quick way of refreshing the page.
  * When searching for tickets make sure you are on the "My Company" page as searching when on "My Tickets" will only return tickets you created.
 

__**ScottyPro Forms and The Support Request Application**__

It is important to remember for any future changes that the Support Request Application displays the fields on a form based on the date/time they were added to the form and not in the order they appear in ScottyPro.
Sidebar

Internal Errigal Collaboration Wiki

User Tools

Site Tools

Page Tools
