Explore usage of v1.1 and v1.0 with same mojaloop release #2660

elnyry-sam-k · 2022-02-03T06:50:31Z

mdebarros · 2022-02-04T09:10:48Z

Delta changes

Background

Currently, the Content-type is validated against a single value injected by a config (e.g. ml-api-adapter) that matches as follows:

"PROTOCOL_VERSIONS": {
    "CONTENT": "1.1", <-- used to validate incoming CONTENT-TYPE header, and value used for content-type headers when requests are generated by the "switch"
    "ACCEPT": {
      "DEFAULT": "1",  <--  value used for ACCEPT headers when requests are generated by the "switch"
      "VALIDATELIST": [ <-- used to validate incoming accept headers
        "1",
        "1.1"
      ]
    }
  }

These changes have been introduced as fixes for the mojaloop/project//issues/2536 bug which has been included in the WIP v13.1.0 release.

Code changes

To simplify and improve backward compatibility, I propose the following changes:

Config Changes

Split the CONTENT section to match the ACCEPT structure as follows:

"PROTOCOL_VERSIONS": {
    "CONTENT": {
      "DEFAULT": "1.1", <--  value used for CONTENT-TYPE headers when requests are generated by the "switch"
      "VALIDATELIST": [ <-- used to validate incoming CONTENT-TYPE headers
        "1.0",
        "1.1"
      ]
    }
    "ACCEPT": {
      "DEFAULT": "1", <--  value used for ACCEPT headers when requests are generated by the "switch"
      "VALIDATELIST": [ <-- used to validate incoming ACCEPT headers
        "1",
        "1.0",
        "1.1"
      ]
    }
  }

Central-Services-Shared

Update the headerValidation HAPIjs Plugin to support the above-proposed changes.

Update core-service to support the above structural change

i. Update config/default.json to support the above-proposed changes.
ii. Update the src/lib/config.js --> getProtocolVersions function to support the above-proposed changes, and also include additional regex validation for CONTENT's DEFAULT & VALIDATELIST values as they must match #.# (i.e. only ACCEPT can contain single digits, e.g. 1).
iii. Update the [src/src/shared/plugins.js--> getOptionsForFSPIOPHeaderValidation] function to support the above-proposed changes.
iv. Update NPM dependency for the central-services-shared release that includes the above-proposed changes.

The following components will need to be updated with the above changes:

bulk-api-adapter
transaction-request-service
quoting-service
account-lookup-service
ml-api-adapter

API Services should validate in-coming requests against the appropriate swagger for FSPIOP v1.0 vs v1.1 based on the CONTENT-TYPE header

i. Add support to OpenApiBackend util & plugins @mojaloop/central-services-shared.Util.OpenapiBackend to correctly validate the incoming request against the corresponding FSPIOP swagger versions by matching the version against the CONTENT-TYPE header.

The following components will need to be updated with the above changes:

bulk-api-adapter
transaction-request-service
quoting-service
account-lookup-service
ml-api-adapter (Note: this has not been migrated to utilise the OpenApiBackend util/plugin)

Helm chart changes

The following Helm charts will need to be update to support the config changes proposed above:

bulk-api-adapter <-- default config + deployment template
transaction-request-service <-- default config + deployment template
quoting-service <-- default config + deployment template
account-lookup-service <-- default config + deployment template
ml-api-adapter <-- default config + deployment template
mojaloop <-- default config for the above child-charts

Quality Assurance

The following functional tests are required to fully test and validate FSPIOP backward compatibility support, but before that we must first ensure the following Actors have been defined and configured on the test environment:

Actor	Description	Configured FSPIOP Version	Notes
FSP1	FSP	1.0	FSP has been configured to send requests for FSPIOP v1.0 but still support v1.1
FSP2	FSP	1.0	FSP has been configured to send requests for FSPIOP v1.0 but still support v1.1
FSP3	FSP	1.1	FSP has been configured to send requests for FSPIOP v1.0 but still support v1.1
FSP4	FSP	1.1	FSP has been configured to send requests for FSPIOP v1.0 but still support v1.1
SWITCH	Hub	1.1

The test scenarios make the assumption that all actors support the latest FSPIOP v1.1, but some have been configured to operate at v1.0 for testing purposes. This is why Scenario 4 is possible. In the situation where the sender FSP

