Draft: Hide chat web search unless the group allows it
What does this MR do and why?
Duo Chat's prompt input has a "+" menu with a web search toggle. Until now that menu appeared whenever the dap_web_search feature flag was on, with no check on whether the user's top-level group had actually turned web search on. This merge request makes the menu also require the group setting, using the setting added earlier in this stack.
This is the third merge request in a three merge request stack:
- Backend, the group setting itself: !253643 (merged)
- Frontend, the group settings checkbox: !253620
- This merge request, honoring the setting in the chat UI.
The two above must merge first. This branch targets the second merge request's branch, 604068-group-duo-web-search-toggle.
How it works
DuoChatPanel::ChatComponentalready emits the chat scope as data attributes. It now also emitsweb_search_enabled, read from the container's root ancestor namespace.parseChatPanelConfigparses that attribute. It is renamed towebSearchAllowedForGroupat that boundary on purpose, because the chat already useswebSearchEnabledfor the separate per-conversation opt-in, and the two must not be confused.initDuoPanelprovides the value once, andprompt_input_actions.vueinjects it. Providing rather than threading a prop matters because that component is rendered from three places: the main state manager, the light state manager, and the blocked state view. A prop would have to be plumbed through all three.- The inject defaults to
false, so a mount that does not provide the value hides the control rather than granting a capability no group opted into.
Design decisions
This fails closed when there is no root namespace. Duo Chat can run outside any group, for example in a personal namespace context. There is no group there to grant the capability, so the control is hidden rather than falling back to the feature flag alone. This matches the epic's stated behavior, that Duo Chat makes no external search requests when a group has not enabled web search. Please push back if you would prefer it to fall open in ungoverned contexts.
This gates the UI only, not the API. The workflow create mutation and the web search update mutation still check only the feature flag against the user, so a caller could still enable web search for a conversation through GraphQL even when the group has it switched off. Closing that gap is a separate change and is not part of this stack. This merge request should not be described as enforcement.
Screenshots or screen recordings
Not applicable. This adds a conditional gate to an existing control. There is no visual change when the group setting is on.
How to set up and validate locally
- Check out this branch, which contains the whole stack.
- Run
bin/rails db:migrateso the new column exists. - Enable the
dap_web_searchfeature flag. - As a user in a top-level group whose web search setting is off, open Duo Chat and confirm the "+" menu no longer offers web search.
- Turn the group setting on and confirm the toggle reappears.
- Open Duo Chat outside any group context and confirm it stays hidden.
Testing done
- The chat control's spec covers the full gate as a table: both the flag and the group grant on renders the menu, either one off hides it, and a mount that provides nothing at all hides it.
- The config parser and the panel initializer each cover the true, false, and absent cases of the data attribute.
- The Rails component spec covers the default, the group having allowed it, and the no-root-namespace case.
- 604 Jest tests across 9 related suites pass under both Vue 2 and Vue 3. 110 examples in the Rails component spec pass. ESLint, Prettier, and Rubocop are clean.
- No changelog entry, because
dap_web_searchis an experiment feature flag that is off by default.
References
- Per-conversation chat toggle issue: #587232 (closed)
- Group setting backend issue: #587234
- Group setting frontend issue: #604068
- Epic: &20480
Video recording