<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=599750) </details> <!--IssueSummary end--> ## Problem GLQL passes usernames (e.g. `pshutsin`) when filtering by user, but the CodeSuggestions Aggregation Engine (AE) expects user GIDs or IDs. The `user_id` filter does not accept usernames, and accepting usernames directly is not supported out of the box because it would require a join to the `siphon_users` table. This mismatch means GLQL-driven queries that filter by user currently cannot work correctly with the CS AE. ## Proposed Solution Add a new `user_username` filter to the CodeSuggestions AE (`ee/app/models/analytics/aggregation_engines/code_suggestions.rb`) that: 1. Accepts one or more usernames as strings (e.g. `username: ["pshutsin"]`) 2. Performs a PostgreSQL lookup (`User.by_username(usernames).map(&:id)`) to convert usernames to IDs 3. Applies the resulting IDs as an `IN` clause on the `user_id` column — equivalent to the existing `user_id` filter This keeps the username → ID conversion in a single location (the AE builder) rather than requiring changes to both the GLQL API and the frontend `parser.js`. ### Filter Behaviour Both filters can be used independently or together, and they compose as `AND` conditions: ``` user_id: [1, 2, 3], user_username: ["pshutsin"] # => user_id IN (1, 2, 3) AND user_id IN (<pshutsin's id>) ``` ### Validation - `user_id` filter: strict integer/GID validation (existing behaviour, unchanged) - `user_username` filter: open string validation, with the PG lookup acting as the implicit guard (unknown usernames simply return no results) ## Implementation Notes - The username → ID lookup should use PostgreSQL (not ClickHouse), as it is faster and `siphon_users` may not be GA yet. - If a username does not resolve to a known user, the filter should return no results (consistent with filtering by a non-existent GID). - This is a pilot for username-based filtering. Once proven, similar `user_username` filters can be added to other AEs that have user dimensions. ## References - Related MR: !235220 (GLQL Typed transform path — where the username/ID mismatch was discovered) - Discussion context: username vs GID handling in GLQL ↔ AE integration