[albertoramosmonagas]

What type of PR is this?

Add one of the following kinds:

• documentation
• tests

What this PR does / why we need it:

Addresses the documentation gaps on OUT_OF_RANGE and the definition of "tenure" reported during the r3.3 release review, and fixes the rendering of the mandatory blocks in info.description.

• info.description:
  • adds a definition of "tenure" at the beginning;
  • documents the CSP regulatory threshold for tenureDate, with an outcome table, worked examples and an example 400 OUT_OF_RANGE response;
  • documents a future tenureDate (D > T) as 400 OUT_OF_RANGE (proposal, see notes below);
  • replaces "MNO" with "CSP", the term used in the API;
  • adds a blank line after each mandatory BEGIN marker so Swagger tools render the following heading correctly.
• kyc-tenure.feature:
  • adds scenarios for tenureDateCheck false (subscription started after tenureDate, within the threshold) and true (subscription started before the threshold);
  • adds scenario @checkTenure_400.05_out_of_range_future_date.

No change to the API schema.

Which issue(s) this PR fixes:

Fixes #107
Fixes #109
Fixes #110
Fixes #111

Special notes for reviewers:

• The outcome table (R = regulatory threshold date, D = tenureDate, S = subscription start date, T = today) is taken from the proposal in the issue.

Changelog input

 release-note
Clarify the definition of tenure and the OUT_OF_RANGE behaviour (regulatory threshold, future tenureDate) in the API description and test scenarios; add a blank line after the mandatory BEGIN markers in info.description

[albertoramosmonagas]

Hi @camaraproject/tenure_codeowners,

This PR documents the following behaviour for tenureDate, based on the proposal in the issue #107 (R = regulatory threshold date, D = tenureDate, T = today):

• D < R: 400 OUT_OF_RANGE
• R ≤ D ≤ T: 200, with true/false depending on the subscription start date

It also adds D > T (future tenureDate) → 400 OUT_OF_RANGE, based on the note in the issue. This is a proposal, not an agreed behaviour: the current .feature already requires “a valid past date” in the happy paths, which suggests a future date is not valid, but the API definition does not say so. Should a future date return 400 OUT_OF_RANGE or 400 INVALID_ARGUMENT?

The description and the .feature (new scenario @checkTenure_400.05_out_of_range_future_date) are updated accordingly. Please reach consensus on this point before merging.

CC: @tanjadegroot (from release management)