[FEATURE REQUEST] Add support subtypes for POST Support Request

[zerwuff]

Is your feature request related to a problem? Please describe.

Extend POST /Support/ with a custom set of more detailed support types.

Urgency

Major

Additional context

As a TO, i want to receive more detailed sub-support types for handling bike damages. We have a set of them to clarify the problem of the bike for operations and what is to fix for the bike. Currently, the main supportTypes are not detailed enough for bike sharing. For communicating this issue types more precise from MP to TO, we would like to have a sub-support types.
A user shall submit up to n sub-support types with one support request, since the asset can have multiple issues.

Describe the solution you'd like

Add new optional field "subTypes" for POST (Entity supportRequest) that can be flexibly defined by the TO.
The type would be a list of damage subtypes. This list contains comma-separated pre-defined enums.

Describe alternatives you've considered

Provide new API that defines the list of possible subtypes
Use comment field.

Possible Implementation

Add new optional field "subTypes" for POST (Entity supportRequest) as type String.

    supportRequest:
      description: request for support
      type: object
      properties:
        id:
          type: string
          description: the booking id
        supportType:
          type: string
          enum: [BROKEN_DOWN, NOT_AT_LOCATION, MISSING_AFTER_PAUSE, NOT_CLEAN, NOT_AVAILABLE, UNABLE_TO_OPEN, UNABLE_TO_CLOSE, API_TECHNICAL, API_FUNCTIONAL, ACCIDENT, OTHER]
        subTypes: <--- new field
          description: a comma-separated list of subtypes that describes the issue with the asset. 
          type: string
          enum: [WHEEL, RING,LIGHT, BRAKE, GEAR, SADDLE, PEDAL, KICKSTAND, RACK,MUD_PROTECTION ]
        location:
          $ref: '#/components/schemas/place'
        time:

The support types can vary from each TO. Some scooter sharers provide lower granularity and have other issues like bike sharing system. To solve this, I would suggest another endpoint that provides that list of sub support types that the MP can fetch from the TO. Actually this is what we do in our B2C apps.

Endpoint name

GET  /supportSubtypes:
        returns list of subtype items   

  subtype definition: 
     id: String
     description: String 

The responsibility to fill in the right value is on the MP side, actually the end user need to select the correct subtypes in the MPs app.
The MP knows all connected TOs and therefore knows the asset <-> to relation, so by sending an damage report he knows asset-wise which TO to call for this request.

[edwinvandenbelt]

We already have the 'damage' concept. Is it an option if we use this in the supportRequest, and make it possible to use a custom classification (since the options are endless)? It overlaps the 'urls' property, but that we should fix in v2.0

supportRequest:
      description: request for support
      type: object
      properties:
        id:
... 
        damage:
          $ref: '#/components/schemas/damage'
        time:

and

damage:
      description: A damage of the vehicle.
      type: object
      required:
        - vehicleComponent
        - description
      properties:
        vehicleComponent:
          description: Part/Component of the vehicle affected. If OTHER is specified the description needs to provide more detail as to what part/component is affected.
          type: string
          enum: [FRONT, REAR, LEFT, RIGHT, TOP, BOTTOM, INTERIOR, TIRE, ANCILLARY, OTHER]
        vehicleComponentName:
          description: a short term to describe the damaged part
          type: string
          x-examples: wheel, ring, light, brake, gear, saddle, pedal, window, rack, ...