mirror of
https://github.com/openobserve/openobserve.git
synced 2026-11-04 00:08:55 +00:00
Omkar Kesarkhane
021d2135b5
## The bug Selecting checks in Synthetic Monitoring and pressing **Move** opened a dialog reading: ``` Current Folder: Foo Select Folder: Foo ``` The same folder name twice — which reads as "move this to where it already is". Nothing could actually go wrong: `primary-button-disabled` already blocked a same-folder submit. The dialog simply gave no clue *why* Move was greyed out, because the destination it had chosen for you was the one destination it would not accept. ## Cause `MoveAcrossFolders` seeded `selectedFolder` from `activeFolderId`, and `SelectFolderDropDown` listed every folder including that one. ## Fix - `SelectFolderDropDown` gains an optional `excludeFolderId` prop: it filters that folder out of the options and refuses to seed the selection with it. - `MoveAcrossFolders` passes `:excludeFolderId="activeFolderId"`, opens with no destination chosen, and additionally disables Move while the destination is empty — *"not the active folder"* is not the same as *"somewhere to move to"*. - The folder-list watcher now keeps a still-offerable choice. Creating a folder from the **+** button arrives here as a store list change, and the re-seed would otherwise clear the folder just created and selected. ## Why the prop is opt-in `SelectFolderDropDown` has six other consumers — ImportAlert, AlertList's clone dialog, CreateReport, AddSlo, SloList, and the synthetics *duplicate* dialog. Every one of those picks a folder to file something **into**, where opening on the active folder is correct. Unset, the filter matches every folder (`!== undefined`) and the seeding is untouched, so those call sites are byte-for-byte unchanged. ## Scope This dialog is shared, so the change reaches **alerts, pipelines, reports, SLOs and synthetics**. Behaviour is strictly narrowed: the option removed was already a guaranteed no-op behind the disabled-submit guard. `MoveDashboardToAnotherFolder` uses a separate `SelectFolderDropdown` under `components/dashboards/` and has the same behaviour, but it is a different component tree and is deliberately left alone. ## Tests 5 new cases on the dropdown (default offers everything, excluded id dropped, blank start, normal seeding still works, choice survives a list change) and 1 on the dialog. Three existing tests asserted the old seeding and are updated. **One deserves review:** `should compute primaryButtonDisabled=false when selectedFolder value is null` asserted that a *null* destination **enables** Move — executing that submits `dst_folder_id: null`. I read it as wrong rather than intentional and inverted it. If that null path is load-bearing somewhere I have not found, this is the thing to challenge. ## Verification Run on this branch, based on `main`: - `src/components/common/sidebar/` — 291 passed (6 files) - Consumers: SyntheticMonitoring, AlertList, ImportAlert, MoveDashboardToAnotherFolder — 216 passed, 10 pre-existing skips - `eslint` on all four changed files — clean - `npm run lint:design:strict` — OK, no regressions - `npm run type-check` — exit 0
web
This template should help get you started developing with Vue 3 in Vite.
Recommended IDE Setup
VSCode + Volar (and disable Vetur) + TypeScript Vue Plugin (Volar).
Type Support for .vue Imports in TS
TypeScript cannot handle type information for .vue imports by default, so we replace the tsc CLI with vue-tsc for type checking. In editors, we need TypeScript Vue Plugin (Volar) to make the TypeScript language service aware of .vue types.
If the standalone TypeScript plugin doesn't feel fast enough to you, Volar has also implemented a Take Over Mode that is more performant. You can enable it by the following steps:
- Disable the built-in TypeScript Extension
- Run
Extensions: Show Built-in Extensionsfrom VSCode's command palette - Find
TypeScript and JavaScript Language Features, right click and selectDisable (Workspace)
- Run
- Reload the VSCode window by running
Developer: Reload Windowfrom the command palette.
Customize configuration
See Vite Configuration Reference.
Project Setup
npm install
Compile and Hot-Reload for Development
For stand-alone UI development environment, create .env file and which contains below environment variable
VITE_OPENOBSERVE_ENDPOINT=http://localhost:5080/
npm run dev
Type-Check, Compile and Minify for Production
npm run build
Run Unit Tests with Vitest
npm run test:unit
Run End-to-End Tests with Cypress
npm run test:e2e:dev
This runs the end-to-end tests against the Vite development server. It is much faster than the production build.
But it's still recommended to test the production build with test:e2e before deploying (e.g. in CI environments):
npm run build
npm run test:e2e
Lint with ESLint
npm run lint