Share/Anyone with the link = No access
Publish/Doc interaction = Edit
However I’ve found that if I do that pairing, they can’t access it and says they need to be invited. I believe its because the ‘No Access’ setting. However if I change
Share/Anyone with the link = Can View
They can see the doc but not make any changes. So I have to set
Share/Anyone with the link = Can Edit
So when that is set, I get everything I wanted from the top, however, after being in the doc, if the user goes to coda.io, they see the doc listed in their list, and they can click in to it. Now they’re in the https://coda.io/Docname_dp-nrXXXXX/page version and can unlock, view hidden tables, etc.
There are a lot of options and combinations - am I missing something or is there no way to make a doc just ‘published’?
Hey there! Wondering if you can clarify if the idea is to have people accessing a public doc? To be working within one doc, editing/changing/adjusting things?
Or, are you trying to create a doc that people can use in their own workspaces separately, kind of like template?
Thanks for the clarification!
Additionally, here are some links with breakdowns of our publishing and share settings for your reference:
Hi @Nicole_Macdonald thanks for helping. I do not want a template, I want an unlisted doc where anyone with the link can make edits if they are logged into coda (so there edits will save). I believe Publish/Edit would do this, however it seems there is a ‘bug’ which gives users access to the ‘D link’ in their coda.io homepage for the published doc.
Let me know if I can make it more clear or if this is not a bug and the intended use case for Publish.
Hey there, good question! I’ve checked in with our Publishing team, and this is actually working as intended. Because the doc is open to editing by others via the publishing settings, the “d link” doc will show up in folks Doc List if they make edits to it.
Happy to pass along feedback to our team on this topic, though. Can you tell me a bit more about your use case? In particular, if people are allowed Edit access to a Published version of a doc, what about them having access to the “d link” or base-level doc is undesirable?
example case where access to “publish + edit acces” on a doc is desired but ‘d link access’ is undesired:
When you want publish doc users to interact with doc (buttons) but dont let them interact with the full doc d-link file where they can edit any all text. (without the need to use permission control - a teams feature)
When you dont want the publish doc users to access the docs d-link wherein they can poke through the intentionally hidden pages by the doc maker.
Hey following up here. I don’t know if it makes any sense for me to explain to you why there should be a difference between Publish and Share modes, since Coda invented them.
The main difference is that the D-link is the private doc. There are more security concerns with that doc. To make publish edit work we have to give edit access to every anonymous person who gets the link - and everyone gets the link who visits and uses the doc.
They get access to the share tab, the unlock button, view hidden pages and the search tab which gives them access to everything.
How does requiring giving EVERYONE EDIT access to make Publish work the intended effect? Why can’t we set the Share function to ‘No access’ and ‘Publish to Edit’ and it works the way is implied? I’m missing something for this to be intended please help me understand Coda’s security model it is very confusing to me and the many other people on the forum I’ve discussed this with. Thanks
Hey @Johg_Ananda, I was the Product Manager for publishing so thought I would try to answer as best as I can. It was a big debate when we first created publishing if the regular and published doc should have the same share model or not.
The main trade off was that if we separated them we couldn’t allow for editing (just view and play modes) as it would be a big technical challenge for them to be separate docs with separate sharing but still be the same doc and stay in sync from both sides. Fundamentally they are the same doc with just different UI treatment, hence they have the same sharing.
It might not be viable in your case but the two features we see people use to mitigate this are either Forms for just data entry or Doc Locking to lock down the original doc and limit what can be edited there (Publishing actually is just using locking under the hood)
The majority of publishing is view/edit mode (95%+) and of those using the Editable version many are fine with the limitations we have. I know that doesn’t help in your case and probably isn’t the reply you were hoping for, but just trying to give you some insight into how we’ve prioritized. Happy to answer more questions and get into more detail if it’s helpful.
I know you understand the technical aspects of this better than I, and if you need to have the permissions be constant throughout the dDoc and the pubDoc, so be it.
However there are some things Coda could do to make it easier for Makers and the users of their docs.
First of all, speak plainly. The language / UX around this issue is confusing; no one on the forums, nor the Codans answering here and in intercom support, were able to articulate the actual policy as you did. So that would have gone a long way in terms of managing expectations. Perhaps the reason that 95% of the publishing is view/edit is because publish/edit is not accurately articulated and doesn’t work the way its expected to, so this is a fallacy to think that metric is guiding. Having publish/edit unlocks so many possibilities!
If true Publish/Edit can’t be achieved, how about hardening the ‘Edit’ and ‘Locking’ features so that the Ddoc can act published. For example:
disable search bar
disable show hidden pages
hide side bar > top
hide Coda chrome
don’t show dDoc on coda homepage
We’re trying to make interfaces that people expect and aren’t distracted by things. For example, if I want to create a ‘search’ feature for the user to find something in a certain table, we can show them that, but a month later when they come back to the doc and the first thing they see is the persistent and noticible search box, it confuses them and they use that and then it brings up a hundred unrelated responses and they think its broken.
Not sure what the reference to us being silent on the issue is, or if that’s more related to speed of response, but we care a lot about publishing and trust that everything you’ve suggested has been debated and discussed. Just as always scoping and prioritizing amongst all the other things we’re trying to deliver at Coda mean there are always trade offs. I tend to think of all features at Coda as WHEN not IFs.
re your previous post on the UI, it’s sure something we think could be better and more transparent. We’ve tried a few experiments before that make it more transparent with more control, but it also meant for the average user there were a lot more things they had to think about vs just hitting publish and not worrying about it. So none of those changes have been ones we’er happy enough to ship.
Still a work in progress to improve, you’ll notice as part of the custom domains launch we moved a bunch of the publishing UI into the right hand panel of the product as it gave us more space to iterate.
