Launched: Manage workspace members from Workspace settings [Pro, Team, Enterprise]

News from Coda
1

Managing a team is no easy feat — especially when it comes managing members’ roles and permissions across your tool stack. Since launching the Coda Admin Pack, we’ve been grateful to hear your insights and feedback. Our top line takeaway was that while the power and functionality were there, it lacked the familiar flow admins rely on to navigate the dozens of tools their teams use every day.

Starting today, all paid workspaces can manage roles and permissions from Workspace settings. For admins of Enterprise workspaces — you’ll also see members’ activity, including their last active date and docs owned, so you can know how your team is using Coda.

Workspace-1280x720.jpg
Workspace-1280x720.jpg1280×720 225 KB

And yes, for all paid workspace admins, this update includes the ability to multi-select and manage your workspace members in bulk. No more million clicks, give your mouse a rest.

27 Likes
2

I fear I know the answer - but this doesn’t enable any sort of user permissions for clients, does it?

3

Hi Ryan, a workspace admin on Coda’s enterprise plan could update a user’s role (Editor or Maker). This changes that user’s permissions and ability to create docs. Other permissions such as sharing or access to Packs are not affected by this new feature. Hope that helps!

4

Do you know if its on Codas radar to introduce user permissions - in terms of client x can look at the same doc as client y - but client x will only see x material and y only see y material? As a residential developer I am constantly needing to share sensitive docuemnts with both contractors and buyers. Ideally - I would love to have coda serve as a client portal for the buyers and vendor portal for the contractors.

Do you know of any good workarounds?

9 Likes
5

@Elaine_Sohng is there any update on detailed permission per user on page-level? so that e.g. in one doc i can enable that certain user to see some pages, and some user can see everything.

The topic has been on the wish list for more than 2,5 years. Do you have a concrete time line?

The cross doc stuff is complicated and error-prone (esp. when it has to go two ways)

Please come up with a solution with permissions on page level soon.

4 Likes
6

Great question Ryan? I was wondering the sane thing too as I was looking into Coda as a toolbox for my company.

3 Likes
7

I vote on this feature as well. As much as I love Coda, not having the ability to restrict certain users to certain pages is preventing me from using Coda for more applications.

3 Likes
8

Hi all, thanks for your feedback on user-specific views. We oftentimes call that functionality “sub-doc sharing” or the ability to share a specific page.

Transparently, sub-doc sharing is a very common request, and one we’ve discussed at length (we’ve even Hackathon-ed potential solutions to it). The biggest challenge with Coda is that docs can be very interactive, and so defining how a “subdoc share” should operate can be tricky.

Some questions we have to answer:

  1. What should happen to views of tables that are not included in the share, or formulas that refer to other parts of the document?
  2. And how should we handle security for users that are creative at seeing everything that comes across to their machine - should we not transmit unshared data?

As we looked at some comparable products to Coda, many of them took shortcuts on these expectations, which we weren’t very comfortable with.

This is why we’re tackling this request in a few stages.

First, we launched cross-doc (with cross-doc actions) as a way to handle this for table data. Then, we started with what might seem like an unrelated launch, but is quite foundational: progressive loading of docs. We launched this as a performance improvement, but it’s also a key building block that allows us to start separating docs into parts, and not send all of them to the client. More to come as we build on this concept.

While we continue to think through this challenge, we’d love to know more about your desired use cases—please sound off in the comments! Key questions we’d love your feedback on:

  • What types of docs would you like to share subsets of, and how would you describe the shared subset?
  • How interactive would you want it to be (e.g. is read-only ok? would you want it to update when other parts of the doc updated?)?
  • And if you’ve already tried cross-doc, which cases did that solve vs. not?

We’ll keep you posted on our progress here, and hope you’re as excited as we are for some big upcoming changes to our editor and overall product performance that help us get further down the road on the request to enable sub-doc sharing.

Thanks!

5 Likes
9

Edit: added a remark about modal view of an object and some small textual edits,

Hello @Elaine_Sohng ,

Thank you for asking our feedback - this is a complicated and important subject that urgently needs attention. I think there are many user cases requiring different approaches and yes, I understand it can get complicated in a hurry.

I will try to address some of your questions and I will do so primarily by describing real life situations.

