I'm using the Box search API to try to locate files on my Box account.
I'm finding that when I move files around, even though those files are on my account on the server, when I search for them, they are not found. They were found in the original location.
Should the /search API reflect the current state of my account? Or is there some sort of caching.
This seems to especially happen with files moved to subfolders.
There is a small delay where Box has to reindex your changed files, so updates won't be seen immediately in real-time.
Related
I would like to add URL links into a web-based Google Drive folder. Searching online, it appears that this was once possible with files that ended in a .glink extension. I'm looking for documentation on the file format so that I can create them programmatically.
[EDIT] Why do I want to create .glink files? Because I want links (bookmarks, URLs) to be able to appear in my Google Drive web page and to be able to click on them an go to the page. Microsoft OneDrive supports this functionality.
GLINKS Files
The URL link file feature was available due to a workaround with Back Up and Sync before being deprecated with Drive for Desktop. The .glink seems to be patched and no longer available as it was also part of a third party tool no longer available. It seems it now only saves them as .URL and automatically gives it the icon for Google Docs, as it would take it as a simple file with text.
Checking the .url type file of Windows, when uploading to Drive it does not update as it should, even utilizing Drive for Desktop (as an alternative to sync data like back up and sync) the outcome is the one suggested above.
This is the main reason why there is no longer any documentation about the matter, due to this one not being an official feature and being also fully deleted, it can be confirm by the file type available when creating files with the Drive API:
https://developers.google.com/drive/api/guides/ref-export-formats
I would suggest to request a feature to allow this or to provide a new way to store URL links as before or report it to review if possible any references on how it used to work by submitting a feature request or checking the issue tracker about the matter:
https://issuetracker.google.com/issues/new?component=191650&template=824106
You can also add the details of the previous threads or discussions about the GLINKS.
We use the multi-linking of folders and documents in Google drive to share live updates with our whole team. This is very useful as each person gets access to the doc and any updates made are received in real-time.
The trouble we have is that if anyone decides to remove the multi-linked item from their home directory using the "remove" option, the content is trashed for everyone. This causes loss of data and info and is not acceptable. We do have the option of checking the location of the multi-linked item and removing it from that particular location alone. But not everyone follows this.
Is there any way we can do the settings such that the "remove" option works only on the current location for the multi-linked item? All ideas are welcome. Can we use Google App Script for this?
There is no workaround for this as of now.
However, you can file a Feature Request for this.
There is no way for you to alter how the google Drive web application works. Remove will remove it forever one.
I want to create an app that "types" into a text document in Drive. The goal is to have a document which is publicly viewable, if not editable, and a program which enters text into that document as though it were being typed by a person. If I use the following Drive API endpoint PUT https://www.googleapis.com/upload/drive/v2/files/fileId
will a viewer see the edits taking place a character at a time? (assuming I upload each version with one character difference). Or is there a function which would allow me to programmatically "type" each character?
My perusal of the Realtime API makes it look like this is what I want except that it involves setting up a separate page, where what I'm looking for is just the ability to write to a doc in Drive, in real time. Am I looking in the right place?
If you just want a background script that writes to a file, you probably don't need the realtime API. This is more designed for multiple users making changes at the same time.
However, it may be possible to accomplish what you want using the import/export functionality.
Use realtime.get to get the contents of the file as json. Then use realtime.update to post a modified version of the contents. This will cause the diff of the get and the update to be applied to the realtime model. Any active clients will see the changes come in as some new characters added to the document.
i have been going around in circles here and have totally confused myself. I need some help.
I am (trying to) writing an application for a client that in concept is simple. he want a google write document with a button. the google drive account has several folders, each shared with several people. when he drops a new file in one of the folders, he wants to be able to open this write file, this file is the template for his email. he clicks the button, the system calls the changes service in the Google Drive SDK https://developers.google.com/drive/manage-changes, gets the list of files that have been added since the last time it was checked, then pull the list of people that the file has been shared with, and use the write file as a template to send that list of people an email saying their file is ready.
SO, easy enough, right?
I started by looking at the built in functions in the Google App Script API. I found this method, https://developers.google.com/apps-script/class_docslist#find in the DocsList class. problem is the description for the query simply says "the query string". So at first i tried the Drive SDK query parameters, which are
var files = DocsList.find("modifiedDate > 2012-12-20T12:00:00-08:00.");
it didn't work. that leads me to believe it is a simple full text search on the content. Thats not good enough.
That lead me into trying to call a Drive SDK method from within an App Script application. Great, we need an OLap 2 authentication. easy enough. found the objects in the script reference and hit my wall.
Client ID and Client Secret.
you see, when i create what this really is, a service account, the olap control in apps script doesn't know how to handle the encrypted json and pass it back and forth. Then when i tried to create and use an installed applications key, i get authentication errors because the controls again, don't know what to do with the workflow. and finally, when i try to create a web app key, i can't because i don't have the site host name or redirect URI. And i can't use the application key ability because since im working with files OLap 2 is required.
i used the anonymous olap for a while, but hit the limit of anonymous calls per day in the effort of trying to figure out the code a bit, thats not going to work because the guy is going to be pushing this button constantly thru the day.
i have been pounding my head on the desk over this for 5 hours now. i need some help here, can anyone give me a direction to go?
PS, yes, i know i can use the database controls and load the entire list of files into memory and compare it to the list of files in the database. problem being, we are talking tens of thousands of files. bad idea.
I wouldn't use DocsList anymore - DriveApp is supposed to be a more reliable replacement. Some of the commands have changed, so instead of find, use searchFiles. This should work more effectively (they even use a query like yours as an example).
Building a workflow that allows a file to be dynamically moved via user input (renames, the whole works). Using the Service Action, a web service will rename and move the file based on user input fields and some other behind the scenes processing. However, once the service runs and the window closes, the file is move but the user experience goes bad. The file keeps refreshing in the preview pane, redirects back to the root, and nothing works right until you navigate away.
The ideal solution would be the for the file to be moved and the user moved to the next file in the folder (or at minimum kept in the folder) as we're looking at a "processing" folder.
Is there any ideal best practice? Do I simply just need to copy the file instead of move and then run a delete routine after-the-fact?
It may be best for you to contact Box via email at API at Box dot com to explain better what your application is trying to accomplish. Generally describing the business case helps us resolve questions like this more quickly.