feat: add new column for user and group to backend

[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, isUser: boolean, displayName: string}

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\", \"isUser\": true, \"displayName\": \"admin\"}]" }' \
'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",
          "isUser": true,
          "displayName": "admin"
        }
      ],
      "usergroupMultipleItems": null,
      "usergroupSelectUsers": null,
      "usergroupSelectGroups": null,
      "showUserStatus": null
    }
  }
}

[enjeck]

Not sure if APIv1.feature needs to incorporate the new column too

[juliushaertl]

I think for building more optimal queries it would actually be nice to have a different table format that not stores the entires in json as text but instead something like this

oc_tables_row_cells_usergroups

id	column_id	row_id	value	value_type
1	2	9	alice	0
2	2	9	bob	0
3	2	10	engineering	1

This might be more complex to build but we can do performant filtering on large tables by having an index on the value type and its exact match. For the value type using an integer (0 for user, 1 for group) is common from the server sharing API. Probably something to explore further then. Would be curious if @blizzz may have further thoughts on that.

[blizzz]

Seconded, as filtering is an important aspect.

Also Teams might be included in future.

[blizzz]

So to have a generic solutions that allows value_type in row_cells_xyz tables:

1. A method like lib/Migration/Version000700Date20230916000000::createRowValueTable() or its optional extension to also add a value_type column. The $columns array could be extended in that class. For new data types of course we need a repair step.
2. Evaluate an abstract subclass of RowCellSupper providing support for setting value type (e.g. adding setValueTypeWrapper()) or maybe it is sufficient (though not cleaner) to extend the current class, taking the existence of a value_type from the concrete implementation into account.
   3.In the same way evaluate extending RowCellMapperSuper with parseValueTypeOutgoing() and parseValueTypeIncoming() although this is unlikely to contain "weird" data. We shall store there constants only (ideally only ints) and it should not be set by direct user input.
3. Row2Mapper needs to become aware of possible value_type fields, for example in insert(), getFilterExpression() (there we already have type-dependent handling) and generally where at least formatValue() is being used
4. Insert ability to merge rows in oc_tables_row_cells_xyz that share the same column_id and row_id to be able to support multi-values by row. The difficulty lies in having different cell ids per actually set value, so this makes editing a cell difficult, but on a first glance the frontend does not work with cell IDs when updating a value. RowCellMapperSuper::findByRowAndColumn() returns a single entity – a starting point would be to have a generic extension for multiple values with a method lile findMultipleByRowAndColumn() that can return multiple entities which will later on be merged for the frontend.
5. Where applicable frontend also has to supply value_type information, e.g. when submitting such cell values.

• Not looked into it yet by me: frontend live filtering, might not be an issue.

A non-generic solutions also ticks almost all items, albeit on concrete implemenations. The value_type might come in handy with other future types (could imagine it for columns like file or image picker, ip address, icon/emoji picker).

On a second look, i just saw the TextLinkBusiness thing and it stores already up to three data points in its value (title, value, providerId). If we want to be able to serve scenarios like these, we'd need to look into a more flexible approach.

[enjeck]

From what I see, with this approach, we can't perform real updates because we have multiple rows? All we can do is delete and insert?

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!