Starting with one of the last questions: how interactive…?
I distinguish four different scenarios:

  1. pages (information) where the user can’t interact with the data
  2. interactive pages, where the user can push buttons to, for example, activate filters or actions
  3. interactive pages where the filters are based on the current user()
  4. same as 3), but allowing the user to edit or add rows, while a user filter is intact

Having said this, I am assuming logged in users. If so, there is always a unique user().

The current locking and filtering options allow you to implement all of the above, with only one caveat: the user can go to whichever page in the doc they want. So, as far as I am concerned, if we can restrict the pages visible to (a group of) logged in users, we are all set. We, the makers, can make pages in such a way that the user only sees what we want them to see. We can specify if the user should be able to alter or add data and al the other editing options already exist.

For the users with limited acces, only data that is part of the user’s access permissions should make it to the browser. This would be quite different from normal use and result in a performance hit. But given te limitations, that would be acceptable.

So in my opinion it is pretty straightforward: If a logged in user has limited access, he only sees the pages he has access to. Examples:
Sub 1) a new product description
Sub 2) a range of articles, which can be filtered
Sub 3) a (filtered) table shows, for example, all the activities of (only) the logged in user
Sub 4) identical to sub 3, but with some permissions to, for example, edit the users’ own address.

All of the above is already available to us with one big problem: the rest of the doc is visible too…and accessible.

If I were to allow a user to change his address, I would grant them access to only the relevant pages, this user would see a very small doc. And perhaps the user would be granted a view to his performance page, without the possibility to edit.

Permissions should include subpages, until changed. All pages should interact according to set filters (like having a field interact with other pages to field a related value or use going to a lookup table), etc. For the user with limited acces, this is standard behavior.

With the above in mind, there is probably one extra locking feature necessary: to not follow the normal action when you click on an object and end up with a modal of that object. Only a button to a modal should work to make sure we don’t give access to data that are not meant to be edited (or viewed).

Cross doc is to slow and to cumbersome to build and has limited capacity. It is not a realistic option for people that need to access real-time data.

6 Likes
10

Hi @joost_mineur, thanks for sharing the details of your needs, the specifics are quite helpful!

This is very aligned with how we’ve been thinking about the range of scenarios and requirements as well.

I’m curious how often you’d want to selectively share (1) a single page; (2) a single page and its subpages; (3) a subset of multiple pages in the doc, and if you have examples of what’s spread across pages.

2 Likes
11

EDIT: I could live without option 4) (where it said 3) in the original version)

Hey @Nathan,
I have been trying to put as much as I can in my main-business doc. My ideas for the future for this doc are the following:

  1. the doc is shared in edit mode with my team. Locking is in place to make sure they can use the tables, buttons, record keeping, etc. without destroying the doc or altering the tables.
  2. there is sometimes confidential of privacy sensitive data that I only show in certain views, the pages with these views would be in a section where only a subset of my team would have access too.
  3. there are client records that I would love to share with my clients, I would have views of my tables in a section where almost everyone has access too, and filters would make sure clients only see their own data. These would be clients with login access.
  4. there would be pages with program defaults, base tables, master tables, etc. that would be accessible by just me and a developer.

I would organize this probably by having a standard doc structure (accessible by all of the team) with pages and sub pages, there would be a ‘main menu level’ with pages called activities, client info, invoices, general business information, planning, etc.
Then there would be a single page with subpages for my clients and another singe page with subpages for the developers.

So, as an answer to your question: sub 1) would not happen very often, sub 2) most of the time and sub 3) well, if it is available we’d probably use it, but the way I see this I could easily live without option 4).

The power of Coda with its views and adjustable modals makes it very easy, if the permission system can really protect the data from users clicking on anything you can click on, to set up the doc in such a way that you can build it in major sections starting with permissions on the main level.

Obviously you can think of scenarios with client or team sections where some clients or team members can dig a bit deeper than others, but that could, again thanks to views, also be covered from the main (‘menu’) level.

Let me know if you need more inspiration - there is plenty more given enough time to write it all down :slight_smile:

5 Likes
12

Thanks for sharing, @Elaine_Sohng , I really appreciate you taking the time for sharing Coda’s considerations with us. It’s deceptively easy as a user (aka me :wink: to think “Just give us user-specific views” and it really puts things in perspective to take a moment to step back to see how this “tiny” piece of the puzzle has to fit in the whole puzzle in order to work.

1 Like
13

I really enjoyed your detailed take on this matter of permissions, thanks for sharing, @joost_mineur !

1 Like