[POLICY_STORE] Add filter, sorting, pagination for GET endpoints

[mkanal]

As business app Trace-X
I want use filter, sorting, pagination for GET endpoints
so that we could visualize the data in a sufficient way

Links

• Relates to [POLICY][BE] Add multi filter, cascading sorting, pagination to policy view traceability-foss#969
• relates to [POLICY_STORE] Multi-Filter support for API endpoint GET /irs/policies #750

Hints / Details

• ...

Acceptance Criteria

• policy store GET endpoints supporting GET /irs/policies
  • filtering on attributes [BPN, validUntil, policyId, createdOn, action,]
    • For filtering on attribute action first permission entry in array is used
  • sorting on attributes [BPN, validUntil, policyId, createdOn, action,] asc, desc, default sorting is BPN asc
    • For sorting on attribute action first permission entry in array is used
  • pagination min 1 / max 1000
• Update Insomnia
• Update documentation
• Update tests

Out of Scope

• sorting on attributes [constraint,]
• filter on attribute [constraint]

[dsmf]

relates to #561

[dsmf]

@mkanal:
The current implementation GET /irs/policies returns a map of policies, not a list (because BPN is not part of the policy entity itself). See the following result:

{
	"BPNL1234567890AB": [
		... policies ...
	]
}

How should the paging work here?
Returning Page<Policy> would not transfer the information to which BPN it belongs.
Returning Map<BPN, Page<Policy>> would convey the BPN information, but this feels wrong either and probably isn't what is needed.

Brainstorming options for harmonizing the BPN policy relationship with paging:

1. Add BPN as an attribute to Policy and return Page<Policy>>. (This seems to me to be the best option, as this would be the default way of paging and thus the easiest option to understand. But: Are we allowed to extend the policy structure in this way?)
2. Return Page<Policy>, add another endpoint that can retrieve the BPNs for a list of policyIds (returning Map<BPN, List<policyId>>.
3. Return a wrapper structure that encloses Page<Policy> and a Map<BPN, List<policyId>> to also transmit the BPN policy relationship (without needing additional queries).
4. Any other ideas?

[dsmf]

discussed with @ds-mwesener:
we add bpn on the same level as validUntil and return a paged list instead of map

[dsmf]

@mkanal: @ds-mwesener said they need multi-sort and multi-filter (with flexible sort operators). Single-sort is no problem. Maybe multi-sort can be implemented within the estimation too, but multi-filter goes far beyond the acceptance criteria in this story and cannot be implemented within the estimation.

Example requests to show how their multi-sort and multi-filter are designed:

multi-sort:

https://traceability.dev.demo.catena-x.net/api/assets/as-built
    ?page=0&size=50
    &sort=id,asc
    &sort=idShort,asc

multi-filter:

https://traceability.dev.demo.catena-x.net/api/assets/as-built
    ?filter=semanticDataModel%2CEQUAL%2CBATCH%2COR
    &filter=semanticDataModel%2CEQUAL%2CSERIALPART%2COR'

suggestion: leave out the filter in this story completely and add new PBI(s) for multi-sort and multi-filter.

[mkanal]

@dsmf please include multi-sort within this story. I will create a story with multi-filter. #750

[dsmf]

Thanks, @mkanal. I'll update the documentation and add some handling for the date format exeption to map to a BAD_REQUEST with a more user friendly message instead.

[dsmf]

PR for documentation improvement

#830

PR for date format exception handling

#831

PR for improvement of IrsApplicationTests.generatedOpenApiMatchesContract

(because I noticed during documentation improvement above that the ignores seem to be obsolete).
#832

[dsmf]

PR to support any ISO date in date search filters for createdOn and validUntil

#844

[dsmf]

PR for deprecation note for old endpoint GET /irs/policies

#845

[dsmf]

deployed to DEV:

• deprecation note for old endpoint GET /irs/policies
• date filters support any ISO date now, not just yyyy-MM-dd

[mkanal]

LGFM. PO acceptance in behalf of @jzbmw