fix: allow a maximum of one invite at a time

[fschade]

Description

as described in #7962 multi invites could get problematic, specially the error handling.
Therefore we've decided to restrict invitations to a maximum of one!

It contains validation (allow only user and group types, id), error handling and tests for that.

• already shared to the user // group -> 409
• wrong or empty libre.graph.recipient.type (group && user allowed) -> 400
• unknown user -> 400
• unknown group -> 400
• disabled user -> TODO not part of this pr, will be handled globally via reva

Related Issue

• Fixes SharingNg. sharing invitation  #7962

Motivation and Context

explicit error handling

How Has This Been Tested?

• unit tests
• manual tests

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[mmattel]

Wouldn't your list of 4xx cases be valuable in some dev docs description?

[kulmann]

Wouldn't your list of 4xx cases be valuable in some dev docs description?

The PR is still in draft mode, isn't it?!

[individual-it]

I think this also needs a change in the libregraph repo, the example there shows multi recipient invite: https://github.com/owncloud/libre-graph-api/blob/main/api/openapi-spec/v1.0.yaml#L514-L519

[fschade]

recipient

I think this also needs a change in the libregraph repo, the example there shows multi recipient invite: https://github.com/owncloud/libre-graph-api/blob/main/api/openapi-spec/v1.0.yaml#L514-L519

thanks for the hint, done: owncloud/libre-graph-api#155

[fschade]

Wouldn't your list of 4xx cases be valuable in some dev docs description?

thanks for the hint too, one of the benefits of oapi is the self documenting character, e.g. https://swagger.io/resources/articles/documenting-apis-with-swagger/

or do is miss some point?

[sonarqubecloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[ScharfViktor]

I tested it, looks good

• resource from personal/project space already shared to the user // group -> 409
• space already shared to the user // group -> 409
• share disabled/deleted space -> 404
• share deleted resource -> 404
• wrong or empty libre.graph.recipient.type - 404
• unknown user/group -400

@grgprarup could you please adapt your tests for new code expectation