All tests must validate CONTENT-TYPE & ACCEPT headers for involved actors.

Scenario - FSPIOP v1.0 End-to-end

Request flow : FSP1 -v1.0-> SWITCH -v1.0-> FSP2

Callback flow: FSP1 <-v1.0- SWITCH <-v1.0- FSP2

Test-cases:

#	Type	Case	Notes
1.1	Success	Fulfil status = 'COMMITTED'
1.2	Success	Error callback to abort transfer
1.3	Failure	Fulfil status = 'ABORTED'
1.4	Failure	Fulfil status = 'RESERVED' (i.e. PATCH NOTIFICATION not supported)
1.5	Failure	GET /Parties PUT-Callback fails validation when including extensionList	Dependant on `4. API Services should validate in-coming requests against the appropriate swagger for FSPIOP v1.0 vs v1.1 based on the CONTENT-TYPE header`
1.6	Failure	PATCH Callback fail validation	Dependant on `4. API Services should validate in-coming requests against the appropriate swagger for FSPIOP v1.0 vs v1.1 based on the CONTENT-TYPE header`

Scenario - FSPIOP v1.1 End-to-end

Request flow : FSP3 -v1.1-> SWITCH -v1.1-> FSP4

Callback flow: FSP3 <-v1.1- SWITCH <-v1.1- FSP4

Test-cases:

#	Type	Case
2.1	Success	Fulfil status = 'COMMITTED'
2.2	Success	Fulfil status = 'RESERVED' (i.e. PATCH NOTIFICATION)
2.3	Success	Error callback to abort transfer
2.4	Failure	Fulfil status = 'RESERVED' (i.e. PATCH NOTIFICATION) with validation failure (e.g. none matching fulfillment-condition)
2.5	Failure	Fulfil status = 'ABORTED'

Scenario - FSPIOP v1.0 -> v1.1 End-to-end

Request flow : FSP1 -v1.0-> SWITCH -v1.0-> FSP4

Callback flow: FSP1 <-v1.1- SWITCH <-v1.1- FSP4

Test-cases:

#	Type	Case
3.1	Success	Fulfil status = 'COMMITTED'
3.2	Success	Fulfil status = 'RESERVED' (i.e. PATCH NOTIFICATION)
3.3	Success	Error callback to abort transfer
3.4	Failure	Fulfil status = 'RESERVED' (i.e. PATCH NOTIFICATION) with validation failure (e.g. none matching fulfillment-condition)
3.5	Failure	Fulfil status = 'ABORTED'

Scenario - FSPIOP v1.1 -> v1.0 End-to-end

Request flow : FSP3 -v1.1-> SWITCH -v1.1-> FSP2

Callback flow: FSP3 <-v1.0- SWITCH <-v1.0- FSP2

Test-cases:

#	Type	Case	Notes
4.1	Success	Fulfil status = 'COMMITTED'
4.2	Success	Fulfil status = 'RESERVED' (i.e. PATCH NOTIFICATION)
4.3	Success	Error callback to abort transfer
4.4	Failure	Fulfil status = 'RESERVED' (i.e. PATCH NOTIFICATION) with validation failure (e.g. none matching fulfillment-condition)
4.5	Failure	Fulfil status = 'ABORTED'
4.6	Failure	GET /Parties PUT-Callback fails validation when including extensionList	Dependant on `4. API Services should validate in-coming requests against the appropriate swagger for FSPIOP v1.0 vs v1.1 based on the CONTENT-TYPE header`
4.7	Failure	PATCH Callback fail validation	Dependant on `4. API Services should validate in-coming requests against the appropriate swagger for FSPIOP v1.0 vs v1.1 based on the CONTENT-TYPE header`

Note: This scenario is only possible because FSP3 does support FSPIOP v1.1, but has been configured to generate requests with FSPIOP v1.0. If FSP3 only supported FSPIOP v1.0, then the callback is expected to fail since FSP3 would not support FSPIOP v1.1 protocols. See point 2 in considerations.

Considerations

