Repository navigation
role_definitions OPTIONS no longer exposes content_type choices since AAP-48392 (SlugRelatedField invisible to DRF metadata) #1060
Description
Bug Summary
Since commit 894af11 (AAP-48392 Models and APIs for tracking remote permissions in DAB RBAC, #749), RoleDefinitionSerializer.content_type changed from ContentTypeField(ChoiceLikeMixin) (a ChoiceField subclass) to serializers.SlugRelatedField(slug_field='api_slug', ...).
DRF's SimpleMetadata.get_field_info explicitly excludes RelatedField/ManyRelatedField from choices rendering, so OPTIONS /role_definitions/ went from returning:
"content_type": {"choices": [{"value": "eda.project", "display_name": "Project"}, ...]}to:
"content_type": {"type": "field", "label": "Content type"}Verified on a live AAP 2.7 install (EDA 1.3.2, eda-server pinning django-ansible-base @ devel, DRF 3.15): no choices key present in either GET or POST actions of the OPTIONS response.
Impact
Any client that populates a resource-type selector from OPTIONS choices silently breaks. Concretely, the standalone EDA UI role wizard (EdaSelectResourceTypeStep in ansible-ui) renders an empty "Resource type" dropdown — reported in ansible/ansible-ui#3322 and originally observed in ansible/ansible-ui#3122.
Suggested fixes (either)
- Restore choices for this field in metadata — e.g. a metadata hook, or a
ChoiceLikeMixin-style field that keeps theapi_slugvalidation but still exposeschoicesfrompermission_registry/DABContentType. - Declare
GET /role_metadata/the supported discovery endpoint for content types and document the OPTIONS behavior change as intentional, so clients migrate.
Additional information
Timeline that led to confusion downstream: UIs written before July 2025 parse {value, display_name} objects (standard DRF ChoiceField metadata rendering) and worked; after 894af11 the choices disappear entirely, which looks like a UI parsing bug but is a serializer/metadata regression here.
Activity