Google Drive Pack

[Stefan_Stoyanov]

Google drive and Coda could be a great hand-in-hand tool for everyone who relates tasks to folders and/or files in the cloud. (Is there are task which isn’t?!)

A very highly desired functionality explained in scenario would look like this:

1. Create a new task/row in Coda table;
2. Then a folder in google drive with the task’s name is automatically created in pre-defined folder;
3. Then when assigning the task to a person/user, this person gets automatic email with a link to the newly created folder. (no manual copy-paste - just an email template which has a placeholder for this link);
4. The very cool part would be that when assigning the task to the user, Coda automatically updates the access rights of the folder so that the person/user is granted an Edit access to this folder.

If we can achieve that… this would lay the ground for us to create our own platform in Coda and ditch our current inefficient TMS

[Litra_Sales]

This would be amazing, I have been looking at Integromat to do this, a GDrive pack would be amazing.

For us, we would just need a link to the GDrive table to be linked back to the item row

[Aasim_Jukaku]

omg +10000 esp for google sheets.

[Johg_Ananda]

Yes, someway to handle attachments and files within a Coda doc would be awesome.

[Jasmine_Wilkinson]

I would like to be able to embed a list of files (folder) from GDrive into a Coda page, and as long as the Coda user also has access to that GDrive folder, they can see the files.