SDK-Scheme-adapter does not utilise the same approach described in the above#Background section and we should consider standardizing it in the same manner for consistency.
The test scenarios make the assumption that all actors support the latest FSPIOP v1.1, but some have been configured to operate at v1.0 for testing purposes. This begs the question if we should consider running tests against FSPs (e.g. pre-FSPIOP-v1.1 SDK-Scheme-Adapter/mojaloop-simulator versions) that ONLY support v1.0?
Code-change 4. API Services should validate in-coming requests against the appropriate swagger for FSPIOP v1.0 vs v1.1 based on the CONTENT-TYPE header will require the most effort to implement because the OpenAPIBackend Plugin will require re-factoring to accommodate the loading of multiple Swaggers documents, and the ml-api-adapter has not been migrated to use the OpenAPIBackend Plugin).

mdebarros · 2022-02-10T09:08:32Z

Further thinking about this, and taking into consideration that the swagger already validates the incoming CONTENT-TYPE to make sure it matches a #.# pattern, i.e. it will fail validation up-front if someone sends the following: application/vnd.interoperability.transfers+json;version=1

This will result in the following sync error:

{
  "status": 400,
  "statusText": "Bad Request",
  "body": {
    "errorInformation": {
      "errorCode": "3101",
      "errorDescription": "Malformed syntax - Invalid content-type header"
    }
  },
  "headers": {
    "content-type": "application/json; charset=utf-8",
    "cache-control": "no-cache",
    "content-length": "109",
    "date": "Thu, 10 Feb 2022 08:54:36 GMT",
    "connection": "keep-alive"
  }
}

Taking this into consideration, we could further simplify the config to the following:

"PROTOCOL_VERSIONS": {
  "CONTENT": {
    "DEFAULT": "1.1", <-- same as initial proposal
  }
  "ACCEPT": {
    "DEFAULT": "1",  <-- same as initial proposal
  },
  "VALIDATELIST": [ <-- used to validate incoming ACCEPT & CONTENT-TYPE headers
    "1", <-- this would be filtered out by the swagger validation for CONTENT-TYPE, but it does make the assumption that the swagger will always filter out this kind of request which is a concern.
    "1.0",
    "1.1"
  ]
}

However, I am still leaning toward my initial proposal based on my in-line comment above.

Just including this here as part of the thought process.

… api compatibility - updated FSPIOPHeaderValidation options based on mojaloop/project#2660 to accept a validationList for the content-type - updated dependencies - fixed audit issues

… api compatibility - updated default.json based on mojaloop/project#2660 - re-factored config to load the changes correctly - updated plugins to correctly configure the FSPIOPHeaderValidation options - fixed unit tests TODO: update latest central-services-shared release after merging mojaloop/central-services-shared#325

… api compatibility - updated default.json config for PROTOCOL_VERSIONS, and updated related usage based on mojaloop/project#2660 to accept a validationList for the content-type - updated dependencies - fixed audit issues - fixed unit tests

