Handle teams that are deleted/renamed after `mdm.apple_bm_default_team` is set

[roperzh]

Problem

As described by @mna in https://github.com/fleetdm/fleet/issues/8733#issuecomment-1325353478, an user is able to set up a default team for DEP enrolled devices using the mdm.apple_bm_default_team config, and while we're doing validation when the config is set, nothing currently prevents the user from deleting/renaming the team without updating this config.

Currently after https://github.com/fleetdm/fleet/pull/9135, if we can't find a team we still add the host to Fleet, but we don't assign a default team to it.

Requirements

TODO: Define what's the expected behavior, should we validate that you're also updating mdm.apple_bm_default_team? should we automagically update mdm.apple_bm_default_team? (is it possible?)

cc: @noahtalerman @lukeheath

[mna]

@lukeheath @noahtalerman @roperzh

I think the following options are possible at roughly the same technical cost:

• Remove the default team from appconfig if that team is renamed/deleted (I believe this can only happen in the PATCH /teams/{id} and DELETE /teams/{id} endpoints as the apply team specs endpoint cannot delete nor rename a team).
• Update the appconfig to the new team name if that team is renamed (though this behaviour could be surprising if the goal of the user was explicitly to rename it and then create a team with the targeted name to replace the old one)

And of course the other option is do nothing and let the appconfig setting stay the same, with its behaviour being:

• if the team got renamed/deleted, new automatic enrollments are not assigned to any team
• if the team got deleted and a new one created with the target name, then new automatic enrollments will be assigned to that team (which a case can be made for it to be either surprising or exactly what the user expected)

[noahtalerman]

option is do nothing and let the appconfig setting stay the same, with its behaviour being...

@mna @roperzh I prefer this option. This is what I would expect as a user.

I think this means that, for now, we're intentionally not solving this rename/deleted problem. We might come back to this later.

What do yo think?

[noahtalerman]

I would also expect for Fleet to warn me when I'm renaming (or deleting) a team: "This team is used for automatic enrollment. After renaming (deleting) this team, all future macOS hosts will automatically enroll to no team."

That said, I think we can come back to solving this problem later.

[mna]

@noahtalerman doing nothing special makes sense to me. I agree with the warning, but as you say, this can be solved later (I think it could also be a frontend-only solution as the appconfig information is available there and the warning would make sense only in a UI context - that is, it would not make as much sense in an API call).

[roperzh]

agreed on all points, a note that we might still want to do it at the API level instead of doing it in the UI as you might change the team name via fleetctl too.

[mna]

@roperzh to be double-checked, but I don't think we can rename/delete teams with fleetctl apply (as the name is used to create or update an existing team).

[gillespi314]

And of course the other option is do nothing and let the appconfig setting stay the same, with its behaviour being:

if the team got renamed/deleted, new automatic enrollments are not assigned to any team

As a user, this is the opposite of what I would expect. My general intuition would be that renaming an entity such as a team is a neutral, non-destructive change and would not have side-effects on things like app settings. Although adding a warning as Noah suggests would mitigate this unexpected result, I would still find it frustrating as a user if renaming the team meant I had to take additional steps to restore the prior default behavior. So in terms of the best UX, I would prefer the first option Martin outlined over the second if they can be accomplished at the same relative level of effort.

[noahtalerman]

My general intuition would be that renaming an entity such as a team is a neutral, non-destructive change and would not have side-effects on things like app settings

I would still find it frustrating as a user if renaming the team meant I had to take additional steps to restore the prior default behavior.

@gillespi314, good points. I agree with both. On second thought, I think your intuition is closer to right than mine here: https://github.com/fleetdm/fleet/issues/9231#issuecomment-1377364736

That said, I think this scenario is an edge case that we can cut. If the default team is renamed/deleted, the hosts still enroll in Fleet assigned to no team. In this scenario IT admin is able to see this in the UI, transfer hosts to the correct team, and update the default team.

Great discussion. It will be helpful when coming back to this later.