In case you didn’t notice it yourself, Coda cross-doc already supports adding, modifying, and deleting rows in other docs.
This isn’t hidden functionality: it’s in the formula editor hints as well as the docs. However it seems it’s not quite ready for release too: the UI for setting this up without a formula is still incomplete, and the docs leave quite a lot for you to figure out on your own. Hence this topic to clear things up.
First parameter is the connection. It should have write access to the table you’re going to write to.
Second parameter is the table URL in format {doc URL}#_tu{table ID}. You can get it by e.g. taking a Row object of any row imported through Cross-doc from that table and removing the row ID part:
Next are column name/id and value pairs. It’s better to use column ID and not a name, because otherwise this will break if you change column name eventually. To get column ID first enable Developer Mode (https://coda.io/account -> Labs), then right-click on the column and you’ll see the Copy column ID option there:
Same for ModifyRow and DeleteRow, only that you need to use Row URL (full Row.RowUrl from the row object), and to delete a row you don’t need to list the columns.
Gotchas:
It seems there’s a bug that won’t update the source table with the changes until you reload the tab with the source doc. @BenLee would you please log this for engineers to look into? Same happens sometimes with the data updated via API/Zapier too, so I think the problem exists on the API/messaging level.
I haven’t found the way to also trigger cross-doc table sync via an action (i.e. to pull the data after pushing the change). Right now you have to either do it manually or wait for the next auto sync.
Just tested, and actually you need both read-write access to the table you want write to. Simply write access won’t be enough.
Also the referenced table must be a table (grid-xxxxxxxxxx), not a view.
So the only way to make a submission form where a user won’t be able to also read all the submissions is to either filter out all rows on the master table, or hide all the columns. Then use views in the source doc to review all the data.
You just press Share and select Embed. Then enable Play mode and probably disable the Sections list. Then copy the code it generates and paste it in your website… or here.
Oh, and the doc must be editable for all, it seems. Otherwise cross-doc actions will not work. So there’s a risk of someone opening it in the separate tab and messing the doc up.
When setting up the table, there should be shared permissions for Editors to be able to click buttons and take actions as well. Click on the gear icon at the top right, choose “Packs”, choose “Cross-doc” and then look under settings. If the connections are under “Shared accounts” then editors should be able to use as well.
I am new to cross-doc actions and am finding it difficult to find detailed instructions. Your example with the form front-end and database back-end seems to be exactly what I need to do.
Questions:
I copied your 2 example files (front-end and database). What do I need to do to make it work in my own workspace?
In your database doc, you state “The table must be filtered off (formula set to false) or all columns made invisible…” What do you mean “filtered off”? Alternatively, if you hide all columns, there’s no issue with adding a new row with all the columns?
As for the first question, you’ll need to replace these with your connection and your doc/table URL. Since you’ve copied the backend doc, the table (grid), view, and column IDs should remain the same, and you’ll only have to replace the _dXXXXXXXXXX doc ID part:
Then, of course, if you change the columns, you’ll have to update the formula to write the data you want to your own columns.
As for the second, let me try to explain this in more detail:
To perform a cross-doc action, you need to do it by main table URL, not view URL (i.e. #_tugrid-xxxxxxxxxx, not #_tutable-xxxxxxxxxx). This ought to be fixed, but I’m not sure if it has been. @JonathanGoldman you posted about APIv1, maybe you know?
For that you need API token to the main table, with both read-write access. This means that you expose a connection where anyone who uses your form doc can load everything that’s in your main table. Normally I advise to import views, to have fine control on what’s visible (which columns are visible and which rows are not filtered out on that specific view). Also normally I advise to keep main tables always ungrouped and without any rows or columns hidden. But in this case you need to do it the other way round, because you cannot use a view URL with cross-doc actions (afaik).
So what I suggest is that you either hide all your columns from the main table, or hide all rows (filter out, “filter off” as I erroneously said) by using a fake filter with a condition e.g. false (returns false for all rows and hence zero rows visible through cross-doc). This is so that even with read-write access, no one using your form could load any data from your back-end table (because there won’t be any data to load, because either all rows or all columns will be hidden).
You can still make yourself a view of that table with nothing hidden and use the table as you normally would.
P.S. The requirement for read-write access also seems like a bug to me. Just write access should be enough to be able to perform a cross-doc action on that connection but not load the data from that table. I hope this is either fixed already or will be. Personally I’m not using cross-doc actions: they become terribly slow when the receiving docs are significantly large (my typical docs). I prefer other options like “inversion of control” (using cross-doc sync, not actions, other way around), 3rd party forms, or Integromat/Zapier-based syncs (slower but asynchronous).
Thank you so much for your detailed response. It is much appreciated.
Unfortunately, I was not able to get the example to work. After I made a copy of the form and database, for the Submit button, I confirmed that the first parameter was “Read-write access” and updated the table URL. I filled out the form and clicked the Submit button, which resulted in the error “Crossdoc::AddRow failed – Could not find or access this Coda object. Check that the credentials you’re using are for the correct table.”
Questions:
When I made the copy of the form and database, there were 2 options for shared accounts to the Answers table – image attached. I chose the one that ended in “(6)”. How do I know which one to choose?
Where is the actual cross-doc table in your example? I did not find one, even though I saw that the pack was installed in the forms document.
What can I try to get this to work?
Is there a detailed reference guide on cross-doc actions?
On the second point about hiding columns or using a fake filter, I tried this in a test document. I hid all the columns in the main table and sync’ed from the test document; however, only the cross-doc column (“Row”) was brought over. If there is no data in the sync’ed copy, in what context is it used?
I had a great conversation with @BenLee earlier today about cross doc actions, and we were able to get @Paul_Danyliuk ’s example to work in my workspace. So, I thought I’d share the steps of how we got it to work. I’ve tested these steps a few times to verify that it’s a repeatable process.
@Paul_Danyliuk ’s example is really good for mimicking forms and writing to a main table in a different doc to prevent a user from accessing and viewing the contents of the main table (e.g., for security concerns).
Open “2-way Cross-doc: front-end” and “2-way Cross-doc: Database” (from the original post above) in Coda.
Make a copy of these files. When making a copy of “2-way Cross-doc: front-end”, there will be a pop-up with the instruction “Connect this doc to Cross-doc”. Select “Connect later” at the bottom of the pop-up.
In “2-way Cross-doc: Database”, anywhere on the “2-way Cross-doc demo: Database” page, type in the formula “Answers.Url()” to get the URL of the “Answers” table.
In “2-way Cross-doc: front-end” on the “Please fill in the survey” page:
Unlock the page to allow editing.
Go to Explore → Packs → Cross-doc and drag the “Answers” table from “2-way Cross-doc: Database” to the bottom of the page.
Once the “Answers” table has been synced, immediately delete this synced “Answers” table. This action helps to create/list the proper Shared Account needed in the next step. [We discovered the necessity of doing this step during our troubleshooting why the connection was not listed in Shared Accounts.]
In the Cross-doc menu, go to Settings and under Shared Accounts, change the drop-down value from “View data” to “Take actions and view data”.
On the form, click the kebab menu and select “See this in HLP Survey form”
Unlock the “HLP Survey form” page
In the “Submit” column, click the Button options
Change the Action:
Delete the first parameter “Read-write access …” and select the first option “Read-write access …” which is the correct/updated connection for your account
Update the entire second parameter with the URL from step #3 above.
Test the changes by:
Filling in and clicking the “Submit” button on the survey in “2-way Cross-doc: front-end” on the “Please fill in the survey” page
Going to “2-way Cross-doc: Database” and refreshing the page to see that the data from the newly submitted survey has propagated to the “Answers” table (or “View of Answers”).
Oh, sorry @Patricia_Liu that it fell under my radar and I didn’t respond. So overwhelmed lately with work and life. Happy to hear that @BenLee helped you to figure it out. Correct, when you copy the docs, you need to re-link the cross-doc connections, otherwise you’ll be trying to read and write to the original doc.
Two useful formulas for Cross-Doc Actions.
Put them at the table, whitch you’d like to modify to get the table ID or the row ID for coding Cross-Doc Actions
Table ID for Add Row -Concatenate(Split(Url(thisRow),"#").ListCombine().Nth(1),"#_tu",concat(thisRow+"").Split("/i-").ListCombine().Nth(1))
Row ID for ModifyRows - Concatenate(Split(Url(thisRow),"#").ListCombine().Nth(1),"#_tu",concat(thisRow+"").Split("/i-").ListCombine().Nth(1),"/_rui-",concat(thisRow+"").Split("/i-").ListCombine().Nth(2))
It would be nice if they will be built-in formulas as Url(), but …
With my cross-doc actions, I use column name text. Are those you are using column names or some sort of column id? I see the benefit of using id’s as if the column name changes the action will still work. I’m just trying to clarify how this formula works since the documentation does not say.
