Please God, let Coda enable view level sharing permissions…views are the most powerful aspect of coda enabling the exact information to be defined upfront…exact information…that’s what I want to expose with typicaly CRUD functionality. Could replace entire applications using Coda if I just had the ability to control CRUD access at view level. Now I only use Coda for a handful of personal spreadsheet replacements.
4 Likes
Amost the same case, maybe now with the new "Coda Doc Pack" we coud make a way out, having a “Adm Doc” and sharing they information to “Users Docs”.
Not sure if this is the right thread but I hope that with the new granular permissions support (that will come soon the team said), we will have the possibility to “protect” - to some extent- some Coda Docs with the chance to disable the “Copy Doc” function and/or hide formulas…
1 Like
I had a very simple question that I couldn’t find answered anywhere: if I embed a doc in my website, can it be edited by people in my team (provided that they login and that they already have access to the doc), or is it read-only/play mode?
I’m guessing it’s the latter only, but wanted a confirmation from those who have used it.
Using the embed code will default to play mode only. You can try editing the URL to see if you’re able to allow regular editing…
<iframe src="https://coda.io/embed/OpFM0dnOXm/_suU39?viewMode=embedplay&hideSections=true" width=900 height=500 style="max-width: 100%;" allow="fullscreen"></iframe>
See if removing this portion removes play mode:
?viewMode=embedplay
I think the initial “embed” in the URL overrides and keeps this in play mode even with the parameter removed. But would need to test it.
And this is also a URL parameter for hiding the section list:
&hideSections=true
1 Like
Thanks Ben, will give this a try then
Wow, I wish I knew that Edge and Internet explorer are not supported by Coda before I invest any time in this product which I serious struggle to still “love”… Yeah, probably very few people use Edge at home but if any document is going outside of home usage IE/Edge is probably not the last browser to be used. I am so mad of myself now. Should’ve gone with the alternatives.
Hi @Stefan_Stoyanov,
Microsoft is changing the foundation their browser runs on. The newest version mentioned in our supported browsers post runs on Chromium and works just fine. We’d rather work for what’s coming up and support the long term future than a version that’s being discontinued.
Yeah, once I found out that the latest Microsoft Edge runs on Chromium, I instantly tried it. I was pleasantly surprised to find that the interface is almost the same as Chrome, down to the sync and settings, and that everything that ran in Chrome (apps, extensions) runs the same on Edge, including Coda. I use my Coda docs as “online apps” using the “create app shortcut” function, and maybe it’s just a placebo effect, but I feel like Edge takes up less RAM than Chrome and hence my Coda apps run faster on the new Edge
2 Likes
Currently looking over the TEAM pricing plan and I’m very disappointed that this feature is missing. We need exactly the same feature as described by @Tomas_Bachtik above. Any ETA on this?
Coda is a different kind of doc in that most items are accessible for use through formulas and various display types, like table views. Limiting sharing to particular sections is a tough thing to tackle when considering what else people may or may not have access to.
We do have Cross-doc, which I would say is a better solution for most of these scenarios. With cross-doc, you can sync in only the tables or views you want to show and even more, it only syncs in the items that are visible in that view. This gives you a new doc that you can share and it’s more secure because the other information in the original doc isn’t accessible.
1 Like
I get I am a bit late on this thread and due to the length of it, I must apologize in advance if this has been covered before.
In the embed option, there is no option to disable the “Open in Coda” button. I need this to be an option as I want my viewers to stay in the page where the doc is embedded and not leave and go to Coda. Can we please add an option to disable this button in the embed settings? Thanks a lot!
5 Likes
Absolutely agree with Ivan. My use case is that I want to allow clients to play with inputs, review their outputs, but not be able to review the inner workings of the doc currently “hidden” on another page (but still accessible if they find the “show hidden pages” button. Restricting their access to this IP is critical to our use case. I would be happy with either: 1) removing the “Open in Coda” button, or 2) restricting “show hidden pages” on the “anyone with the link can view” profile.
FYI, I am securing the doc by embedding it on a password-protected web page.
2 Likes
To expand on this topic of the “Open in Coda” button. I don’t mind that external people might see the page in Coda, I just don’t want them seeing the whole Doc, just the page that I have embedded. This should be easy to program. Similar to the YouTube embed options. Can we get an official response on this one? Thanks for your help!
3 Likes
I absolutely agree with Ivan_French that there should be a way to disable the option to Open in Coda when you are embedding a page from a doc. I want to be able to include some information on our website that displays only the information that I want them to see. I do not want them to have the option to open my doc and go exploring. Especially, as others have also expressed, that I don’t want people to be able to find any hidden pages. Cross-docs has been mentioned as a way to show only one page, but for what I want to do that will be very cumbersome.
I find it silly that when you go to embed it gives you the option to Hide Page List, but then gives you a note that says, “Users will still be able to see other pages by clicking Open in Coda.” Kind of a pointless option other than giving you more display real estate with the embed. So why, why, why can’t you give us the option to disable the Open in Coda Option? It would solve so many issues for people. If the reason is because of marketing and you don’t want to eliminate the exposure of Coda to potential users then just provide an option for people to go to a Coda web page that explains about Coda rather than forcing people to expose their coda docs.
2 Likes
One issue here is that hiding the “Open in Coda” option won’t stop someone from just right clicking the embed (or using developer tools) to open the full doc and explore it from there. So we don’t want to give folks a false sense of security thinking that the other pages in the doc aren’t available to someone who can easily look up the link to the full doc.
What I’d recommend here is to use cross-doc to share the part of the doc that you want to share (e.g., just the specific view) and sync that into another doc that you actually publish and embed.
1 Like
@oleg we get the philosophical concept here, but reality is that 99% of users don’t know what ‘developer tools’ are and 99% of use cases are about preventing user confusion and making workflows elegant rather than protecting against the dreaded hack0r.
I think you can find a way to disclose the security risks while making Coda more useful for a myriad of use cases.
4 Likes