role_team_assignment module regression: entity_type resolution change breaks non-Organization/Team role definitions in 2.6.20260306

[djdanielsson]

Bug Summary

The role_team_assignment module in ansible.platform 2.6.20260306 introduced a breaking change in how entity_type is resolved, causing failures for role definitions whose names don't start with "Team" or "Organization" (e.g.
"Launch User Role - Projects"). The same playbook works correctly with ansible.platform 2.6.20251106.

Component

• Other (Ansible module: plugins/modules/role_team_assignment.py)

Ansible, Collection, and Platform Details

  ansible [core 2.18.15]
  ansible.platform 2.6.20260306 (broken)
  ansible.platform 2.6.20251106 (working)
  Ansible Automation Platform 2.6
  Automation Controller 4.7.9

Steps to Reproduce

  - name: Assign Roles To Teams
    ansible.platform.role_team_assignment:
      assignment_objects:
        - name: "My Organization - Development"
          type: organizations
      role_definition: "Launch User Role - Projects"
      team: "Launch Development"
      state: present

Expected Behavior

The role assignment completes successfully (as it does with ansible.platform 2.6.20251106).

Actual Behavior

  fatal: [localhost]: FAILED! => {
    "msg": "{'object_id': 'Project matching query does not exist.'}"
  }

Root Cause Analysis

The breaking change is in plugins/modules/role_team_assignment.py, in the main() function's entity_type resolution logic.

Version 2.6.20251106 (working):

  role_map = {
      'Team': 'teams',
      'Organization': 'organizations',
  }
  entity_type = next((
      mapped
      for prefix, mapped in role_map.items()
      if role_definition_str.startswith(prefix)
  ), None)

This derived entity_type from a prefix match on the role definition name string. For "Launch User Role - Projects", neither "Team" nor "Organization" matched, so entity_type was None. The subsequent elif entity_type and
object_param: branch was skipped, and the module proceeded to module.exit_json(...) without error.

Version 2.6.20260306 (broken):

entity_type = role_definition.get('content_type')

This reads content_type directly from the API response for the role definition. For "Launch User Role - Projects", the API returns a non-None content_type value (likely "project" or similar). This causes the module to enter the
elif entity_type and object_param: loop, where it attempts to resolve each assignment_objects entry. The user's assignment_objects contains type: organizations, but the module now tries to resolve the object in the context of the
role definition's content_type — which doesn't match — resulting in "Project matching query does not exist.".

The exact diff (compare link (2.6.20251106...2.6.20260306)):

  @@ -237,16 +237,7 @@ def main():
       if team_ansible_id is not None:
           kwargs['team_ansible_id'] = team_ansible_id
  -    role_map = {
  -        'Team': 'teams',
  -        'Organization': 'organizations',
  -    }
  -
  -    entity_type = next((
  -        mapped
  -        for prefix, mapped in role_map.items()
  -        if role_definition_str.startswith(prefix)
  -    ), None)
  +    entity_type = role_definition.get('content_type')
       object_param = assignment_objects
       results = []

Impact

Any role definition whose name does not start with "Team" or "Organization" (which previously resulted in a harmless None entity_type) now gets a non-None content_type from the API, causing the module to enter a code path that
fails to resolve assignment_objects correctly. This affects all users of role_team_assignment (and likely role_user_assignment if it has the same pattern) who use role definitions like:

• "Launch User Role - Projects"
• "Launch Admin Role - Projects"
• Any custom or built-in role definition not prefixed with "Team" or "Organization"

Suggested Fix

The new content_type-based approach is architecturally better than prefix matching on role name strings, but the downstream logic in the elif entity_type and object_param: branch needs to correctly handle the content_type value.
Specifically, when assignment_objects entries include an explicit type field (e.g. type: organizations), the module should use that type for object resolution rather than deriving it from the role definition's content_type.

Workaround

Pin ansible.platform to version 2.6.20251106:

ansible-galaxy collection install ansible.platform:==2.6.20251106

Cross-reference

Originally reported as redhat-cop/infra.aap_configuration#1334 (redhat-cop/infra.aap_configuration#1334)