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.
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.
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?
Create Doc #1 that uses Global-Document-People to create a table of Coda Persons
Create Doc #2 that pulls in the table from Doc #1 using cross-doc
Doc #1 breaks because it’s using hidden objects
What happens to Doc #2? Will just the table in Doc #2 be broken or will the whole doc be broken?
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.