Please confirm the following
Bug Summary
Six of the nine list endpoints used by the EDA role wizard filter name with lookup_expr="istartswith", while three use icontains, so substring search silently misses on most endpoints — and the ansible-ui toolbar presents the filter as a "contains" search:
| Endpoint |
name lookup |
| eda-credentials, projects, credential-types, decision-environments, event-streams |
istartswith |
| activations, rulebooks, activation-instances |
icontains |
| audit-rules |
no filterset_class at all |
(See src/aap_eda/api/filters/*.py.)
Clients also cannot work around this with ?name__icontains=: no FilterSet declares that lookup, and with no django-filter STRICTNESS configured the unknown param is silently ignored, returning the full unfiltered list.
Environment
AAP 2.7 on OpenShift (eda-server-operator), EDA API version 1.3.2. Behavior is defined in the FilterSet declarations, so it is deployment-independent (same in standalone builds).
Steps to reproduce
- On an instance with the default credential types loaded, call
GET /api/eda/v1/credential-types/?name=auth.
- Call
GET /api/eda/v1/credential-types/?name__icontains=basic.
Actual results
?name=auth returns 0 results, even though "OAuth2 Event Stream" and "OAuth2 JWT Event Stream" exist (prefix-only match).
?name__icontains=basic returns all 28 credential types (param silently ignored, no filtering).
Expected results
- A name search presented as "contains" in the UI should match substrings:
?name=auth should return the two OAuth2 types.
- Ideally an unsupported filter param should not silently return the full unfiltered collection.
Additional information
Suggested fix: change lookup_expr to icontains for the istartswith name filters (precedent already in-tree: ActivationFilter, RulebookFilter), and consider adding a filterset_class to AuditRuleViewSet. Backward-compatible: icontains matches are a strict superset of istartswith matches.
Refs: ansible/ansible-ui#3322 (where this was uncovered), ansible/django-ansible-base#1060 (related OPTIONS metadata regression found in the same investigation).
Please confirm the following
Bug Summary
Six of the nine list endpoints used by the EDA role wizard filter
namewithlookup_expr="istartswith", while three useicontains, so substring search silently misses on most endpoints — and the ansible-ui toolbar presents the filter as a "contains" search:namelookupistartswithicontainsfilterset_classat all(See
src/aap_eda/api/filters/*.py.)Clients also cannot work around this with
?name__icontains=: no FilterSet declares that lookup, and with no django-filter STRICTNESS configured the unknown param is silently ignored, returning the full unfiltered list.Environment
AAP 2.7 on OpenShift (eda-server-operator), EDA API version 1.3.2. Behavior is defined in the FilterSet declarations, so it is deployment-independent (same in standalone builds).
Steps to reproduce
GET /api/eda/v1/credential-types/?name=auth.GET /api/eda/v1/credential-types/?name__icontains=basic.Actual results
?name=authreturns 0 results, even though "OAuth2 Event Stream" and "OAuth2 JWT Event Stream" exist (prefix-only match).?name__icontains=basicreturns all 28 credential types (param silently ignored, no filtering).Expected results
?name=authshould return the two OAuth2 types.Additional information
Suggested fix: change
lookup_exprtoicontainsfor theistartswithname filters (precedent already in-tree:ActivationFilter,RulebookFilter), and consider adding afilterset_classtoAuditRuleViewSet. Backward-compatible:icontainsmatches are a strict superset ofistartswithmatches.Refs: ansible/ansible-ui#3322 (where this was uncovered), ansible/django-ansible-base#1060 (related OPTIONS metadata regression found in the same investigation).