feat: add backend for new user/group column

[enjeck]

Contributes to #586

This adds to the backend to support adding a new column that receives users or groups.

We expect the row values of this column to be array of objects with format {id: string, type: int}

Creating a column

Request

curl --silent \
    -X POST \
    -u admin:admin \
    -H "OCS-APIRequest: true" \
    -H "Content-Type: application/json" \
    -d '{ "baseNodeId": 1, "title": "New Column", "usergroupDefault": "[{\"id\": \"admin\", \"type\": 0}]" }' \
'http://nextcloud.local/ocs/v2.php/apps/tables/api/2/columns/usergroup?format=json' | jq

Result

{
  "ocs": {
    "meta": {
      "status": "ok",
      "statuscode": 200,
      "message": "OK"
    },
    "data": {
      "id": 7,
      "tableId": 1,
      "title": "New Column",
      "createdBy": "admin",
      "createdByDisplayName": "admin",
      "createdAt": "2024-05-13 15:25:29",
      "lastEditBy": "admin",
      "lastEditByDisplayName": "admin",
      "lastEditAt": "2024-05-13 15:25:29",
      "type": "usergroup",
      "subtype": "",
      "mandatory": false,
      "description": "",
      "numberDefault": null,
      "numberMin": null,
      "numberMax": null,
      "numberDecimals": null,
      "numberPrefix": "",
      "numberSuffix": "",
      "textDefault": null,
      "textAllowedPattern": null,
      "textMaxLength": null,
      "selectionOptions": [],
      "selectionDefault": null,
      "datetimeDefault": null,
      "usergroupDefault": [
        {
          "id": "admin",
          "type": 0,
        }
      ],
      "usergroupMultipleItems": null,
      "usergroupSelectUsers": null,
      "usergroupSelectGroups": null,
      "showUserStatus": null
    }
  }
}

[blizzz]

First glance looks good, have not tested myself yet

• Integration test can be extended around inserting, modifying and delete column values
• a new migration class is needed to add the new columns on existing installations (existing steps are not executed again).

[juliusknorr]

All right, from the journey through the rabbit hole of value transformation/parsing, i came up with a few changes:

Related to this PR:

• The value_type column is now only added to the usergroup cell data table
• I cleaned up the migrations a bit further
• I added the to filter by one value in views for the user group column

More general as the current approach to handle different value formats was really confusing and not feasible for the usergroup column:

• Improve mapper methods to be more clear on what they do
  • parseValueIncoming: This had two use cases, one to map from the request data to the value to insert cell data into the database, but also to map from filter values to the value that is used in the query builder to construct view filter queries. It was split into
    • filterValueToQueryParam: For a stored value of a filter rule get the value to put in the database query, this could in the future be refactored again to actually build queries more dynamically, but left that out to keep the changes at a reasonable level
    • For the case of inserting/updating values we no longer pass encode/decode json values, but an applyDataToEntity method is added for each case to just fill the Entity object depending on the type.
  • parseValueOutgoing
    • Changed to a formatEntity and no longer use a mixed value type but the actual database entity so we know what to expect and how to transform that to the actual response data format
  • Use hasMultipleValues to indicate that multiple values are stored in multiple entities compared to a hardcoded column type
• Removed a few duplicate code bits around getting the mapper class dynamically

Still checking in on the test failures

fixed

[juliusknorr]

👍 But would appreciate @blizzz and @enjeck to also give their thumbs up for my parts

[blizzz]

A question, a hint, a follow up thing, and a nitpick, nothing blocking per se.

[blizzz]

roger. perhaps opening an issue for this afterwards?