Permission model for internal use inside a company

Forgot to mention: if we're going to the trouble of setting up our own Loomio instance we'll want to make it available for some friends outside of our company as well, so we'd probably have one parent group for our company and add sub-groups for the different teams there. So these permissions could maybe be implemented in the form of a group-level setting to "allow group members to see/participate in all sub-groups"

Hi toupeira!

To my mind the settings that would make sense would be to have the parent group Secret (so no one who wasn't a member could see anything about it or its subgroups), and then have the subgroups set to "Members of (Parent Group) can see threads" (this permission is under Advanced).

One thing I'm confused about: "allow everyone to participate without being a member of that group". What would it mean for someone to not be part of the group, if they were able to fully participate in it?

Thanks for your quick answer Matthew, didn't notice the different settings on sub-groups. And yes this sounds exactly like what I was looking for!

One thing I'm confused about: "allow everyone to participate without being a member of that group". What would it mean for someone to not be part of the group, if they were able to fully participate in it?

We're trying to establish interest groups in our company that will look after certain areas, e.g. an infrastructure group, a customer support group etc. At Spotify they call this "guilds":

The idea is that certain people will take over strategic responsibility for areas they care about and work out / implement proposals. A small number of people would be considered the actual "owners" of a group, while all employees could be considered "members" that can participate. So I guess what I'm really asking for is to have different member roles.

I think the UI could make a lot more sense with role-based permissions, similar to how GitHub/GitLab/Meetup/etc. do it. Then the open/closed/secret setting would only apply to group visibility/joinability, and the content permissions could be moved into customizable guest/participant/owner roles which you can assign to each user membership.

@matthewbartlett after playing around with Loomio a bit more I have a clearer idea of what my concerns are:

• at the moment we don't want any content available to anonymous users, this means Secret is a must
• at the same time we want all employees to be able to see and participate in all sub-groups, which means Secret doesn't work :)

I'd like to submit a PR to solve this somehow (or at least have a workaround for our own instance) and am trying to figure out what the easiest approach is. What do you think about changing the permission checks so members of the parent group are considered members of sub-groups as well? I think then I could set everything to Secret and it should work as expected.

Path of least resistance as far as I can tell would be to change the logic (in ability_service.coffee?) so that people who aren't logged in and visit a thread/group page are redirected to a sign in page, then making a closed group.

We're also imminently releasing a new plugin system (readme here) which would allow you to write up the new functionality (however you decide to do it) in a plugin and install it on your instance that way.

@jameskiesel that would solve my first concern but not the second (if I want to avoid adding all users to all sub-groups). Anyway, the plugin system looks very interesting and I added some feedback to the PR, thanks!

@richarddbartlett just linked me the group permissions design doc which was very helpful, so I'll leave it here for future reference.