Having to make a GDrive document public to embed it is not a viable solution. Structured wikis like Coda are for sure better that GDrive, but while transitioning clients, we need a way to guide them to the old docs they have (and not every doc needs to have a page in the wiki - some are design artifacts, other kinds of files that don’t translate well to wiki anyway e.g. Sketch files, videos etc.

[John_Faig]

+1 for a Google Drive pack. It would be great to have a more flexible view into Drive files since it lack organization, especially “Shared with Me”. This option would be very helpful because there is not easy way to provide filtered document views of Google Drive to users without investing in a document management system which is very costly and requires significant setup.

For inspiration, look at a simple example (Awesome Table) and a more complicated example (addon directory). Awesome-Table, which provides a view and has some UI widgets to filter files. The addon directory works like Amazon and lists filter options in a panel.

Awesome Table --> https://chrome.google.com/webstore/detail/files-cabinet-by-awesome/obmjbphplaacknapcnebijpkmghknmdo
Panel options --> https://www.sweetwater.com/c708--Plug_in_Bundles

[Jeremy_Jaramillo]

Yes, please I would love to see this pack added as well.
Thank You

[alexdeneui]

Thanks everyone for your feedback here. Drive, Sheets and Docs are certainly very interesting data sources for Coda. I have nothing specific to announce today, but you should stay tuned for some announcements here soon!

[Khalid_Zamer]

I tried to use links from drive to organize the organizations file sharing and would be very useful to catch ball with google drive shared linked to be embedded or data shared … +1

[Johnathan_Mar]

+1 for this topic, my team is also interested in this pack!
By the way, are there any ideas on connecting personal FTP/SFTP servers to coda?

[GJ_Roelofs]

Linked to Attach files/images to cells with the request to have a workflow where one can have a Google Drive pack and specify a column to which files can be attached, then for that column the ability to specify which folder the files will be uploaded to.

[Federico_Stefanato]

+1
We would really need it.

[Johg_Ananda]

For anyone wanting to have a structured way to create links to files in google drive:

1. Make sure its in a public folder in gDrive and get the shareable link.
2. Paste the gDrive generated shareable link into a cell
3. Use this formula to adapt it to the purposes described herein: Replace([Img gDrive URL],1,33,“drive.google.com/uc?export=view&id=”)

[Bill_French]

@Johg_Ananda

Make sure its in a public folder in gDrive

Are you sure the Drive folder itself needs to be public? I think it will also work if Anyone with the link is enabled. If true, it’s a little more secure and not subject to unintended indexation by some crawler.

[Jasmine_Wilkinson]

Good tip, (that does essentially mean the file is ‘public’ it’s just not about to appear in Google searches).
It’s still not a workable solution - but that is a rant for Coda

[Jasmine_Wilkinson]

Any update on this?

I CANNOT use Coda with any clients (who could be paying you!) because of this.

It is a MASSIVE miss to require Google docs to be public in order to link to them. Especially seeing as you already have Google integration. I understand you want people to use Coda instead of GSuite but you gotta understand that it is a slow process for many organisations, we are trying to get them to transition from Google docs to a better way of managing knowledge and if you can’t facilitate this transition you are preventing Coda users from being able to embed Coda wikis in organisations - and cutting yourselves off at the knees.

There is a basic list of things that need to be achievable for people to adopt a wiki and being able to embed / link to GSuite files us one of them (if you allowed Office365 files and integrations you’d be attractive to the Entreprise market and people who are desperate to be free from the horrors of Sharepoint)

[Bill_French]

@Jasmine_Wilkinson

It is a MASSIVE miss to require Google docs to be public in order to link to them.

@Jasmine_Wilkinson, my tests show PUBLIC sharing is not required to easily create direct integrations with Google Docs.

@Jasmine_Wilkinson

that does essentially mean the file is ‘public’ it’s just not about to appear in Google searches

I think it’s a little more secure than saying it is removed from search indexing bots. Links to the openly accessible documents cannot be predicted and you must be a named user in the Drive account to learn what they are.

[BenLee]

Hi @Jasmine_Wilkinson,

Thank you for your interest and use-case notes. There is a good bit that we are working on to make this easier, some things just take a little time and are much more involved than they appear.

For embedding Google Docs in another system, they almost always need to be public to display. If you are simply linking to docs from a Coda doc, then it doesn’t matter what the permissions are since it’s a link to visit, it’s only the embedding that requires the more open permissions. I’m curious if you’re using a system currently that embeds Google Docs that does not require more open sharing and still displays them?

Please do keep an eye out for announcements as we release new features and updates very regularly!

Ben

[Bill_French]

@BenLee

If you are simply linking to docs from a Coda doc, then it doesn’t matter what the permissions are since it’s a link to visit, it’s only the embedding that requires the more open permissions.

This is an important nuance worthy of a rant.

We often say “embed” but, we and mean “link”. And sometimes we say “link” but, we’re thinking “embed” because - well - embedding does require a URL, ergo, it’s a link. Where was I going with this? Oh yeah…

Another nuance is the notion that anything shared through Google Drive is “public” if it is not shared with a named user. This is not a precise interpretation of Drive’s behavior.

Public on the Web

By Google’s definition, Public on the web means publicly accessible and possibly discoverable through indirect means (such as a search engine that happens to find the document or folder that is also shared publicly). This should not be interpreted as a bad thing. There was a time - many years ago - when users lobbied for this feature because security was too rigid and unable to meet commonly expected use cases.

Anyone with the Link

Sharing via Anyone with the link is actually very secure. Document owners who enable this feature create no risks whatsoever UNTIL AND AT SUCH TIME the link is exposed. The context of the exposure sets the security level because these links are comprised of essentially GUIDs and almost impossible to guess.

When such a link is dropped into a Coda table, it is every bit as secure as the Coda document itself. Anyone with access to the Coda document is equally authenticated to view the document – and no more than the document specified by the link.

This is far different than dropping the link into an email and trusting the planet’s entire hacker community to ignore such links in SMTP packets. SMTP is not only not secure, it is the opposite - it is a broadcast of the link across the inter-webs. Do this at great risk.

When was the last time you heard about a security breach in Google Drive because the Anyone with Link method was used?

I can’t recall (myself), but I’m sure there are instances. But it is not a likely occurrence nor is it apparently a pervasive and debilitating issue for businesses and organizations, otherwise, this feature would probably be gone.

Embedding Documents

As @BenLee intimates, no platform can embed anything without open access to that which it needs to render inside another page (in this case, a Coda document). It’s simply not possible unless there exists authenticated soft tissue between Coda and the platform that possesses the content. Ben said “almost” every platform requires this; I think it’s simply not possible, so [in my opinion] every embed requires access without credentials.

This is a good example - a Google Data Studio Dashboard. It can render just fine in Coda if …

1. The Data Studio dashboard is shared as Anyone with the link;
2. All of the data sources utilized in the dashboard are also shared as Anyone with the link;

In a specific production instance, this dashboard would not be at risk any more than the Coda document rendering this dashboard as an embedded iFrame. In the example, I did it with the Embed formula, but the Embed feature works equally well.

Indeed, sharing documents is not ideal in the current feature set, but it’s not bad either. I’m sure there are some CSOs and IT people who simply do not allow such link sharing behavior, but that’s why Coda supports HTTP links. Any document - even documents that require credentials and a security context can be accessed from Coda. It’s not seamless (of course) and sometimes the friction is annoying. Perhaps a future Pack will make it friction-free.

Signed URLs

If none of these approaches satisfy your security requirements, you can add a security layer to your Coda UX that uses the API to temporarily open Anyone with Link access to a specific document (or folder) for a set period of time (like maybe five minutes). Once the time has expired, the document sharing reverts back to the named users. It’s no different than opening a server port for a specific process and then closing it after the process has finished.

This is not easy, nor is it cheap to build into your Coda apps, but it does allow you to sustain a very tight grip on your external documents while mimicking an open pathway for Coda app users.

Below is a system I built in Google Drive that generates 24-hour signed URLs for extractions of Zendesk tickets. This is secure because the links are set to Anyone with the Link and only named users (on the Zendesk platform) are able to use these signed URLs which themselves expire after 24 hours. The logic behind signed links is that –

• Any support data that’s more than 24 hours old should not be relied upon by anyone;
• Any possibility of a link shared through accidental or unintentional activities becomes worthless in a day or less.

In this design, attackable surfaces vanish and are re-established every 24 hours with completely different URLs.

[Mike_Ray]

+1 for this too.

It really doesn’t make sense that Coda doesn’t offer this already since you connect to other Google services and Dropbox.