Default team for new apps

[bootstraponline]

• You have set up teams inside your organization.
• You add a new app to the organization plan.
• Once the app was added the team can see it, but not all of them are included, so you have to go to the team tab and add the team members there.

To solve the issue, you would need to setup a default team group, so they will be copied to the newly created app.

(credit to @birmacher for writing the feature description)

[viktorbenei]

Great idea and thank you for the #feature-request @bootstraponline!

We did consider this option initially, but were worried that this might lead to accidental access to apps you don’t intend to grant access to. Of course, if this request gets enough votes and we can gather enough feedback to formalize how this could be implemented in a “safe” way (-> no accidental access) we’re open to do it.

A workaround/note in the meantime, which might help in some cases: you can assign groups to apps from the Organization’s page too, not just on the app’s Team tab.

1. Open the Organization’s page, e.g. from Account settings
2. Go to the Groups tab
3. On the related Group’s header click the [...] button to get the “more options” menu
   
4. Select Assign group to apps
5. In the popup you can see and manage the access level of the given group on every app of the Organization.
   
   

[bootstraponline]

@viktorbenei

We did consider this option initially, but were worried that this might lead to accidental access to apps you don’t intend to grant access to.

In my experience, there’s a mobile team and they need access to all apps. That’s how it works on other services for example.

With a large team, there’s a growing collection of these invisible apps. It’s not obvious how to solve the issue other than manually auditing all the apps to ensure the permissions are configured correctly.

If someone is opting into the default assign to existing team behavior, then I don’t think the issue of “accidental access” is real.

[viktorbenei]

@bootstraponline

In my experience, there’s a mobile team and they need access to all apps.

Well, we have quite a few separate teams for example, where this would not apply

@bootstraponline

If someone is opting into the default assign to existing team behavior, then I don’t think the issue of “accidental access” is real.

I do agree with this, although this would not solve the issue completely, e.g. in our case we could not use this without creating separate organizations for separate teams / “departments”.

[viktorbenei]

Don’t get me wrong, I don’t disagree with you, I’m just saying that the solution outlined here will only work for some teams/orgs, and not for others.

[bootstraponline]

@viktorbenei

I’m just saying that the solution outlined here will only work for some teams/orgs, and not for others.

I agree.

I just think it’d be a more common case that if you trust your development team then the use case of granting them access to all the apps should be supported. Maybe I’m wrong and it’s more common to block devs from apps.

[viktorbenei]

I’d say both are common.

One more related idea, in addition to a “default assignment” like you described: a single button/option to assign a specific group to all apps with the specified role. Similar to the Default team for new apps one, but instead of clicking through the list one by one this button would “Assign the Alpha team to all apps as admin”.

WDYT?

[viktorbenei]

@bootstraponline

if you trust your development team

In our case it’s more about distraction / responsibilities and control over notifications, not about trust. E.g. our web dev team would be annoyed to hell if they’d get a notification about every failed build related to the CLI or tools

[bootstraponline]

@viktorbenei

“Assign the Alpha team to all apps as admin”.

WDYT?

I like it.

Still doesn’t solve the issue of apps being hidden by default but at least there’s an easy solution with a single button click.

[bootstraponline]

@viktorbenei

E.g. our web dev team would be annoyed to hell if they’d get a notification about every failed build related to the CLI or tools

For what it’s worth, we have a similar issue and that’s solved by gmail filters. I know on GitHub people can individually opt out on a per repo basis of notifications. Maybe a more robust notification model would make sense.

[viktorbenei]

Sure, it’s not a “we should either do this or that” decision, these features could co-exist, letting teams/orgs decise how they want to organize

[viktorbenei]

Yeah… But that’s a topic for a separate #feature-request

[novemberfive_ops]

Any plans of giving us the option?

All our apps are created via the api. And the only thing that is manual work is adding groups to the app.
Default groups would be awesome or an option to add groups via API? Would really help our automation process.

Gr.

Seppe

[thi.nguyen]

At the moment, manually adding is the only option.

Thank you for reaching out,

Thi