[BUG] Shares in non-root are not displayed

[parneet-guraya]

Fixes: #4432

Demo -->

Record_2024-07-10-13-37-07.mp4

The reason for this issue was whenever we create/edit a link. After POST request we make a GET call to retrieve the share info because it was mentioned here that the POST request does not return the response that we need.

But the GET request is returning wrong path i.e for a file that exists at /Folder/file it returns the path /file . So, it always returns a path that a file exists in the root even though it is inside some folder.

Above screenshot shows two responses. First one is the POST which has path /Fol/file and the second one is GET response which has path /file (which is incorrect)

Also the incorrect response from GET lead to duplicate entries in DB -->

• First entry is stored from the response with path as /file(incorrect)
• Second entry is stored when the ShareView is refreshed and upon sync (from remote), instead of getting replaced the new entry gets added because there's path ##difference.

Solution -->

Turns out POST request does return same response as GET does and also with correct filePath. So, now the need for GET doesn't exist.

[parneet-guraya]

@jesmrec does it also fix #3016?

[jesmrec]

@jesmrec does it also fix #3016?

i don't think so, are different things. The current one affects the list in the shares view, and the #3016 affects the list of files. Anyway, i will take a look in QA phase.

[Aitorbp]

For my part the work is fine. Only one thing is missing, could you add the calens file? Here you have some information to do it: https://github.com/owncloud/android/blob/master/changelog/README.md

[parneet-guraya]

@Aitorbp , Added the changelog 👍

[Aitorbp]

@parneet-guraya very good job! I will move to QA!

[jesmrec]

Let's QA this

[jesmrec]

@parneet-guraya first, thanks for the contribution.

I noticed that the fix applies to the public links, but for sharing with users and groups (also reproducible and reported in the issue as a note). Could you take a look?

[parneet-guraya]

I noticed that the fix applies to the public links, but for sharing with users and groups (also reproducible and reported in the issue as a note). Could you take a look?

@jesmrec , you're right. However, I'm not able to add any shares, it seems the demo account does not have privileges?

Record_2024-07-24-02-45-11.mp4

This is what I get as a response (even on master) but I'm able to do the same from web just fine. Could you give it a look?

[jesmrec]

@parneet-guraya this should not be a matter of permissions because web allows to share. Something is not correct in the app there. I will try to check.

[jesmrec]

@parneet-guraya which server instance are you using to check it?

[jesmrec]

I was able to reproduce the problem with ocis.ocis.master.owncloud.works but not with the oCIS stable 5.0.6. I created an issue in oCIS repo: owncloud/ocis#9681 because the problem is also reproducible with iOS client. Web client works fine. In order not to block the current issue, i'd recommend to use an instance with stable 5.0.6

[parneet-guraya]

Hi @jesmrec, I'm using demo instance at demo.owncloud.com this could be running on latest master?

So, to run different version i.e 5.0.6, I guess I have to run it locally?

[jesmrec]

You can use this instance with the stable version: ocis.ocis.production.owncloud.works (i just found it). With same usernames and pwds.

[parneet-guraya]

@jesmrec, Would you mind directing me to the resource to how to do it?

[jesmrec]

@jesmrec, Would you mind directing me to the resource to how to do it?

Sorry, what do you mean? you can access https://ocis.ocis.production.owncloud.works just with the URL, as any other instance. Is that right? if not, let me know.

To clarify:

https://ocis.ocis.production.owncloud.works -> production version, the current stable (5.0.6)
https://demo.owncloud.com -> rolling version, latest master. with a preliminary 6.1.0

The problem is not reproducible in production, and reproducible in rolling

[parneet-guraya]

Okay, I get it now. Thanks 👍

[jesmrec]

@parneet-guraya were you able to finally reproduce the "share with users" problem? let us know if you need some extra help or clarification. thanks!!

[parneet-guraya]

@parneet-guraya were you able to finally reproduce the "share with users" problem? let us know if you need some extra help or clarification. thanks!!

Hi, turns out the POST request that we make to share with users and groups returns the wrong path (as if the file always is in root folder). This is same as we create public shares where first a POST followed by a GET request was made but in that case the second request was returning the wrong path so I removed the request because first request was enough according to the data we need.

But, now in this case the only request that we make to share, returns the wrong path. So, it is a backend issue. I read from the issue created by @jesmrec comment that mobile clients are using deprecated API so could it be the bug exists in the deprecated api?

A quick fix could be just to make a refresh call from remote after doing the POST request for adding the share. Which triggers when a dialog appears for adding new shares and that is the reason we start seeing the items that were not showing earlier.

Do let me know what you think? @JuancaG05 @Aitorbp

[jesmrec]

But, now in this case the only request that we make to share, returns the wrong path. So, it is a backend issue. I read from the issue created by @jesmrec owncloud/ocis#9681 (comment) that mobile clients are using deprecated API so could it be the bug exists in the deprecated api?

Don't worry about this, ocs is not deprecrated yet. Problem in the oCIS issue finally comes from other side.

[Aitorbp]

@parneet-guraya were you able to finally reproduce the "share with users" problem? let us know if you need some extra help or clarification. thanks!!

Hi, turns out the POST request that we make to share with users and groups returns the wrong path (as if the file always is in root folder). This is same as we create public shares where first a POST followed by a GET request was made but in that case the second request was returning the wrong path so I removed the request because first request was enough according to the data we need.

But, now in this case the only request that we make to share, returns the wrong path. So, it is a backend issue. I read from the issue created by @jesmrec comment that mobile clients are using deprecated API so could it be the bug exists in the deprecated api?

A quick fix could be just to make a refresh call from remote after doing the POST request for adding the share. Which triggers when a dialog appears for adding new shares and that is the reason we start seeing the items that were not showing earlier.

Do let me know what you think? @JuancaG05 @Aitorbp

Hello @parneet-guraya , very good research. As you know, we are using a deprecated API and we don't know if someone could change something in this API. So maybe the best way at the moment is try to do to refresh as you comment. So, yes, go for it 👍

[parneet-guraya]

Hi, pushed the fix 👍

[Aitorbp]

@parneet-guraya a few changes more and ready to go 💯

[jesmrec]

Now, everything is fixed. @Aitorbp please approve if you think this is OK as well and we can merge it

[Aitorbp]

LGTM 🥇 Good job!