[FEATURE REQUEST] support use cases: demage report and info regarding existing damages

[matt-wirtz]

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

When renting a shared car the user is required to check the condition of the car at the start of his rental. Most important is to compare the condition with what is stated in the known damages list. If there are any damages not yet listed it's necessary to report these damages before starting the trip. Therefore the use cases:

• get info regarding existing damages
• report new damages

should be supported by the TOMP-API.

Urgency

Major, because integrations might not be possible if the TO uses already a digital only damage info process.

Additional context

The use case "get info regarding existing damages" seems to be related mostly to car sharing. The use case "report new damages" seems to be applicable to all sharing types. But again with probably higher relevance for car sharing.

Describe the solution you'd like

The above mentioned use cases should be incorporated.

Describe alternatives you've considered

Possible Implementation

Not yet worked out, in progress.

[edwinvandenbelt]

Good morning! I think you're just in time, we planned a version 1.5 in December. Your issues seem logical, but the enlisting of the reported damages is new to me. The other one, reporting damage is only possible at the end of the trip, where you can supply proof with photos at the parking spot.

I propose:

• extending the 'asset' with an array of strings (or should we formalize this more), so when offering something (or after the commit) you can see what's wrong with this asset
• extending the supportType with 'DAMAGE_REPORT', so you can submit a supportRequest with some comments and photos (in the URLs array).

Do these extensions fulfill your requests?

[matt-wirtz]

Hi! For the use case "existing damages" I extended the "asset" object as suggested. To be more precise I extended the assetProperties. Since the assetProperties are included in several endpoints, e.g. the planning endpoints, it might be necessary to include the existing damages info only when necessary.

In order to only include the damage info when necessary - probably mostly when in the trip execution phase prepare - should there be a request parameter in the call to POST /legs/{id}/event indicating that the TO should append the damage info. And if the request parameter is not set then no damage info will be appended.

Another option would be to have the existing damages not included in the assetProperties but in an different object e.g. "assetDamages". This could then be part of /legs/{id}/event and only there. Which sounds to be much more suitable.

[edwinvandenbelt]

Hello Matthias, for your information, the 'assetProperties' object is also used in the assetType, to specify the shared properties over all assets in that type (like the type 'yellow bike', where the assetProperties object (field: sharedProperties) contains a field 'color': 'yellow'). So, in this case, putting it in the asset object is more appropriate to give an overview of existing damage. ( the "housewife's rule": everything has its own place and everything is in its own place). It is reported damage of one specific asset, and is not really a candidate for grouping assets. And, yes, please create an object for the damage, so there can be introduced a new field in the asset, containing an array of these Damage objects. If it is a field in the asset, please do not repeat 'asset' in the field name.

Regarding the reporting of new damage, I think it should be in the support module, in the POST /support/ with body { "supportType": "REPORT_DAMAGE", "assetDamage": {your Damage object} }. This way new damage can be reported at any time. However, it might be wise to include in the onBoardingSteps an additional step 'REPORT_UNSEEN_DAMAGES'.

Is this doable?