Roles & Permissions

[Brian_Sowards]

Hey community!

Coming off the presentation on “2022 Year in Review” Webinar with Shishir, we want to kick off crowdsourcing answers to the two key questions he asked on Roles & Permissions.

[I’ll add the link to the recording here when it drops]

Shishir’s two questions:

How would you like to think about data and calculation boundaries?

When determining who can have access to a cell or data, how do you think about who should have access?

I think it would be great for people to respond here with use cases, things you are trying to do like:

• Creating a client portal where your client can see how many hours you’ve worked and invoices
• Building a list of potential candidates to hire at a startup with their requested salaries, but only certain HR leaders can see that number while everyone else can see the application

One item to think about: performing calculations on data. For example:

• Only the sales leader can see what every sales person on the team sold, but everyone could see the sum total of the team

It would also be great to get examples of things you wanted to be able to do for your clients and how you were unable to solve it in Coda today.

Shishir’s next Q:

If you receive a link to a subset of a doc (page, page set, etc.) what container do you expect to receive it in?

In other words, what would the person on the other side receive and what controls would you (or they) have over it?

Wizards like @Leandro_Zubrezki might have a wireframe for what would work here.

Perhaps a shortcut here might be something like the formula bar that only the Doc Admin could see & edit.

Personally, I’d love to see an upgrade to the Page formula, the Button formula made official, and a v2 of the Detail view. Combined with formulas on filtering data based on roles/permissions using the Coda User ID/Auth, we could solve for most of our use cases.

---

A bit on the Supersynchronous journey

From Day 1 we’ve aspired to be the Enterprise partner for Coda. Security, roles & permissions, and scalable workflows have been something we’ve thought about every day and tried to problem solve for.

At this point we simply tell our clients they cannot solve for roles & permissions or scalability in a Coda doc. We regularly say:

• “If they have access to the doc, they have access to the data.”
• “Coda is best used as a single doc for your org. It doesn’t really work to have multiple docs because they don’t speak to each other well.”
• “Coda does not have a good solution for two-way data syncing with Packs or docs. We’ve built something that works (ex: Affinity Pack), but it takes expert devs to customize it to your use case.”

We’ve accepted that Cross-doc cannot solve the problem of scalability. Prolific producer @Scott_Collier-Weir has provided some solutions here. (Scott, curious for your POV here!)

I’m personally excited about the potential of using Coda with Xano (https://www.xano.com/).

If Coda could solve the roles & permission + two-way sync problem, we could solve the scalable/cross-doc problem with Xano in every use case we’ve come across.

I remain enthusiastic that Coda is the ultimate workflow design tool for Enterprise orgs if these issues can be addressed.

Look forward to everyone’s feedback!

[joost_mineur]

Hello @Brian_Sowards ,

I have written many times about the role&permission issues we encounter.

There are 3 main areas where we need solutions:

1. setup and backbone pages: this area of the doc should only be accessible to users with a doc-admin role. This is were our base tables, base formulas, parameters, and developer notes reside.
   Any formula or view on the ‘standard’ pages should have access to whatever is stored here, but a ‘standard’ user should not see these pages in the page menu, should not have access to these pages and should not find himself on one of these pages after clicking on a ‘return to table’ link on modals, detail views, modal menu’s or by any other means.
2. Hidden pages: similar to sub 1), but hidden pages should be hidden for ‘standard’ users. No visible menu options to hide/unhide hidden pages, etc. I will leave it open to discussion if a pagelink to a hidden page should be visible and can be used by ‘standard’ users.
3. Assigned page access to named users, including automatic access to subpages. This would allow for customer pages: either one page correctly filtered or many pages each for a single user (client). This could also be accomplished by roles and setting a page (or section) as ‘client pages’ and assigning the role ‘client’ to specific users. It can be named whatever instead of client of course.

Regarding the above: in my opinion any page should have access to all tables and pages in the doc. We have enough tools (locking, filtering) to create safe pages if we know the users are confined to the pages that are assigned to him through his role or direct acces permissions. Actually, it would be nice if we can define roles ourselves (client, sales, support, admin) and then assign one or more roles to each doc user.

I have build something like this (in Coda) that worked really well and seemed pretty save, except for one thing: it depended on canvas rows and canvas cells are the most unsafe thing in Coda: through the canvas cell you have access to every table in Coda, you can (reset) any filter, you can delete table data at will, you can kill the template structure of the canvas cell, etc.

I prefer option 1, 2 and 3, but have locked canvas cells would help. Unlocked canvas cells are nice for free form notetaking and adding private tables, but they need a) the standard locking options that we have for normal pages and b) extra locking options to not have access to a docs tables, unless they are placed there or made accessible by a doc maker.

I am sure I am skipping some details here, but this is pretty much what I am looking for.

[Billy_Jackson]

Thanks @Brian_Sowards, good to continue this conversation after the year in review.

Agreed that this is a pretty big limitation that affects almost everything we do with Coda, and keeps me anxious about dedicating any further resources to the platform.

Speaking in terms of end-user functionality, I"d like to mirror what @joost_mineur says in that we need:

