Launched: Clear Non-Referenced People for Copied Docs

Some of our favorite docs help organize peopleーaround tasks, events or even just to play games over Zoom.

If you share or publish a doc that @-mentions people or includes a table with a people column, others who copy the doc will inherit the selectable people for that doc. We’ve heard your feedback that this isn’t ideal behavior, and today we’re launching an update that clears non-referenced people when your doc is copied.

(As a reminder, you can disable the copy button for your published docs, and manage sharing settings for your private docs.)

Here’s an example of a table from a published doc that includes several team members from the author’s workspace:


Here’s how that same table behaves for a user who copied the published doc to their own, private workspace. You’ll notice the list of selectable people has far fewer options:


No extra work is needed on your part to make this happen. Any non-referenced people will automatically be removed as selectable options when someone else copies your doc. This applies to published docs and shared collaborative docs. Note, however, that if you publish a doc that includes people as examples, those people persist as options when the doc is copied.

We hope this enables you publish with even greater confidence, and that you share your great ideas and frameworks as discoverable docs in the Doc Gallery!



One question then. If I remove those references in play mode, then copy the doc — those people won’t be in the list, right? I.e., will the copy use the last actually saved snapshot (with people), or will it use my play mode version (without ones)?

I think it used to be the latter, in which case that’s a good workaround. Figured I’d still ask though.

UPD. Checked. Seems like no, the changes you make to the doc are gone when you copy. There’s no more viewMode=play mode anymore, and viewMode=embedplay doesn’t give you the context menu where you’d find an option to copy the doc.

Yeah, the copy is based on the last saved version of the doc. Play mode edits aren’t persisted anywhere, so those aren’t taken into account when copying.

Hi, @JonathanGoldman
One feature that would be nice to have is the ability to disable the copy button when you share your doc with people who can edit it. Not only when you publish it.
I don’t want any person, even my employee, to be able to copy the whole company files with two clicks of a button.


@Breno_Nunes - I couldn’t agree more!

1 Like

I still have people showing up in “Author” section of the page. I had previously removed all the tables/sample elements I previously linked with some examples. However, these names still exist.

So, for names referenced in tables, I can simply remove them. However, under pages where you can add subtitle, author. these names still show up.

I cross referenced them using the doc map, it does show couple of tables, button elements which I had used before. However, they physically don’t exist in my doc.

*The highlighted objects don’t exist in my doc… but shows up here.

I may have to remove the whole page to get rid of it.

FYI it’s never really disabled. It’s just hidden, but nothing prevents anyone from copying any doc that they have view access to. One can get Doc ID from the JS console or whatnot, open the doc in the usual Coda UI (not publishing) and find the copy button in a drop-down menu near the doc title.

Dear Paul,

and every doc can be copied through the menu:

Even when the copy button is hidden:

Just wondering it it’s an error or…I missed something :thinking:

It was never meant to be a security feature, just like locking. Both simply hide some UI components but don’t secure the doc on backend level. It’s just not possible by design (a single file that loads entirely; I’ve written on this quite a few times).

P.S. What’s the point to prevent copying really? If you can view the doc, extracting data from it is only matter of effort. With current design, even if you hide everything and lock everything and prevent copying, a malicious actor can still grab the document JSON file and parse that to extract hidden data. I’m often doing this to examine what takes excessive doc space and how to optimize it:

1 Like

There are a number of threads about Coda vs. Notion. I think this should be very clearly stated to those who choose between the products.

I haven’t examined Notion. I wouldn’t be surprised if it worked the same there, just no Paul around to unearth that.

I think that the same way that the best door lock can’t prevent someone from breaking into your car ( they call always break the car glass) , a way to disable the copy button would prevent most of people from copying most of the docs. Of course that you would be an exception, but there aren’t many like you :smiley:, @Paul_Danyliuk. I learn a lot from your posts.

Breaking the car glass is a more morally challenging feat than finding a doc’s ID to copy it :slight_smile: With the car you know that you commit a felony by damaging one’s property. With the doc — not so much (unless you’ve signed an NDA, and the company can prove that you copied the doc and violated it).

Which brings me to another suggestion. We already have a “doc copied X times” counter. I suggest Coda adds a way to also see the list of people (emails) who copied the doc. This way even if one cannot prevent copying the doc, one can see who copied it (e.g. against the company policy) and take measures accordingly. @JonathanGoldman

And thanks Breno!


In many of my docs I now have names that I don’t want there anymore. How do I prevent them from showing up in a People type selector (ie remove them from my doc)?


1 Like

Hi Connor, we unfortunately don’t have a good solution for that yet, but if you copy your doc all the users like that who are unreferenced in the doc will be removed from the copy. But not sure if that’s a viable workaround in your case or not.

Thanks so much for the response. That’s not really a viable solution at the moment, since the doc is linked in many places by many different people, but I will keep that in mind for future docs. Thank you.