Limit stream access to registered users

Hi all,

When a Speckle server is set up within a company, it would be very helpful to have an access level option of “registered user”. This would allow free sharing of data withing the server (and with any collaborators who have access to the server), without requiring either free access to the data to anyone, or adding each individual person to the stream.

Would this be useful to others?

This is something we’d be happy to contribute, and I thought I’d float the idea before we slot it into our plans.

6 Likes

Good idea! I can see this being useful. You could share some example streams with everyone on the server without sharing it with the whole web.

Edit: thinking about it, it might also be useful to differentiate between colleagues and external collaborators. E.g.: example streams containing company sensitive data you’d like to only share with colleagues, but not with clients or other parties.

4 Likes

Hey all, this is a good shout. How we are thinking to implement this is around the future concepts of “Teams” (or organisations), rather than just blanket server-wide. One default team could be, of course, the whole server, but it’s important to have this concepts a bit better baked in.

This will be a deep auth & permissions change that will have quite a few ramifications across the whole server code, so, if not urgent, I’m going to play for buying ourselves some extra time to think and scope it out in the near future before we jump on it! We’ll start a thread in the coming months on getting this fleshed out.

2 Likes

Hey @dimitrie, I understand that a proper implementation of teams / orgs / projects in definitely non-trivial, and thought that a server-level access level would be a simpler step that would still be useful no matter what the details of the teams / organizations system ends up being.

Within Arup, as we look to move Speckle from being a tool for tech-savvy early adopters to being a platform that changes the way whole teams collaborate, support for projects or teams is a key capability to support this.

We are planning to start our big v2 rollout in October and I would like to have something minimal in place by then. A short-term solution we are considering is to tag streams with project numbers (using Globals), and to create a plugin webapp that shows all the streams for a given project, allows the creation of streams (with the relevant tags filled out, and provides a shortcut for assigning access). This is a bit hacky, but will allow us to gather feedback and support early teams uses and then eventually migrate to the new system.

1 Like

Hello @dimitrie and the wider Speckle community,
I also think the “user group” or “team” permissions would be a great feature. We have a use case where we would like to set up a “collaborative” environment on a project server where all registered users would be able to contribute to a given stream. By everyone, I mean a team of 20 to 30 people who might change with time. So having to set personal permissions at the stream level every time the team grows/shrinks seems quite a hassle.

On that note, while waiting for a long-term solution, is there a way to get a list of all registered users on a server? I know we can query the api for a specific user but can we do that for all users? That way I can programmatically set permissions to everyone registered whenever a new stream gets created - a temporary workaround to the above mentioned issue. Or do you maybe have a better suggestion on how to deal with this?

Thanks a lot for your time :upside_down_face:

Edit: Also, is this considered the correct/fastest query to grant permission to more than 1 users in the same request?

mutation { M1: streamGrantPermission(permissionParams:{streamId: "xxx",userId: "yyy",role: "stream:contributor"} ), M2: streamGrantPermission(permissionParams:{streamId: "xxx",userId: "zzz",role: "stream:contributor"} ) }
I tried passing a list in the variables but it did not work. :frowning:

2 Likes

@gjedlicska is working on this right now, as part of the admin features bucket list effort!

To prevent future spamming, the api is restricted to one user permission grant per call. Nevertheless, until we get to implement rate limiting (wow, this issue will have its one year birthday soon!) you can probably get away with sending those in a for loop :sunglasses:

While I realise this doesn’t really solve your short term problems in full, I’m actually happy these problems exist, as it means you’re probably putting speckle through quite some exercises :raised_hands:

2 Likes

Hello @SpeckleTeam,
It’s been a while :slight_smile:
We’ve been enjoying most of the recent updates to Speckle a lot, great work everyone!
However, the issue in this thread is still present unfortunately :frowning: . The recent server changes actually made our lives a bit more difficult.

Let me recap quickly!
Use case: We have a private project-specific Speckle server with 56 registered users on it. We create a substantial amount of streams (170 over the last year and growing weekly) on that server. Out of the 56 registered users, only about 20 are actively involved in the “production” process daily although this number is quite dynamic; the rest is a mixture of people who don’t need to be kept constantly in the loop. We work on streams collaboratively - all the 20 members of the “production” team might be required to view, edit and contribute to the streams at certain point.

Old strategy: With the previous version, we could sneakily give all registered users a collaborator role. Most of the people outside of the production team did not even know about it although they could go on the web page, check progress and review streams.

New situation: With the latest updates however, we were forced to explicitly send invites via mail to all registered users. Bear in mind that in some weeks, up to 10 new streams might be created - meaning 10 emails to all 56 users.

Solution (sort of): Since people started complaining about the constant “spamming”, we had to find a temporary solution to create our own user groups. In order to make sure these groups are dynamic and can be updated by admins to reflect changes to the team’s composition, we needed a smart location where to store them. Our solution for now is to store the groups in a dictionary as part of the global parameters on a generic empty Speckle stream (used only for this purpose). Kind of hacky but seems to work.

I know that our use case is somewhat special but I am still wondering whether some general permission setting features are coming down the road:

  • grant access to all registered users (view or edit)
  • implement custom user groups
  • option to not receive emails but only a notification on the webpage

Or anything in that line of thoughts?
Apologies for the super lengthy post! I hope we can have a chat about the possibilities. Maybe there’s something that we overlooked :face_with_monocle:

Thanks a lot,
Mariela

2 Likes

Hi @Mariela_Tsopanova, the issue is indeed something on our product agenda - having its birthday too. We plan to solve within a different scope though - that of organisations, which will be a new entity and will allow you to control this behaviour. A server will be able to have as many organisations as needed (mind you, naming might change - you can also look at them as teams, or your custom user groups).

I do understand your pain, and as y’all at Arup are close to our hearts I’ll see if we can provide an escape mechanism by adding another option in the notification preferences to not receive stream invite emails - I’ll have to ping @gjedlicska on this one. That would be the easiest solution from our end that we can commit to enacting fast (and maintaining in the future)!

3 Likes

We can add a server level notification settings panel, that can be used to globally disable notification topics and channels.

It could use exactly the same constructs and components as the user level settings do right now.

The only drawback there, that @Mariela_Tsopanova and the team should be aware, that now you need to proactively accept the stream invitation to be given the intended stream contributor role.

Without the emails, users need to rely on the frontend banner invite notifications, that are kinda ephemeral and if you have 10 of them / week, they can be a PITA too.

I’ve added an issue to continue the planning discussion there.

4 Likes