Comments
-
Yes, I'm seeing the expected behavior and times of a couple of seconds. That looks normal. Thank you.
-
Really? It's been 23 hours. My clients are down - we rely on timely notification of a "command" file that's been updated. My business is suffering. This doesn't reflect well from a company that claims to support enterprise level functionality.
-
The notification seems to get pushed if some other client lists the folder (ie another browser showing the folder is refreshed).
-
Even Firefox browsing to dropbox.com looking at the folder where a file is then updated does not show the updated file and opening the updated file shows the OLD data until the browser is refreshed. Then new content is shown.
-
The client not getting notifications is both Edge & Internet Explorer using the Dropbox Javascript SDK. Nothing on this end changed today, but near 4pm Mountain it quit working.
-
This is still going on, hours later. The status page has not been updated and no response of findings here.
-
I'm hoping there's a fix for this, but in the mean time I do the following: * Invoke sharing/create_shared_link_with_settings() which of course fails if the file has already been shared * Invoke sharing/list_shared_links() and (I personally) use the url from the first element in the list of links * Since the resulting URL…
-
Thanks Greg. In v1 of the API we could get a temporary shared link (lasting four hours) and use that with a slight tweak to show the file in the browser. Is there no equivalent feature, have we lost that capability, in v2? In v2, the /create_shared_link_with_settings would be the correct end-point to get the URL for…
