When designing workspaces in Coda, I keep running into an inconvenient problem. When activating the item: “Open row for editing” in the buttons that create a new row - the new row is opened in the parent table by default. I have no possibility to choose in which view to open a new created record. I know there is a workaround where you can add a formula and compensate for this inconvenience. But it is not always convenient. I would like to use this as a native feature.
The problem stems from the limited capabilities of granular access. You have to design the doc architecture in a certain way to separate private information. And the key problem is that in most interactions, the user can get to the parent table when they don’t need to.
I would like to have more control over which of the views the user switches to after pressing the button in scenarios when a new row is added and the open for editing function is activated.
Additionally, I would also like to set the standard popup button “Expand Row” to allow the user to choose which view to open by default, rather than the view from the parent table.
hi @Tamerlan_Kagarmanov ,
The issus is partly related to an old syntax Coda operates
instead they should offer something like below:
openRow() function you can also select the view.
I wrote partly related, the main issue is that permission management is not yet well established in any doc. The solutions the Team plan allows for are at best work arounds.
I am looking forward to the moment that
- editors become real editors instead of makers light (we thus need more makers in our plan) and thus makers pricing will align
- we are in stage 4 of the two way sync so we can easily split data
The link to the parent table should indeed be an option, the existence of the parent table in any view generates a lot of problems and you can only fix this (duct tape) with automations and buttons that create a new table. This is a form of complexity I try to stay away from.
Maybe for X-mas 2024?
Oh man, been wanting this from day one! I’m able to create different views of tables for different contexts, but the edit view in those different context is set to one.