I have created a Doc. It has multiple pages and I have shared the doc with the team but I don’t want them to see the entire pages. How can I restrict user to view or edit specific page of the Doc.
Unfortunately, that functionality does not yet exist in Coda 
(I cant wait for a day when page permission become a feature!).
You can, depending on your use case and structure of docs, achieve some of permission control with cross-docs but that complicates things quite considerably 
1 Like
Hey there! Thanks for sharing this feedback! While we don’t currently support this, it’s something our team is looking into.
In the interim, the best solution would be to use folders in your workspace, with separate docs that have their own permissions or to use cross-doc.
I have formally tracked feature request votes for each of you in our team’s tracker and moved this post over to the Suggestion Box so others can weigh in with their opinions.
There are a few things you can experiment with.
Imagine you don’t share the doc at all; you keep it private to yourself. In your core doc create a table with a single row that includes a canvas field and include in the canvas everything you want your team to see.
Then create a new doc you want share to the team. In that doc, cross doc the table that contains the single canvas field. Then shape the field to display in full view.
As you update the original content, the team will see the latest content in the shared document.
Another approach that might work - create a new doc for the team and use CopyPageToDoc to copy/update the page that you want the team to see. This action will copy the page intended for the team when executed. I believe this action can be run automatically to always keep the target page updated.
Oh Bill - there’s some super interesting ideas there.
I wonder if there’s a way one can do this with user filters.
I’m spitballing, but hear me out.
Table 1 - Helper table with 1 row per user, and a bunch of columns which are check boxes for which tables you want to give access to. You lock this down with a filter that only the doc maker can change - which is user()=“name of trusted doc builder”
Then for all database views, you simply have a filter that looks up table 1 to see if the user can see the relevant rows. If you don’t have access, no info from that database will be seen.
This does mean you need to set this up for ALL tables in your doc individually, which depending on the size of your doc could be a decent amount of time, but otherwise, it seems like it might work.
I could be missing something.
I only thought about it because last night I was chatting to a codan and going through a doc with them, but they couldn’t see ANY of the content, as I had not made a user row for them in my normal helper table.
Now, I’m not sure if this is particularly locked down or not (especially given some strange filter issues I’ve been having lately) but it seems something someone might want to explore if they have time, and could potentially create a proof of concept version quite quickly. I wish I had the time to try right now rather than just being an idea…
Ok - so I’ve created a prototype in 5 mins.
Maybe it will help you? It is just to show the concept.
You’ll need to edit the helper_security table to include your name and coda_user name - and then add a row for each user. Then lock that table down with another filter. But I THINK this might just do what people have been asking for.
That’s a fairly known pattern that abstracts visibility for data, but @Subham_Goyal indicates this is about page content which may include many types of data objects.
Sadly, I don’t think either of my suggested approaches will work well enough to suit the requirements.
The copyPageToDoc approach actually does work, but each copy will create a new page; no way to overwrite a single page target. But, if the users were tolerant of multiple updates (like a status reporting scenario), it could be a solution.
However, there is a third possibility –
Since we know that it’s possible to email a specific page from a document and this can be instrumented for automated sending, one could create an email pipeline of the HTML for the page to be shared more openly. The email pipeline might then be able to be used to present the content for the targeted users in some rendered approach. This is all very ugly and speculative, of course.
Ah I assumed something like that would have already been made 
But taking it further - if one just used display tables, couldn’t you hide everything you needed inside? I know it’s not ideal, but you could use canvas columns for anything not table related? They’ll still be covered by the simple switch to see the page?
Btw : I like your email page suggestion - super interesting!
Yes, that would work as long as readers are tolerant of seeing content in table cells. And there are ways to repress cell-based content through inline formulas too, so there are many options to explore.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.