Files or folders are not shown as shared unless the page is refreshed

[purigarcia]

Expected behaviour

File is shown as shared

Actual behaviour

File is not shown as shared unless the page is refreshed

Steps to reproduce

1. Log in owncloud on Firefox and chrome
2. Using firefox, there is a folder "documents"
3. Access to folder "documents" and share a file by link or by user
4. Using chrome, access to folder "documents"
5. File is not shown as shared unless the page is refreshed

Other steps to reproduce is using curl

1. Log in owncloud on Firefox or Chrome
2. Execute this command in the console
   curl -u user http://serverName/owncloud/ocs/v1.php/apps/files_sharing/api/v1/shares -d path=/documents/file.png -d shareType=3
   where user is the user you are using
   and -d path is where the file is
3. In the web, access to folder "documents"
4. File is not shown as shared by link unless the page is refreshed

The same bug happens when a folder is shared

Server configuration

Owncloud version: It was tested in daily
{"installed":"true","version":"6.90.0.1","versionstring":"7.0 pre alpha","edition":""}e:

Client configuration

Browser: chrome, firefox
Operating system: MaOs 10.7.5

[PVince81]

Anything in the logs ? Browser log ?

Could be a race condition

[purigarcia]

I don't see anything which seems important or related to this issue in the logs or browser logs.

[PVince81]

Ok I think this is because all shares are loaded and cached the first time the files list is loaded.
Then when navigating to other folders it uses ajax calls but doesn't reload the cached shares for performance.
We could make it reload the shares every time the folder changes.
At that time I didn't like the idea because it seems that currently ALL shares are loaded, not only the ones from the current folder.

[MorrisJobke]

I can still reproduce this in stable7

[PVince81]

Yes, this is not fixed. Need a good solution, but I don't want to revert back to loading ALL shares every time the user navigates between folders.
Ideally the Share API should allow for filtering by path, which I guess works already in the OCS Share API. BUT thing is, that old rusty code isn't using the OCS Share API but a custom endpoint.

Ideally I'd like to move all sharing calls to the OCS Share API, maybe it would be a good start here for OC 8.

[karlitschek]

@PVince81 Is this still open?

[PVince81]

Yes

[PVince81]

CC @rullzer just for information.
Something we'll have to address eventually.

[rullzer]

Yes. But how to do this is not trivial.

A possible solution for new shares is a function get shares since. Which would just check for the stime (share time). However that would not solve the other case where a share is deleted.

Of course the best solution would be to have a push channel from the server. But I do not see that happening any time soon.

Maybe the best (and easiest) fix would be to add ETag stuff to the OCS responses. So the browser makes regular polls to the server for the shares of the current directory. It adds the IF_NONE_MATCH header (which it caches). So if new shares are found (or removed) the ETag won't match and updates have to be performed. If it is a 304 nothing needs to happen.

The ETag in OCS responses can then just be the MD5 or so of the response. Which will be the same if nothing in the shares changed.

It will not be instant that way but polling every minute is already a better UX. And as a bonus we could also use this in the clients for if the dialog is open.

[MorrisJobke]

I would rate this a duplicate of #983

[nasli]

The point here is to keep the user synced as much as possible, and since up to now is the only way to do it, in the mobile client we are updating share files while the user navigates.

We are doing a lot of requests for that, but doing that we ensure that the user is always up to date.

Since a mobile device have less resources than the web, we expect the same behaviour on the web.

[PVince81]

The brute force quickfix approach would be to call the OC.Share APIs every time the user navigates into a folder.

Anything else is out of scope as it would require having something that monitors changes on the server, which is in the same level as detecting changes in the file list listing (and shares) and updating the UI in real-time. See #983

[rullzer]

The brute force quickfix approach would be to call the OC.Share APIs every time the user navigates into a folder.

Yeah... that does not scale... 😞

[PVince81]

Note that OC 5 did that when we didn't have ajax file navigation back then. It would reload the full page when switching folders, so the shares were always up to date...

[rullzer]

So to be clear, currently we cache the results?

• So I open the root (shares are fetched for root)
• I navigate to subfolder1 (shares are fetched for subfolder1)
• I navigate back (cache is used)

Is this currently what is happening?
Because I think there we should fireoff request or at least cache them for a limited time only (30 sec max)... Else the only way is force refresh.

[PVince81]

The cache is simply the JS variable OC.Share.itemShares and possibly others.

[PVince81]

The TTL might not work properly, this is old API and we don't have direct proper control to detect when it is being read... The easiest would be to clear that array after switching folders.

[PVince81]

Moving the code to the OCS Share API will help fixing this: the list of shares for the current folder is retrievable with "subfiles=true". So every time the folder is switched, this call needs to be made for the current folder.

I believe this is how mobile/desktop clients do to be able to display sharing statuses.

See #21554 for the port to OCS Share API

[PVince81]

Fixed in 9.0 through #21554.

When switching folders, the status icons are re-fetched from the server for the current folder.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.