[Feature Request]: apply complex filtering logic to estate request

What happened?

In the onoffice client one can define complex logical filters onto the requested estates. If possible one should be able to apply a similiary complex logic onto the estates during a request. Right now the best that can be done is to define the filter in onoffice, save it and give onoffice the filterid with the request and/or apply filter simple "and"-chained field value filter onto the request with the ->where operation

How to reproduce the bug

no way to reproduce. Feature request

Package Version

n/a

PHP Version

n/a

Laravel Version

n/a

Which operating systems does with happen with?

No response

Notes

Here is an example of binary logical sql operations that can be applied to the estaterequest.

ORs sind nicht wie in UI-Filtern via API umsetzbar, siehe docs:

filter

OBJECT. Ignored if resourceid is set. Key: field, value: array of objects with filter expressions in the format "status": [{"op": "=", "val": 1}]. With op you specify the operator. Possible values for op are the following SQL operators: is or =, >, <, >=, <=, != or <>, between, like, not like, in, not in For the operator like the value % can be specified as a placeholder.

With val you specify the value which should be applied to the filtering. The individual filter expressions are linked with the AND operation. Multiple values or ranges for operators like IN or BETWEEN are specified in comma separated array notation.
"objektart": [{"op": "IN","val": ["Zimmer","Haus"]}], "letzte_aktion ": [{"op": "BETWEEN","val": ["2020-01-01","2021-04-01"]}]}

{
    "actionid": "urn:onoffice-de-ns:smart:2.5:smartml:action:read",
    "resourceid": "",
    "identifier": "",
    "resourcetype": "estate",
    "parameters": {
        "data":["Id", "kaufpreis", "reserviert", "verkauft"],
        "filter": {
            "status": [{"op": "=", "val": 1}],
            "kaufpreis": [{"op": "<", "val": 300000}]
        }
    }

Es gibt also keinen or operator. Alle Feldbedingungen sind somit immer als and Verknüpft. Wenn es einen OR Operator in der Liste gäbe, wären wir immer noch nur auf ORs innerhalb von Feldern limitiert, da ein Feld immer Key sein muss, anders als bei dem freien Filter String im UI. Feldübergreifende Logik ist also nur ausserhalb der API möglich.

Theoretisch ist das dann im Package grundsätzlich machbar, jedoch müsste man hier pro OR (wenn man nur eine Ebene an ORs ohne Verschachtelung betrachtet) einen eigenen (oder mehrere, bei mehr als 500 Ergebnissen pro OR-Anfrage) Request machen, und dann die Ergebnisse mergen. Bei verschachtelten Bedingungen müssten wir die Logikstruktur dann lokal aufbauen und abarbeiten.

Aufwand/Nutzen ist hier vorerst schwer zu rechtfertigen. Auch müsste aus Nutzersicht auf den potentiell hohen Overhead aufmerksam gemacht werden, gerade bei großen Mandanten.

innobraingmbh / laravel-onoffice-adapter