1. A way to wall off certain pages based on username/role - i.e. clients can see the client dashboard but nothing else, etc; admins can see backend, users can’t mess it up
2. A way to wall off certain row data so that only certain users/roles can see it - visible iff it passes through a filter. i.e. clients can see any task assigned to them, but not all the tasks related to the fires we’re putting out behind the scene.
3. A way to wall off certain column data so that only certain users/roles can see it - i.e. everyone should be able to see WHO is hired on Project X. Only Managers can see pay rates, for instance.

Some thoughts on implementation:

1. Seems straightforward (in a relative sense) to extend doc permissioning to the page level. Alternately, if docs could access data/tables from one doc to the next, you would theoretically not have to even include this permissioning. You can just wall things on a doc-level.
2. This has been (semi) solved by @Paul_Danyliuk (who I hope will forgive me if I mess up the details) but creating a column that contains an access key/or access role-list (would have to be a special column type) can determine which rows are accessible to which users. If you allow this row to be determined by a formula, you can formulaically provide access on a row-level. Underlying values in this column would have to be calculated serverside.
3. Include a setting (inside the column options) that determines who has access to that column - either directly or via formula. Combined with suggestion in 2, this will allow you to create an access column, LOCK the access column from everyone except for admins, and the whole table is walled the way you need it to.

You and Shishir both mentioned “formulas - visible to all - that require access to certain pieces of data - visible to only some”. For me, this would be a “nice to have” rather than a “need to have” like the above, but I imagine that it can be treated as a special case. Formulas - in general - do not have access to data their users do not have access to. However, someone with a certain token can “authorize” a formula to use their access permissions (would obviously have to be run serverside). This feels like a place I’d be happy to use a special pack, because I am struggling to think about a use-case where the person implementing this is not quite advanced.

As a disclaimer:
I am - at best - only knowledgeable enough to be slightly dangerous with this sort of stuff, and am certainly naive to the intricacies of what has to happen behind the scenes to make these things work. By no means to I intend to suggest that this work is trivial. However, I do suspect that it is possible, and I hope that my input here - if overly obvious - is at least helpful in communicating the functionality I hope for, if not the architecture required to provide it.

[Susan_M_Davis]

This is perfect timing as I have spent the last week dealing with this very issue! UGH! First Coda was acting odd with formulas. Formulas I’ve used many times to allow user access were failing to function in filters. Even Coda support couldn’t explain why every filter was failing and then showing all users every record! Finally had to do some ugly work arounds. Hoping Coda fixes that formula issue soon. Near as I can tell it has something to do with the new Filter Bars being added. Formulas that worked prior to it’s introduction now fail. ODD!

This is messy because my brain is fried from dealing with these issues all day but some thoughts.

1. Page security isn’t too bad but could be improved upon.
2. Table security is where I’d see the most benefit.

• show/hide columns based on formula could be useful for more than just security
• ability to prevent user from clicking on linked table and getting to that info
• lock columns to prevent editing based on formula
• better way to handle editing data in the popup – ability to lock columns here to display only or edit (heck why not an edit mode vs a view mode!) – how about data validation in this edit popup similar to what is availalbe in the “form” mode.

3. If I send a user some data and that data has a lookup, I don’t want them able to click that lookup and get access to my doc! Currently have to do a lot of creative Codaing to send them only text rather than actual data which takes more time.
4. If I send a page, I want my user only to see what I send them and NOT be able to access anything in that emailed page and get back into my doc!
5. While we’re at it. Seriously, why can’t we have a button to save page to PDF? It’s up there in the page drop down menu being able to convert the page to PDF and then send it would resolve #4. Shouldn’t be difficult to code since the item already exists! Just need to create the access from it from a button.

[Susan_M_Davis]

OHHHHH AND!!!

If I hide pages I don’t want users able to find them and definitely don’t want them able to unhide! Seriously, what was the point of hiding them if the user can just click and unhide. If I take a user to a page via a link, I don’t want all the pages above that page to now be visible to them! Only solution now is not to make subpages, but then that removes the usefulness of subpages.

And if I have hidden pages or if a table is filtered so my user cannot see the data, then they certainly should NOT be able to use the search bar and find the hidden or restricted data.

While we’re wishing and dreaming, how about a navigation bar. Coda has one because when you publish a doc to the gallery, you can choose to have it shown at the top. How hard is it to create a navigation bar item where you can have certain things repeat at the top of pages that have the navigation bar turned on? I’ve kind of built my own for this but it has a few quirks due to how it has to be implemented.

[Cari]

I created a Doc for our club. I was shocked when I discovered that regular users (editors) have the ability to change the column titles. I thought only Doc Makers could do that. I know most of you are talking about more detailed roles and permissions than this. But I think column titles should be uneditable by editors by default outside of separate roles and permissions that might allow it. Isn’t that part of being a Doc Maker?

Anyway, someone who was supposed to only be adding and editing club members changed a bunch of column titles and it has taken me hours to figure out what some of the checkbox columns were tracking because I had several and they ended up being named “false”, “false 2”, and “true 2”. Those checkboxes had important purposes that only I, the Doc Maker, was privy to.

In the future, I will take screenshots of my Docs and make external documentation in case this ever happens again. I just can’t figure out why an editor would ever need permission to rename column titles. Rearranging columns to meet their needs I do, but not changing column titles.