Treating the base table like a filtered view?

Hello! A lot of the docs I create typically involve a hidden “backstage” section, where all the base tables live, and then various filtered views on the visible pages. This works great, except I’ve noticed one downside:
Anytime users get emails that reference rows in a doc (getting tagged in comments or using the email-a-page functionality), the auto-generated links in the email always link them to the base tables in backstage.

I don’t want to confuse users by showing them the backstage area, but sometimes there could be sensitive information that I definitely don’t want them to see.

How are other doc makers dealing with this problem? Is there a way to set the Coda email links to go to a view instead of the base table?

I think another solution would be to treat the base table like a view (filtered and on visible pages), and create an unfiltered view in the backstage. The links would no longer go to the backstage. Are there any concerns with filtering the base table?

Yeah, big pain with it.

But I would still stoically stick to the principle of putting base tables into backstage and only showing views elsewhere. I would try to avoid links in the emails (i.e. I wouldn’t include raw Lookup columns in the views that get emailed but rather bring over the Text columns) or construct those links manually myself (through a dedicated Hyperlink() column) and hope that one day Coda adds the capability to select the default view to display links to, rather than give up on the principle.

P.S. Welcome to the community!

1 Like

Thanks for the response @Paul_Danyliuk. That makes sense to use hyperlinked text columns to circumvent this issue.

Stoicism aside, would there be any fundamental issues with treating a base table as a filtered view? It may add a bit more risk that the table could accidentally be deleted, but I think that would be the only downside? Docs that rely heavily on users commenting on rows—thus getting email notifications anytime there is comment activity—would be critical to prevent them from going backstage when they click on the “View Comment” link in the email.

I’m excited to to engage more with this community—thanks!

Fundamental issues — I guess no.

There’s one major difference between a base table and a view:

  • When you set a filter on a base table and then refer to the table in a formula, it returns all rows.
    I.e. the filter on a base table is applied for display only.

  • When you set a filter on a view and then refer to the view in a formula, it returns only visible rows, i.e. those that passed through the filter.

So technically:

  • a table is stored in a doc file as display metadata + actual row data
  • a view is stored in a doc as display metadata + a list of row IDs that are selected for display in that view. Unless it’s volatile and based on User()/Today()/Now() — then the list is calculated every time upon doc load.

Not sure if this affects the workflow much but this is a detail to keep in mind.

2 Likes

We’ve definitely seen that this is a need and we notice it with docs we use internally as well. There is a formula that gets us most of the way to a solution and we might dig into it more after some of our other projects finish up.

OpenRow(thisRow,[My Table View])

You’ll see that the formula builder help mentions “view or layout” for the second parameter, but we don’t have the ability to designate a layout yet. If you’re able to pick a view that’s outside of your hidden main tables section though, this might work for you.

Let us know if this helps out!

2 Likes