[QA][OCM] Hide & Enable Sync fail with received federated shares

[jnweiger]

Describe the bug

A clear and concise description of what the bug is.

Steps to reproduce

Setup two machines with e.g.

env OCIS_DNSNAME=cat-7rc3-DATE OCIS_VERSION=v7.0.0-rc.3 ./deploy_ocis_bare_metal.sh
env OCIS_DNSNAME=dog-7rc3-DATE OCIS_VERSION=v7.0.0-rc.3 ./deploy_ocis_bare_metal.sh

mutually register the machines in their ocmproviders.json; service ocis restart

Alice at dog invites bob at cat, bob accepts, alice shares a folder with bob.

Bob sees the folder in shares -> Shared with me.

• There is an 'enable sync' icon. It causes an error. BAD
• There is a 'Hide' icon. It causes an error. BAD

This 'sometimes' worked in older versions, if I am not mistaken??

Expected behavior

Icon's in the UI should work for federated shares, the same as they do for local shares.
Removing Hide and enable/disable sync for federated shares is not a good option, IMHO.

Actual behavior

Additional context

The functions of Hide/Unhide and Enable/Disable Sync are quite related, although their names don't hint at that at all.

Hide/Unhide determines, if the share shows up in the web UI.
Enable/Disable sync determine, if the share shows up in desktop/mobile clients.

I'd suggest to consistently name them

Show/Hide in Web UI.
Show/Hide in sync clients.

@hodyroff fyi.

[jnweiger]

Related log entries on the share receivers' machine cat have
a 400 error code with the hide action, and a 409 with enable sync:

Dec 03 16:48:45 jw-ocis-v7-0-0-rc-3-tum ocis[6653]: {"level":"debug","service":"graph","request-id":"c45eb1c7-0e57-416a-9156-56aca26b1a54","proto":"HTTP/1.1","method":"POST","status":409,"path":"/graph/v1beta1/drives/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668/root/children","duration":1.865628,"bytes":171,"time":"2024-12-03T16:48:45Z","line":"github.com/owncloud/ocis/v2/ocis-pkg/middleware/logger.go:27"}
Dec 03 16:48:45 jw-ocis-v7-0-0-rc-3-tum ocis[6653]: {"level":"info","service":"proxy","proto":"HTTP/1.1","request-id":"c45eb1c7-0e57-416a-9156-56aca26b1a54","traceid":"734a8f4f42b2df337ef3126063224e00","remote-addr":"80.139.81.120","method":"POST","status":409,"path":"/graph/v1beta1/drives/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668/root/children","duration":88.861342,"bytes":171,"time":"2024-12-03T16:48:45Z","line":"github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/accesslog.go:34","message":"access-log"}
...
ec 03 16:49:03 jw-ocis-v7-0-0-rc-3-tum ocis[6653]: {"level":"debug","service":"graph","request-id":"a37ec4d0-0d7e-45cb-9578-a4e98e7db268","proto":"HTTP/1.1","method":"PATCH","status":400,"path":"/graph/v1beta1/drives/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668/items/89f37a33-858b-45fa-8890-a1f2b27d90e1$89f37a33-858b-45fa-8890-a1f2b27d90e1!817d8007-146a-4bd5-8052-bdb16d1683df","duration":0.182053,"bytes":171,"time":"2024-12-03T16:49:03Z","line":"github.com/owncloud/ocis/v2/ocis-pkg/middleware/logger.go:27"}
Dec 03 16:49:03 jw-ocis-v7-0-0-rc-3-tum ocis[6653]: {"level":"info","service":"proxy","proto":"HTTP/1.1","request-id":"a37ec4d0-0d7e-45cb-9578-a4e98e7db268","traceid":"ae17999c0553f7c9575f6d28c8f4eb6b","remote-addr":"80.139.81.120","method":"PATCH","status":400,"path":"/graph/v1beta1/drives/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668/items/89f37a33-858b-45fa-8890-a1f2b27d90e1$89f37a33-858b-45fa-8890-a1f2b27d90e1!817d8007-146a-4bd5-8052-bdb16d1683df","duration":6.859733,"bytes":171,"time":"2024-12-03T16:49:03Z","line":"github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/accesslog.go:34","message":"access-log"}

The sharer's machine dog does not seem to log anything during this period of time. :-(

[micbar]

There’s a reason for that.

Sync and hide features are owncloud vendor features on the graph api.

There is neither a protocol feature in OCM nor in the CS3Api. Both protocols know nothing about that.

Both would need to be extended to match that expected behavior here.

[jnweiger]

From my point of view, it's a blocker, when the user consistently gets some "Failed to XXX" errors, when he clicks XXX.
I guess @hodyroff agrees with that general attitude.

Maybe we can remove the not implemented elements from the GUI for now when it's an OCM share?