This feature made security settings way easier to implement for our developer and operations team :)

Super cool, can't wait to try it out :-)

I am shocked that this is not implemented yet.

What do you do when you run a micro-service architecture and you have a hundred different applications spread across multiple project teams and you need fine grained control?

Oh yeah you sit there like god damn idiot specifying each individual project to a team. Instead of the absolute bloody obvious - applying permissions to the entire group.

I am dissapoint. Very disappoint.

This would be incredible useful so that I could allow an area where developers could be have much more freedom to experiment without having to maintain 2 separate octopus environments. For the good ideas I could easily promote them to to other project groups once the idea is vetted out and agree upon between the developers and the devops teams.

Is there an update on this? (or should I look into the tenant thing for handling maintainable delegated project deployment) :-)

any update on this Vanessa Thanks

We have lots of webservices belonging to different teams, the webservices are set to one project each. This feature will make it more manageable to add and remove projects without having to resort to administrating projects in teams. Make it so.

This would be a great feature to have for large organisations, to have group administrators to manage their own projects

I would also agree that it would be very useful to be able to scope a group to specific projects or environments, but still allow them to create project or environments, respectively. Our use case for this is that we have our dev environments and our production environments, but we have two different groups who manage those environments. We can currently scope each of the groups to their respective sets of environments, but we would also like to allow each of these groups to be able to create new ones as well (and preferably, automatically add those new environments to the corresponding group's scope).

This would be a better option as I have ran into the issue that scoping a team to specific projects blocks the ability to create projects if it is set as a permission for their role. A more flexible approach to permissions would useful, like being able to scope a team to a project group rather than scoping specific projects to a team.

This would help a lot. We have four teams, working on different applications. I'm setting up an admin group, a contributor/deploy to test group and a deploy to production group for each team. It would help a lot if I only had to assign a project group for each security group than keep up and assign/delete projects whenever some module is added or deleted to an application.

We would love to be able to restrict permissions within a project group. We support multiple product groups and use the project group to separate out each product.

This would be a great addition

This feature will help large teams

That would be a great improvement for instances where multiple teams are using the same instance of Octopus with multiple project groups

I'd agree. Particularly as - on my reading - this is what the documentation (http://docs.octopusdeploy.com/display/OD/Project+Groups) says is the case already.

Now that retention policies and environments that can be deployed to are defined in lifecycles, managing user permissions seems to be the only function left to project groups.

Being able to do this would make managing users much more scalable.

Yes please. It would be great to add a Project Group to a Team rather than loads of Projects. Would also be maintainable as when a new project is added to a project group then the team will see it automatically

Maybe I missed it, but I would also like the project administrator have the ability to add users to that group, although maybe that is a separate permission "Team Owner"...

We really need this feature open up our OD installation to multiple projects.

We need a Project Administrator that can change anything within a single project
* Create and maintain Library Sets within the project
* Create new Environments for the project
The current administrator role has global permissions. In our case we have distinct projects with no relations in our company.
We would like both a global administrator company wide, but also a local administrator for each project in our company.

Very useful.. it's pretty annoying to have to add projects for folks and then add that project to their permission group. So much nicer to just give them permission on the group and let them do what they need as far as adding/removing/renaming projects there.