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.

Code-wise this is ready, but we might need to adjust the "since" tags. I'm assuming this will be for 10.7

@jvillafanez any progress on that?
Could you add a changelog pls?

Since this PR has API changes, I'm waiting for the official 10.7 alpha. Master is still with 10.6

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

This is currently frozen due to API changes. Waiting for OC 10.7 in order to resume the work in this area. There is a 10.6.1 version planned I think.
@micbar FYI

There is a 10.6.1 version planned I think.

Note: there is no 10.6.1 planned. Next version should be 10.7.0

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

@jvillafanez looks good in general.
Is it possible not to duplicate the code for the core federatedfilesharing app? As I see the only difference here is a set of share types.

Is it possible not to duplicate the code for the core federatedfilesharing app? As I see the only difference here is a set of share types.

The problem is that the actual action depends on each provider. The manager just forwards the request to all the providers. In this context, we could expect that each provider has its own way of storing the information, and its own way to delete it. The fact that both providers use the same DB table could be considered as a bad coincidence.

I agree we should avoid that duplication, but I think we'd also need to refactor all the related operations and provide a common way for the providers to store the information. For now, as said, it seems the storing part is completely delegated to the providers.