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

mkanal commented 2 months ago

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 https://github.com/eclipse-tractusx/traceability-foss/issues/969
relates to https://github.com/eclipse-tractusx/item-relationship-service/issues/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 commented 1 month ago

relates to #561

dsmf commented 2 weeks ago

@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:

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?)
Return Page<Policy>, add another endpoint that can retrieve the BPNs for a list of policyIds (returning Map<BPN, List<policyId>>.
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).
Any other ideas?

dsmf commented 2 weeks ago

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

dsmf commented 2 weeks ago

@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 commented 2 weeks ago

@dsmf please include multi-sort within this story. I will create a story with multi-filter. https://github.com/eclipse-tractusx/item-relationship-service/issues/750

dsmf commented 1 week ago

PRs: https://github.com/eclipse-tractusx/item-relationship-service/pulls?q=is%3Aopen%2Cclosed+is%3Apr+title%3A%22639.*policy+store%22+

all merged and deployed on DEV

dsmf commented 1 week ago

Outcome:

GET /irs/policies/paged

Pagination

[x] pagination with min 1 / max 1000 using Spring's standard pagination structures

Filtering

[x] multi-filter possible &search=...&search=...
[x] filter by BPN search=bpn,[EQUALS|STARTS_WITH],<value>
[x] filter by policyId search=policyId,[EQUALS|STARTS_WITH],<value>
[x] filter by action (first one in permission list is used for filtering), search=action,[EQUALS],[use|access]
filter by createdOn (will be implemented in #750)
filter by validUntil (will be implemented in #750)

Sorting

[x] sort direction asc, desc
[x] default sorting is BPN asc
[x] multi-sort possible `sort=...&sort=...
[x] sort by BPN sort=bpn,[asc|desc]
[x] sort by policyId sort=policyId,[asc|desc]
[x] sort by action (first one in permission list is used for sorting) sort=action,[asc|desc]
[x] sort by createdOn sort=createdOn,[asc|desc]
[x] sort by validUntil sort=validUntil,[asc|desc]

Tests

[x] Unit tests for the new code paging, sorting, filtering, mainly see PolicyPagingServiceTest

Hint: Integration tests can stay as they are temporarily because the old endpoint without paging is not removed in order to keep backward compatibility until the frontend is adapted.