Is there a Coda Person collection object that allows me to write a formula to find any Coda Person based on their email?
For example lets say I have a table with email and a Coda Person column type. I want to automatically set the Coda Person based on the email in the row.
Thanks
yep you can, so email is the property of the person you get via chaining
User().Email
cheers, christiaan
No sadly you need some sort of helper table like the DocAccess table in the Doc explorer pack.
This allows you to sync in everyone who was access to a document and then you can use a normal coda filter to locate the person object you are after
Doc access.filter(email=thisRow.email).person.first()
That will only work if every person you are after is shared with a document.
I believe the coda admin pack (available to enterprise) has a table to sync all workspace users though.
Technically possible but this may get you in trouble. There is a system table Global-Document-People that lists every person that had to ever do anything with this doc such as open, be referenced or be shared with.
This is a hidden table though, so accessing it might get your doc disabled at a random instant. Even to access it you have to use the $$[] ref syntax like $$[grid:Global-Document-People:::false:false:_Global Document People]. So sharing this here only for the answer’s completion.
The best way is to just collect a table of people, and whenever a new person joins the doc, prompt them to press a button (e.g. like this) and the button then would add that person to the table.
P.S. Another thing that might be possible is resolving the person through a pack. IIRC a pack expects you to specify the person’s email to return you a Person object; you don’t have to know their IDs or whatnot. So it’s possible to make a custom formula and a custom column format that would take in an email and convert that into a Person object.
Very interesting and thank you @Paul_Danyliuk!
I know that any doc using hidden objects/formulas could break at a moments notice and may not be recoverable back to healthy state (evening using the history). Curious though if there’s a workaround to mitigate some of the damage. Do you know what would happen in this scenario?
Scott the rescue again! I didn’t know about the Coda Admin pack. Very cool I think that may solve the problem.
The table will be broken, but how can you be sure that every person will be listed on the Doc #1? AFAIK it requires an active engagement of that user (or the user being referenced at least once) to be on that table. The table doesn’t list anyone who’s in the workspace or the folder but never interacted with the doc.
A better way would probably be to just not use the above expression in a live formula. It could be safer to use it within a button and upsert missing people into an otherwise editable table upon the click. Can’t guarantee that it’s 100% safe though: all I know is that I had one doc disabled where I was actively reading from document-global-people with a formula and then I had another doc where I had that in a button and to this day the doc is alive.
Oh, and that solution from my P.S. in the above post. That’s worth trying too. I haven’t done that but in theory that should work.
Admin pack will only work if you’re on an Enterprise plan, as far as I know.
So glad! You can also if you don’t have enterprise, use the dock Explorer pack
But again that comes with the caveat that it only syncs in every individual who is shared explicitly on the current document
If is not explicitly shared with a lot of people, you can make a dummy doc that is shared with everyone and automate that sharing, and then use the doc explorer and reference that document
@Scott_Collier-Weir rats! The Org Users table in the Coda Admin pack doesn’t have a Coda Person table column so back to the issue of not being able to auto create the table with everyone in the org and a Person column that ties to their Coda Person object.
Just recreate it then!
Shouldn’t be hard if the endpoints are exposed.