Here is an example of the space I’m trying to create.
Ideally I would be able to have a “doc” for Marketing Collaboration which is viewable to everyone, and a “Workspace” doc which is viewable by only the people on the marketing team. Additionally, if possible, I would like to have project pages able to be restricted further within those.
I spent a little bit of time looking for how to set up view permissions and only really found edit permission stuff.
Thank you for your help.
Edit: To be clear – the folder I have created is currently set to private but will be set so that everyone within the company can view it. Ideally I would then be able to restrict specific docs to only the marketing team and specific pages to only specific people within that marketing team.
If you are looking to limit who each doc is available to, I’d keep this as a Private folder and set the permissions for each doc in the doc itself. A share folder will share any docs in it with the people in the shared folder, overriding the doc permissions.
For sharing a part of a doc, just one page with someone or a group, we don’t have that functionality yet but have been exploring options a good bit. For now, the best solution is to use Cross-doc and sync the table views over to other docs and share those with the specific groups.
I’m happy to dig in deeper if you still have questions.
I am flagging your reply as inappropriate, and will seek to have it deleted.
I understand that you may be frustrated that a feature you value has not yet been implemented by Coda.
But you cannot use such language in this forum. Dropping the f-bomb is not acceptable.
Calling anyone a ‘useless prick’ is not acceptable.
Especially when it is one of the hard-working and highly-supportive engineers at Coda.
This forum is a safe and supportive place for Coda makers of all skill levels to ask for support.
The helpful and supportive regular contributors to this platform, make this one of the best user-support forums in the no-code industry.
This friendly, polite and respectful atmosphere is easily damaged by people making nasty, senseless and immature replies like yours - and none of us will tolerate that for a moment.
PLEASE MODIFY YOUR POST TO SHOW MORE RESPECT, OR REMOVE IT
Thanks for flagging this @Xyzor_Max and for keeping the Coda Community a positive and encouraging place for Makers to connect and share their ideas. I have removed their post.
I want to give this missing feature a little bump.
We are using several Docs and inside the docs we have pages with data, wich a not to be shown to every doc user.
So it would be really nice to have a role based access control for pages inside a doc.
Roles could be maintained in a table together with the aproved folder users. Each user can be member of one or more roles. Each role contans a set of visible or restricted pages. Such a feature could be extended to any mor functionalities inside Coda.
The current roles (Doc Maker, Editor, Guest) unfortunately are not enough.
That topic was for the launch of “full-page embed” functionality. Which could kinda-maybe-but-not-really do what you want. So some people used the opportunity to once again ask about when page/sub-doc sharing will finally arrive.
Codan @Ayuba_Audu was kind enough to write an extensive update on the progress (see my link above).
So what you are asking for is not possible yet, but the “full-page embed” functionality might be a usable alternative for you: add a custom page to your main doc with just the data you want to share, and then embed that page in another doc. You then give the relevant people access to just that other doc. They can view & edit content on that page without seeing the other pages from your main doc.
Of course there are many downsides to this approach; you’ll need to create a subpage and an additional doc for every user that should not have access to the main doc (=not efficient / a lot of work) AND most importantly your data might not be as secure as you’d think. Let’s say you want user X to only see certain values of a look-up column. You might be able to filter those out of view, but the data is still there “under water”, just not visible to the average user. To quote @Ayuba_Audu:
TLDR; page/sub-doc sharing is not yet possible, but it’s being worked on. Full-page embed might be an alternative for some use cases for the time being.
I am afraid this does not work the way you interpret the latest updates: for people to use the doc with the embed, they need to be authorized in BOTH the source doc and the doc with the embed.
At this point in time, the only ‘advantage’ of the embedding is that you can make really small, subject focused docs with pages with full functionality, but it does not prevent them from opening the source doc. In some situations they will even end up in the source doc if they follow links to the originating tables (see one of my earlier posts: Launched: New ways to integrate your toolstack into Coda - #59 by joost_mineur)
I think the problem here is that so much in Coda is tied into the document as an organizing principle, from functionality like tables to UI like the sidebar, that it’s not reasonable to tell users “just use folders to organize instead”. It is natural for teams to organize their Coda with Docs as a top level organizing principle like “Marketing” and then have pages be the different projects or areas of responsibilities within that.
So one of these two things needs to change; either documents stop being the clear top level organizing principle with something like Folders getting dramatically improved to replace them (I’d guess some pretty fundamental DB level stuff precludes this and even if it was possible how on earth would people migrate) or permissions and other access controls needs to be expanded on pages. To say that permissions only live on top-level objects is always going to be hard for us business users.
On a team plan you can use page locking and on locked pages editors can’t change the table filters. This scheme is not meant as a 100% secure way of protecting your data, but is takes a lot of effort to get to the secured information.
As an additional comment to my post on Oct. 30th, I want to add that the search box (top left in the page pane on a PC or the looking glass-Search on mobile (in the kebab menu)) can be used to find anything/everything in your entire document.
Say you have a view of a table with proposals and the table is filtered in such a way that users can only see proposals that have their user name in one of the columns, normally a user might see just couple out of all the available rows. Now imagine that the master proposal table is on a hidden page and is filtered in such a way that only the doc owner can see any row in this table and all other users see nothing.
If page locking is in place, general users (editors) can’t change the filters. In the view of the proposal table they only see what is meant for them to see. And even if they stumble upon the hidden page, the only see an empty master table.
Now imagine this user is John, but the table holds proposals for John and Elise. Using the search function and searching for Elise, you will get a hit on the view of the proposals table and you will get a hit on the master table. And even thought these tables are filtered for other users to not see these table rows, through the search function you can not only see, but open a modal to these proposals that were not meant for you to see. If the proposal table holds a sub-table, you will see all the sub tables lines that match this proposal, even if the sub-table is filtered to only give access to the doc owner.
Needless to say: you can search on a persons name, but als on anything else, like an description, an item, a color, etc. The more general your search term, the more hits you will get.
In my opinion: 1) short term - search should be an optional item along with the other optional items in the locking settings and 2) longer term - search should respect table filters (making it the responsibility of the maker to filter sensitive data properly).
Thanks for sharing your detailed review of the search box.
I took the liberty to reference your post in my blog in which I try to understand the philosophy behind these product choices.
