PSA: You can have different users doing calculations with different values in the same rows

Showcase Tips and Hacks
1

Adding the capability of multiple users doing different calculations (with different input values) at the same time using the same doc is surprisingly simple with Coda. You don’t need to duplicate and then filter the rows for each user. Looks like if you have dependency on User() anywhere in a formula’s dependency graph, it will only calculate that on the client side and never share the value with other users.

See how two instances of Coda show completely different numbers in the same table without clashing:

image
image1920×1080 214 KB

Drawback: in this setup Automation most likely will see an empty table, since automations by default are run by Automation Bot system user. You can set up automations to run as any actual user though.

Also, need Codans like @Krunal_Sheth to confirm if my low-level assumption is true: values calculated by formulas dependent on User() anywhere in dependency graph don’t propagate to other connected clients and don’t get saved to snapshots (i.e. are always calculated on the client) — aka volatile functions

2 Likes
2

Hi @Paul_Danyliuk,
Great and very explanatory example (aside from the fact that the two users are both yourself and it took 3 minutes for me to get it. But it’s because I’m stupid :grimacing:).

I can only confirm your assumption based on my (tested) implementations: I actually tried muti-user setup with the User() column throughout the dependencies tables and overviewed in real-time.
In my opinion, ActiveUser could eventually become a basic column property, though I’d place it lower in the backlog list.

Many thanks, as usual, for explaining - more or less obvious - functionalities so well.
Cheers

3

I make great use of this by first creating a table of my ‘Members’ - all of the users (and other non-codans who could be involved in the project), where we can have more attributes/columns for each members.

Then I create a global formula/variable called ‘User Member’ == _Members.Filter(Member=User().Name).First()

This allows me to reference the logged in user anywhere in the app. Further, you can have attributes/states for each member by having a column in the [_Members] table, and then you can quickly reference it anywhere with `[User Member].[State]’.

It gets more fun by using buttons to allow each user to toggle their state:

ModifyRows( [User Member], _Members.State, [User Member].State.Not() )

2 Likes