Hi there - hoping someone can help me with a specific cross-doc issue I’m having. I’m just learning my way through cross-doc functionality as I attempt to separate a doc into two separate docs - one that will be for my “users” and one that will be for my “admins”.
Some background - I have a table of Things that my Admins will manage. My Users will need to report in that they have created a batch of one of those Things.
To support this, I have a cross-doc Table in my Users’ doc for the Things table in the Admin doc.
For reporting in, I’m using the Add Row action to add a new row to a “production log” in the Admin doc to as to centralize where these activities are reported to. I’m following the method outlined here:
In my “new table” (in the User doc) that contains my button for the Add Row action, I have a column called “Thing Produced” and it is a Select List defined by a filter applied to the cross-doc table for Things.
When I add my row, using the user’s input, my row gets added correctly but the row reference to the Thing gets lost - it comes across into the Admin’s table as just a string vs. a reference to the row in the Things table in the Admin doc.
Am I trying to do the impossible, or am I just not doing it right?
Second question - is this the right way to setup this kind of structure? i.e. having “users” reporting in to a central doc from a “user” doc that is shared with all users, thereby keeping information exposure between “users” to a minimum and keeping central control over the data reported in the “admin” doc?
Regarding setting a reference vs string, here’s what worked for me:
— sending an actual Row object for the Thing in your case.
But if you can change your workflow where you can send a row ID / some other identifier instead, and do the lookup back to the Thing on the backend side, I think that would be more reliable than this undocumented behavior. It’s quite possible that this action isn’t even sending the Row object but converting it to text using some display value, then resolving that display value to an object on target table.
Yes, this is the right approach, although I’d say Coda isn’t really there yet to make it enjoyable.
Hi @Paul_Danyliuk! Thank you so much for your response and for the link to your guide. There are some excellent notes in there and I hope Coda takes note so as to address some of these key areas for improvement for Cross-doc functionality.
What I believe you are doing is exactly what I was trying to do, I believe.
In my setup, I have a temporary table to serve as the basis for the “form” that I open for users to do their data entry, and also to have a column for the Button to do the “Crossdoc::AddRow” action. One of the columns in this temporary table is a Select List based on the filter of an Cross-doc Table of Things - so the user would select one of the Things in the form. My AddRow action was trying to send the Row (as you were, as I understand it too to be a reference to the row in the remote Table) as well as other inputs for other columns on the temporary table that are all mapped to a remote Table.
On the remote table that I’m adding to, I have a column which is again a Select List based on a Filter of the (there) local table of Things - the same table that I’m importing as a Cross-doc Table. When my row is added, it seems to be doing exactly what you said - “this action isn’t even sending the Row object but converting it to text using some display value” - but that’s where it stops. It doesn’t resolve to the actual Row that is referenced.
My workaround is exactly as you said - using a different identifier and then having a column on the table I’m adding to w/ a formula to do a lookup on the identifier to capture a reference to the Thing I’m interested in.
This really feels like a bug (re: Row identifiers not being passed through and resolved properly) but would like to get some confirmation that this is the case, or a good explanation as to why a workaround like the one I’m using is necessary.
Let me know if I’ve misunderstood something and need to correct my approach.
This is fantastic as it fills in some key gaps in the existing documentation around Cross-doc. It would be good to update it based on how Cross-doc is available in Coda now - there are just some minor things that aren’t quite the same as they may have been back in January.
I really appreciate the note about referencing columns by their ID rather than their name in the Crossdoc actions - very smart, and not intuitive to an average user of Coda; agreed that a UI around this would be much much better to manage this.
The gotchas you captured as well are very solid points - I wish I had seen them before I started down this path as it would have saved me a bit of time trying to debug what I thought were problems but were just the gotchas.
I would love to see some traction on what the future looks like for Cross-doc functionality. For some background, this is a pretty key piece of functionality for building out more secure Coda apps for users of multiple Roles and needs. I can appreciate the complexity that is behind solving this but I can’t recommend it enough that this be given some focus.
Coda enabled me to prototype a solution which would have normally been thrown together as a web application. I was able to do it in less than a day rather than the week that it may have taken to achieve the same goal by prototyping a web application. This is an incredible benefit and I’d really love to keep being able to do this kind of thing, leveraging Coda, as a way of rapidly prototyping these kinds of solutions.
As it stands right now, the prototype is likely going to be sufficient to do some user testing and generate feedback on the concept and direction. But we are concerned that that’s where the benefit ends for us using Coda as a platform for these kinds of solutions. I’d be happy to share more insight into what I’m doing or where my frustrations have been if it is helpful to the Coda folks (tagging you @BenLee as I saw Paul do that in his other link and so I’m hoping this is useful for you as well).