… api compatibility (#325) feat(mojaloop/#2704): core-services support for non-breaking backward api compatibility - mojaloop/project#2704 - updated FSPIOPHeaderValidation options based on mojaloop/project#2660 to accept a validationList for the content-type - updated dependencies - fixed audit issues BREAKING CHANGE: - headerValidation.FSPIOPHeaderValidation now expects the`supportedProtocolContentVersions` options argument to be a list, the same as `supportedProtocolAcceptVersions`

… api compatibility - updated default.json config for PROTOCOL_VERSIONS, and updated related usage based on mojaloop/project#2660 to accept a validationList for the content-type - updated dependencies - fixed audit issues - fixed unit tests

… api compatibility (#496) feat(mojaloop/#2704): core-services support for non-breaking backward api compatibility - mojaloop/project#2704 - updated default.json config for PROTOCOL_VERSIONS, and updated related usage based on mojaloop/project#2660 to accept a validationList for the content-type - updated dependencies - fixed audit issues - fixed unit tests BREAKING CHANGE: - Config PROTOCOL_VERSIONS.CONTENT has now been modified to support backward compatibility for minor versions (i.e. v1.0 & 1.1) as follows: > ``` > "PROTOCOL_VERSIONS": { > "CONTENT": "1.1", <-- used when generating messages from the "SWITCH", and validate incoming FSPIOP API requests/callbacks CONTENT-TYPE headers > "ACCEPT": { > "DEFAULT": "1", <-- used when generating messages from the "SWITCH" > "VALIDATELIST": [ <-- used to validate incoming FSPIOP API requests/callbacks ACCEPT headers > "1", > "1.0", > "1.1" > ] > } > }, > ``` > > to be consistent with the ACCEPT structure as follows: > > ``` > "PROTOCOL_VERSIONS": { > "CONTENT": { > "DEFAULT": "1.1", <-- used when generating messages from the "SWITCH" > "VALIDATELIST": [ <-- used to validate incoming FSPIOP API requests/callbacks CONTENT-TYPE headers > "1.1", > "1.0" > ] > }, > "ACCEPT": { > "DEFAULT": "1", <-- used when generating messages from the "SWITCH" > "VALIDATELIST": [ <-- used to validate incoming FSPIOP API requests/callbacks ACCEPT headers > "1", > "1.0", > "1.1" > ] > } > }, > ```

… api compatibility (#295) feat(mojaloop/#2704): core-services support for non-breaking backward api compatibility - mojaloop/project#2704 - updated default.json config for PROTOCOL_VERSIONS, and updated related usage based on mojaloop/project#2660 to accept a validationList for the content-type - updated dependencies - fixed audit issues - fixed unit tests BREAKING CHANGE: - Config PROTOCOL_VERSIONS.CONTENT has now been modified to support backward compatibility for minor versions (i.e. v1.0 & 1.1) as follows: > ``` > "PROTOCOL_VERSIONS": { > "CONTENT": "1.1", <-- used when generating messages from the "SWITCH", and validate incoming FSPIOP API requests/callbacks CONTENT-TYPE headers > "ACCEPT": { > "DEFAULT": "1", <-- used when generating messages from the "SWITCH" > "VALIDATELIST": [ <-- used to validate incoming FSPIOP API requests/callbacks ACCEPT headers > "1", > "1.0", > "1.1" > ] > } > }, > ``` > > to be consistent with the ACCEPT structure as follows: > > ``` > "PROTOCOL_VERSIONS": { > "CONTENT": { > "DEFAULT": "1.1", <-- used when generating messages from the "SWITCH" > "VALIDATELIST": [ <-- used to validate incoming FSPIOP API requests/callbacks CONTENT-TYPE headers > "1.1", > "1.0" > ] > }, > "ACCEPT": { > "DEFAULT": "1", <-- used when generating messages from the "SWITCH" > "VALIDATELIST": [ <-- used to validate incoming FSPIOP API requests/callbacks ACCEPT headers > "1", > "1.0", > "1.1" > ] > } > }, > ```

… api compatibility (#436) feat(mojaloop/#2704): core-services support for non-breaking backward api compatibility - mojaloop/project#2704 - updated default.json config for PROTOCOL_VERSIONS, and updated related usage based on mojaloop/project#2660 to accept a validationList for the content-type - updated dependencies - fixed audit issues - fixed unit tests BREAKING CHANGE: - Config PROTOCOL_VERSIONS.CONTENT has now been modified to support backward compatibility for minor versions (i.e. v1.0 & 1.1) as follows: > ``` > "PROTOCOL_VERSIONS": { > "CONTENT": "1.1", <-- used when generating messages from the "SWITCH", and validate incoming FSPIOP API requests/callbacks CONTENT-TYPE headers > "ACCEPT": { > "DEFAULT": "1", <-- used when generating messages from the "SWITCH" > "VALIDATELIST": [ <-- used to validate incoming FSPIOP API requests/callbacks ACCEPT headers > "1", > "1.0", > "1.1" > ] > } > }, > ``` > > to be consistent with the ACCEPT structure as follows: > > ``` > "PROTOCOL_VERSIONS": { > "CONTENT": { > "DEFAULT": "1.1", <-- used when generating messages from the "SWITCH" > "VALIDATELIST": [ <-- used to validate incoming FSPIOP API requests/callbacks CONTENT-TYPE headers > "1.1", > "1.0" > ] > }, > "ACCEPT": { > "DEFAULT": "1", <-- used when generating messages from the "SWITCH" > "VALIDATELIST": [ <-- used to validate incoming FSPIOP API requests/callbacks ACCEPT headers > "1", > "1.0", > "1.1" > ] > } > }, > ```

… api compatibility (#85) feat(mojaloop/#2704): core-services support for non-breaking backward api compatibility - mojaloop/project#2704 - updated default.json config for PROTOCOL_VERSIONS, and updated related usage based on mojaloop/project#2660 to accept a validationList for the content-type - updated dependencies - fixed audit issues - fixed unit tests BREAKING CHANGE: - Config PROTOCOL_VERSIONS.CONTENT has now been modified to support backward compatibility for minor versions (i.e. v1.0 & 1.1) as follows: > ``` > "PROTOCOL_VERSIONS": { > "CONTENT": "1.1", <-- used when generating messages from the "SWITCH", and validate incoming FSPIOP API requests/callbacks CONTENT-TYPE headers > "ACCEPT": { > "DEFAULT": "1", <-- used when generating messages from the "SWITCH" > "VALIDATELIST": [ <-- used to validate incoming FSPIOP API requests/callbacks ACCEPT headers > "1", > "1.0", > "1.1" > ] > } > }, > ``` > > to be consistent with the ACCEPT structure as follows: > > ``` > "PROTOCOL_VERSIONS": { > "CONTENT": { > "DEFAULT": "1.1", <-- used when generating messages from the "SWITCH" > "VALIDATELIST": [ <-- used to validate incoming FSPIOP API requests/callbacks CONTENT-TYPE headers > "1.1", > "1.0" > ] > }, > "ACCEPT": { > "DEFAULT": "1", <-- used when generating messages from the "SWITCH" > "VALIDATELIST": [ <-- used to validate incoming FSPIOP API requests/callbacks ACCEPT headers > "1", > "1.0", > "1.1" > ] > } > }, > ```

… api compatibility (#74) feat(mojaloop/#2704): core-services support for non-breaking backward api compatibility - mojaloop/project#2704 - updated default.json config for PROTOCOL_VERSIONS, and updated related usage based on mojaloop/project#2660 to accept a validationList for the content-type - updated dependencies - fixed audit issues - fixed unit tests BREAKING CHANGE: - Config PROTOCOL_VERSIONS.CONTENT has now been modified to support backward compatibility for minor versions (i.e. v1.0 & 1.1) as follows: > ``` > "PROTOCOL_VERSIONS": { > "CONTENT": "1.1", <-- used when generating messages from the "SWITCH", and validate incoming FSPIOP API requests/callbacks CONTENT-TYPE headers > "ACCEPT": { > "DEFAULT": "1", <-- used when generating messages from the "SWITCH" > "VALIDATELIST": [ <-- used to validate incoming FSPIOP API requests/callbacks ACCEPT headers > "1", > "1.0", > "1.1" > ] > } > }, > ``` > > to be consistent with the ACCEPT structure as follows: > > ``` > "PROTOCOL_VERSIONS": { > "CONTENT": { > "DEFAULT": "1.1", <-- used when generating messages from the "SWITCH" > "VALIDATELIST": [ <-- used to validate incoming FSPIOP API requests/callbacks CONTENT-TYPE headers > "1.1", > "1.0" > ] > }, > "ACCEPT": { > "DEFAULT": "1", <-- used when generating messages from the "SWITCH" > "VALIDATELIST": [ <-- used to validate incoming FSPIOP API requests/callbacks ACCEPT headers > "1", > "1.0", > "1.1" > ] > } > }, > ```

mdebarros · 2022-03-07T13:19:44Z

The following stories/issues have been created as a result of this investigation:

Core-services support for non-breaking backward API compatibility for PROTOCOL_VERSION configs - Core-services support for non-breaking backward API compatibility for PROTOCOL_VERSION configs #2704
API-Snippets to support generating backwards compatible OpenAPI Definitions API-Snippets to support generating backwards compatible OpenAPI Definitions #2706
API-Snippets to support generating backwards compatible OpenAPI Definitions #2706
Integrate API-Snippets into Core components - Integrate API-Snippets into Core components #2708
GP tests to validate backward compatibility use-cases - GP tests to validate backward compatibility use-cases #2709
OpenAPI Backend Plugin to support multiple OpenAPI Definition for validating incoming FSPIOP API requests - OpenAPI Backend Plugin to support multiple OpenAPI Definition for validating incoming FSPIOP API requests #2710
API Validations against multiple OpenAPI definitions to support backward compatibility API Validations against multiple OpenAPI definitions to support backward compatibility #2707
API Validations against multiple OpenAPI definitions to support backward compatibility #2707

Notes:

The above list is not ordered or prioritised in any way
The above stories need to be refined, and most likely further broken down into smaller stories

mdebarros · 2022-03-07T13:42:37Z

The following stories/issues have been created as a result of this investigation:
...

@elnyry-sam-k am I missing anything from this list?

… api compatibility (#66) feat(mojaloop/[#2704](https://github.com/mdebarros/ml-api-adapter/issues/2704)): core-services support for non-breaking backward api compatibility - mojaloop/project#2704 - added new feature_test: collections/hub/golden_path/feature_tests/backward_compatibility/fspiop_protocol_validation.json which asserts validations against correct current, old and not-supported versions for parties, quotes, transfers, and transactionRequests - added new feature_test: collections/hub/other_tests/bulk_transfers/fspiop_protocol_validation.json which asserts validations against correct current, old and not-supported versions for bulkTransfers These are a sub-set of tests as a result of the following investigatory issue: mojaloop/project#2660

elnyry-sam-k · 2022-03-07T17:30:46Z

Thanks Miguel..

I've added a dependency for #2707 on #2710 and apart from documentation, this list looks good..

Closing this story for no

elnyry-sam-k added story oss-core This is an issue - story or epic related to a feature on a Mojaloop core service or related to it labels Feb 3, 2022

elnyry-sam-k mentioned this issue Feb 3, 2022

Helm release v13.1.0 #2528

Closed

46 tasks

elnyry-sam-k added this to the Sprint 17.1 milestone Feb 4, 2022

mdebarros mentioned this issue Mar 2, 2022

feat(mojaloop/#2704): core-services support for non-breaking backward api compatibility mojaloop/central-services-shared#325

Merged

mdebarros mentioned this issue Mar 3, 2022

feat(mojaloop/#2704): core-services support for non-breaking backward api compatibility mojaloop/ml-api-adapter#496

Merged

mdebarros mentioned this issue Mar 3, 2022

feat(mojaloop/#2704): core-services support for non-breaking backward api compatibility mojaloop/quoting-service#295

Merged

mdebarros mentioned this issue Mar 3, 2022

feat(mojaloop/#2704): core-services support for non-breaking backward api compatibility mojaloop/account-lookup-service#436

Merged

mdebarros mentioned this issue Mar 3, 2022

feat(mojaloop/#2704): core-services support for non-breaking backward api compatibility mojaloop/bulk-api-adapter#74

Merged

mdebarros mentioned this issue Mar 3, 2022

feat(mojaloop/#2704): core-services support for non-breaking backward api compatibility mojaloop/transaction-requests-service#85

Merged

mdebarros mentioned this issue Mar 4, 2022

feat(mojaloop/#2704): core-services support for non-breaking backward api compatibility mojaloop/testing-toolkit-test-cases#66

Merged

elnyry-sam-k modified the milestones: Sprint 17.1, Sprint 17.3 Mar 7, 2022

elnyry-sam-k assigned mdebarros Mar 7, 2022

elnyry-sam-k closed this as completed Mar 7, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Explore usage of v1.1 and v1.0 with same mojaloop release #2660

Explore usage of v1.1 and v1.0 with same mojaloop release #2660

elnyry-sam-k commented Feb 3, 2022 •

edited

Loading

mdebarros commented Feb 4, 2022 •

edited

Loading

mdebarros commented Feb 10, 2022 •

edited

Loading

mdebarros commented Mar 7, 2022 •

edited

Loading

mdebarros commented Mar 7, 2022 •

edited

Loading

elnyry-sam-k commented Mar 7, 2022

Explore usage of v1.1 and v1.0 with same mojaloop release #2660

Explore usage of v1.1 and v1.0 with same mojaloop release #2660

Comments

elnyry-sam-k commented Feb 3, 2022 • edited Loading

Goal:

Pull Requests:

Follow-up:

Accountability:

mdebarros commented Feb 4, 2022 • edited Loading

Delta changes

Background

Code changes

Helm chart changes

Quality Assurance

Considerations

mdebarros commented Feb 10, 2022 • edited Loading

mdebarros commented Mar 7, 2022 • edited Loading

mdebarros commented Mar 7, 2022 • edited Loading

elnyry-sam-k commented Mar 7, 2022

elnyry-sam-k commented Feb 3, 2022 •

edited

Loading

mdebarros commented Feb 4, 2022 •

edited

Loading

mdebarros commented Feb 10, 2022 •

edited

Loading

mdebarros commented Mar 7, 2022 •

edited

Loading

mdebarros commented Mar 7, 2022 •

edited

Loading