@saooti/octopus-sdk 41.12.1-beta2 → 41.12.1

package/.claude/settings.local.json

@@ -11,7 +11,15 @@
       "Bash(npm:*)",
       "Bash(npx vitest:*)",
       "Bash(./node_modules/.bin/vitest run:*)",
-      "Bash(npx eslint:*)"
+      "Bash(npx eslint:*)",
+      "Bash(node -e \"console.log\\(require.resolve\\('./package.json'\\)\\)\")",
+      "Bash(node --experimental-vm-modules -e ' *)",
+      "Bash(node -e ' *)",
+      "Read(//home/julien/Workspace/frontoffice/code/frontend/**)",
+      "Read(//home/julien/Workspace/frontoffice/**)",
+      "Bash(git rm *)",
+      "Bash(grep -vE '\\\\-[A-Za-z0-9_-]{8}\\\\.mjs$')",
+      "Bash(grep -E '\\\\-[A-Za-z0-9_-]{8}\\\\.mjs$')"
     ]
   }
 }

package/CHANGELOG.md

@@ -1,21 +1,10 @@
 # CHANGELOG
 
-## 41.12.1 (En cours)
+## 41.12.1 (19/08/2026)
 
-**Features**
-
-- Ajout de nouvelles fonctions dans l'api `rubriqueApi`
-- Option de `AdvancedSearch` pour ne pas afficher le filtre de groupe
-- Ajout callback sur fermeture de notifications
-
-**Fixes**
-
-- Correction d'une anomalie de chargement du style de la modale utilisée par
-  `ClassicNotifications`
-
-**Misc**
+### Fixes
 
-- Suppression de la marge entre le titre et le contenu pour `PresentationLayout`
+- Gestion des erreurs dans downloadHelper
 
 ## 41.12.0 (13/07/2026)
 

package/PLAN-fix-dist-bare-imports.md

@@ -0,0 +1,122 @@
+# Plan: fix octopus-sdk's dist output for plain `npm install` consumers
+
+## Background
+
+Consumer apps (frontoffice, podcastmaker) currently only pass their test
+suites against `@saooti/octopus-sdk` when it is `npm link`ed to this repo.
+A plain `npm install` of the published package breaks Vitest in those repos
+with:
+
+- `TypeError: Unknown file extension ".vue"` for
+  `vue-material-design-icons/*.vue`
+- `Error: Cannot find module '.../dayjs/locale/de' ... Did you mean
+  "dayjs/locale/de.js"?`
+
+Vitest externalizes normal `node_modules` packages by default and lets
+Node's native ESM resolver load them directly. That resolver can't handle a
+raw `.vue` specifier, and — since `dayjs` ships no `"exports"` map — it
+requires exact file names for subpath imports. This only "worked" when the
+SDK was npm-linked because a linked package resolves outside `node_modules`
+and dodges Vitest's externalization heuristic, letting Vite's own resolver
+(which is lenient about extensions and knows `.vue`) handle it instead. That
+was incidental, not a real fix, and consumer repos currently paper over it
+with a `test.server.deps.inline` entry in their `vitest.config.js`.
+
+Root cause is in this repo's `vite.config.js` build config, not in the
+consumer apps.
+
+## Root causes
+
+1. **`vue-material-design-icons` externalized wholesale.** The `external`
+   callback in `vite.config.js` externalizes every bare (non-relative,
+   non-`@/`) import indiscriminately. `vue-material-design-icons` ships raw
+   `.vue` SFCs rather than pre-compiled JS, so externalizing it re-emits
+   `import X from "vue-material-design-icons/ChevronDown.vue"` verbatim into
+   `dist/*.mjs`. Confirmed via:
+   ```sh
+   grep -rhoE 'from "[^".][^"]*\.vue"' dist/*.mjs | sort -u
+   ```
+   → 58 distinct `vue-material-design-icons/*.vue` specifiers across the
+   dist chunks.
+
+2. **`dayjs/locale/*` imported without an extension.**
+   `src/components/composable/useDayjs.ts` has:
+   ```ts
+   import "dayjs/locale/de";
+   import "dayjs/locale/es";
+   import "dayjs/locale/fr";
+   import "dayjs/locale/it";
+   import "dayjs/locale/sl";
+   ```
+   `dayjs` has no `"exports"` map in its `package.json`, so Node's strict ESM
+   resolver needs the exact file name.
+
+Swept the rest of `dist/*.mjs` for other bare/extensionless external
+specifiers (`grep -rhoE 'from "[^".][^"]*"' *.mjs`, filtered against the
+known peer/runtime deps) — nothing else came back. `qrcode.vue` is a real
+package name (its own `package.json` resolves it), not a raw SFC path, so
+it's fine as-is. No other externalized package (`video.js`, `vue-select`,
+etc.) needs bundling.
+
+## Steps
+
+### 1. Bundle `vue-material-design-icons` instead of externalizing it
+
+In `vite.config.js`, change the `external` callback:
+
+```js
+external: (id) =>
+    !id.startsWith('vue-material-design-icons') &&
+    !id.startsWith('.') && !id.startsWith('@/') && !id.startsWith('@tests/') && !path.isAbsolute(id)
+```
+
+The `vue()` plugin is already part of the build pipeline, so Rollup will
+compile these icon SFCs into plain JS as part of the bundle — no raw `.vue`
+specifier will remain in `dist`. Icons are tiny SVG wrappers, so this is a
+negligible size cost spread across existing chunks.
+
+### 2. Fully-specify the dayjs locale imports
+
+In `src/components/composable/useDayjs.ts`, add `.js` to all five locale
+imports:
+
+```ts
+import "dayjs/locale/de.js";
+import "dayjs/locale/es.js";
+import "dayjs/locale/fr.js";
+import "dayjs/locale/it.js";
+import "dayjs/locale/sl.js";
+```
+
+`dayjs` stays a peer dependency (correct — consumer apps must own a single
+dayjs instance); only the specifier changes.
+
+### 3. Verify
+
+- Full rebuild (`npm run build`) and re-run the `grep -rhoE 'from
+  "[^".][^"]*"' *.mjs` sweep over `dist/` — should come back clean of raw
+  `.vue` and extensionless subpath imports.
+- In `frontoffice/code/frontend`: remove the `@saooti/octopus-sdk` symlink,
+  do a plain `npm install @saooti/octopus-sdk@<new version>`, remove the
+  `test.server.deps.inline` entry from `vitest.config.js`, and run the full
+  test suite — should still be green.
+- Repeat the same unlink/reinstall/remove-inline/test check in
+  `podcastmaker`, since it depends on the same SDK and would hit (or has
+  hit) the identical failure.
+
+### 4. Cleanup once verified
+
+- Remove the `test.server.deps.inline: ['@saooti/octopus-sdk',
+  'vue-material-design-icons']` block from `frontend/vitest.config.js` (and
+  podcastmaker's equivalent, if it was ever added there).
+- Leave the existing dev-mode `optimizeDeps.exclude` / `server.fs.allow`
+  npm-link accommodations in the consumer apps' `vite.config.js` alone —
+  those are about local-dev HMR ergonomics when linked, unrelated to this
+  test-time module resolution bug.
+
+## Expected outcome
+
+Once `dist/*.mjs` contains only specifiers Node's native ESM resolver can
+load unassisted, Vitest's default externalization of `node_modules`
+packages works correctly for a plain `npm install` of `@saooti/octopus-sdk`
+— no `deps.inline` workaround needed in any consumer app.

package/PLAN_test_utils_single_entry.md

@@ -0,0 +1,194 @@
+# Plan: single bundled entry point for octopus-sdk test utilities
+
+## Context
+
+octopus-sdk is consumed by frontoffice (and potentially podcastmaker) via
+`npm link`. Frontoffice's Vite/Vitest and octopus-sdk's own Vite config both
+define a global `@` alias pointing at their *own* `src/`. Because linked
+packages are transformed from raw source (not the built `dist/`), any
+octopus-sdk source file that imports something via `@/...` gets that alias
+resolved against **frontoffice's** `src/` when transformed inside frontoffice's
+Vite instance — wrong target, resolution failure.
+
+This was already fixed for octopus-sdk's main bundle: `vite.config.js` builds
+`index.ts` to `dist/index.mjs` with `@/...` imports resolved and inlined at
+SDK build time (see `rollupOptions.external`), so consumers importing
+`@saooti/octopus-sdk` never hit raw source needing alias resolution.
+
+The gap: octopus-sdk's **test utilities** (`tests/utils.ts`,
+`tests/mocks/*.ts`) are exported via `package.json`'s
+`"./tests/*": "./tests/*"`, which passes through raw `.ts` source
+unconditionally. Frontoffice's `tests/utils.ts` and ~70 spec files import
+these paths directly, so they hit the same alias collision whenever the
+SDK source touches `@/...` (e.g. `AuthStore.ts` now imports
+`rubriquesApi` from `@/api`, which is a *transitive* import from
+`tests/utils.ts` importing `useAuthStore`).
+
+## Decision
+
+Bundle the test utilities into **one** built entry point, `dist/tests.mjs`,
+built the same way as the main `index.mjs` (aliases resolved at SDK build
+time). Consumers import everything from one path:
+`@saooti/octopus-sdk/tests`.
+
+This is *not* just a mechanical repackaging: the current `tests/mocks/i18n.ts`
+and `tests/mocks/useRouter.ts` work by **side effect** — importing the file
+calls `vi.mock(...)` at module-evaluation time. That only works because ES
+module imports are evaluated in source order relative to other imports in the
+importing file, and each of these mock files is imported as the very first
+line of ~70 spec files. If those files were merged into one shared module
+naively, importing that module would force *both* mocks (vue-i18n AND
+vue-router) onto every spec file that imports it — a real behavior change for
+specs that don't want vue-router mocked, and a correctness risk for anything
+that relies on the real router.
+
+**Fix: turn the mock modules into plain factory functions with no import-time
+side effects, and have each spec file call `vi.mock()` explicitly, referencing
+the imported factory.** This is Vitest's own documented supported pattern:
+`vi.mock()` calls are hoisted above imports by Vitest's transform, and a
+factory argument may reference an imported identifier as long as that
+identifier's name is prefixed `mock` (Vitest hoists that specific import
+alongside the `vi.mock` call). Concretely:
+
+```ts
+// before (side effect, implicit)
+import '@saooti/octopus-sdk/tests/mocks/i18n';
+
+// after (explicit, still correctly hoisted)
+import { mockI18n } from '@saooti/octopus-sdk/tests';
+vi.mock('vue-i18n', mockI18n);
+```
+
+This keeps mocking fully selective per spec file, fixes the alias-collision
+bug at the root (SDK build resolves its own aliases), and gives a single,
+low-maintenance entry point rather than a hand-maintained list of build
+entries per mock file.
+
+## Steps
+
+### 1. octopus-sdk: convert mock modules to factories
+
+- `tests/mocks/i18n.ts`: change from a `vi.mock(...)` side-effect call to
+  `export function mockI18n() { return { useI18n: () => ({...}), createI18n: () => {} }; }`
+  (same object literal as today, just returned instead of passed inline).
+- `tests/mocks/useRouter.ts`: same transform →
+  `export function mockUseRouter() { return { useRoute: () => ({...}), useRouter: () => ({...}) }; }`.
+- `tests/mocks/useAdvancedParamInit.ts`: same transform →
+  `export function mockAdvancedParamInit() { return { useAdvancedParamInit: () => ({...}) }; }`.
+  Note this one mocks an SDK-internal path (`@/components/composable/route/useAdvancedParamInit`),
+  not a third-party package — keep that target path as-is, only the
+  side-effect-to-factory conversion changes.
+- `tests/mocks/rights.ts` (`mockEmission`, `mockPodcast`): no behavior change
+  needed, already plain functions — just gets folded into the same bundle.
+
+### 2. octopus-sdk: single entry point
+
+- Create `tests/index.ts` that re-exports everything currently split across
+  `tests/utils.ts` and `tests/mocks/*.ts`: `mount`, `VueWrapper`,
+  `localisation`, `setupAuthStore`, `setupPlayerStore`, `combineStoreSetups`,
+  `setupPinia`, `mockI18n`, `mockUseRouter`, `mockAdvancedParamInit`,
+  `mockEmission`, `mockPodcast`.
+  (Either keep `tests/utils.ts` as the implementation file and have
+  `tests/index.ts` just re-export, or merge directly — whichever keeps the
+  smaller diff.)
+- `vite.config.js`: change `build.lib.entry` from a single string to an
+  object with two entries:
+  ```js
+  entry: {
+    index: path.resolve(__dirname, 'index.ts'),
+    tests: path.resolve(__dirname, 'tests/index.ts'),
+  },
+  fileName: (_format, entryName) => `${entryName}.mjs`,
+  ```
+  Keep the existing `resolve.alias` (`@`, `@tests`, `vue`, `hls.js`) — the
+  `@tests` alias already needs to exist here (not just in `vitest.config.js`)
+  since `tests/mocks/i18n.ts` references `@tests/utils` internally; this was
+  already added to `vite.config.js` in a prior WIP pass on this branch — verify
+  it's still there, add it if not, and drop the now-redundant duplicate alias
+  from `vitest.config.js`.
+- `cleanStaleChunks()` (in `vite.config.js`) currently only scans the top level
+  of `dist/`. With `tests: '...'` as an entry name (no `/` in it, unlike the
+  earlier multi-entry draft), output stays flat as `dist/tests.mjs` — no
+  recursive scanning needed. Confirm this after building; only revisit if the
+  entry name changes to something with a path segment.
+- `package.json` `exports`: replace `"./tests/*": "./tests/*"` with
+  ```json
+  "./tests": {
+    "types": "./tests/index.ts",
+    "default": "./dist/tests.mjs"
+  }
+  ```
+  (`types` points at raw `.ts` source, same as today's behavior — no need for
+  `unplugin-dts` to cover this entry.)
+
+### 3. octopus-sdk: migrate its own internal specs (36 files)
+
+octopus-sdk's own test suite imports `tests/mocks/i18n`, `tests/mocks/useRouter`,
+`tests/mocks/useAdvancedParamInit` directly too (`grep -rl "mocks/i18n\|mocks/useRouter\|mocks/useAdvancedParamInit\|mocks/rights" tests --include="*.spec.ts"` → 36 files as of this writing). Each needs the same
+mechanical rewrite as frontoffice (step 4). Since these are same-repo,
+relative imports (e.g. `from '../mocks/i18n'` or `@tests/mocks/i18n`) — adjust
+the codemod pattern accordingly, or just import from the new `@tests` (i.e.
+`tests/index.ts`) alias directly.
+
+### 4. frontoffice: migrate consumer imports
+
+- `tests/utils.ts`: change
+  ```ts
+  export { mount, VueWrapper } from '@saooti/octopus-sdk/tests/utils';
+  export { setupAuthStore, combineStoreSetups, setupPinia } from '@saooti/octopus-sdk/tests/utils';
+  ```
+  to import from `'@saooti/octopus-sdk/tests'` instead, and additionally
+  re-export `mockI18n`, `mockUseRouter` (and `mockAdvancedParamInit`,
+  `mockEmission`, `mockPodcast` if useful) so spec files can keep pulling
+  everything from the local `@tests/utils` alias as they do today.
+- Mechanical codemod across spec files (66 files for i18n, 6 for useRouter —
+  counts as of this writing, re-run the greps below to confirm current
+  numbers):
+  ```
+  grep -rl "octopus-sdk/tests/mocks/i18n" tests
+  grep -rl "octopus-sdk/tests/mocks/useRouter" tests
+  ```
+  Replace:
+  ```ts
+  import '@saooti/octopus-sdk/tests/mocks/i18n';
+  ```
+  with:
+  ```ts
+  import { mockI18n } from '@tests/utils';
+  vi.mock('vue-i18n', mockI18n);
+  ```
+  (needs `import { vi } from 'vitest';` present — most spec files already
+  import `vi` for other reasons; add it where missing.)
+  Same pattern for `useRouter`:
+  ```ts
+  import { mockUseRouter } from '@tests/utils';
+  vi.mock('vue-router', mockUseRouter);
+  ```
+  This is regular enough to script with a small codemod (sed/ts-morph) rather
+  than hand-editing 70+ files — verify the mechanical replacement still lets
+  each file pass its own tests, since ordering (mock call before other
+  imports that transitively pull in `vue-i18n`/`vue-router`) still matters:
+  place these two lines where the old side-effect import used to be
+  (typically line 1) to preserve the same evaluation order.
+
+### 5. Verify
+
+- `cd octopus-sdk && npm run build` — confirm `dist/tests.mjs` is produced and
+  `dist/index.mjs` still builds correctly.
+- `cd octopus-sdk && npx vitest run` — full SDK suite green after step 3.
+- `cd frontoffice/code/frontend && npx vitest run` — full frontend suite green
+  after step 4. Pay particular attention to any spec that relies on **real**
+  `vue-router` behavior today (i.e. does *not* currently import the
+  `useRouter` mock) — confirm the codemod didn't accidentally add a
+  `vi.mock('vue-router', ...)` call to those.
+- Run `npm run lint` on all touched files in both repos (touched files only,
+  no `--fix`-then-commit sweep, per project convention).
+
+### Out of scope
+
+- `"./src/*"` export mapping (raw source passthrough) is untouched — it's
+  used extensively by non-test app code in frontoffice (`main.ts`, `router.ts`,
+  several components) and is a separate, larger concern than test utilities.
+- podcastmaker: searched at plan-writing time, found no references to
+  `octopus-sdk/tests/*` — re-check before assuming it's unaffected, in case
+  that changes before this plan is implemented.

package/TO_SLOT.md

@@ -0,0 +1,43 @@
+# Stub components converted to scoped slots
+
+The SDK used to ship several "stub" components — empty `<div />` placeholders —
+that were overridden by the real frontoffice implementation at build time via
+an implicit Vite alias trick. That trick breaks once the SDK is pre-built as a
+library (see `~/Documents/FIX_BUILD_SDK.md`), so each usage was moved to an
+explicit scoped-slot API instead (or, for two deeply-nested cases, to runtime
+global component resolution — see below). All identified stubs are now
+converted; the stub `.vue` files themselves have been deleted since nothing in
+the SDK references them by import anymore.
+
+- `EditBox.vue` (deleted)
+  - `EmissionPage.vue` — **Done** (`#edit-box` slot)
+  - `ParticipantPage.vue` — **Done** (`#edit-box` slot)
+  - `PlaylistPage.vue` — **Done** (`#edit-box` slot)
+  - `PodcastModuleBox.vue` — **Done** (`#edit-box` slot, passed through `PodcastPage.vue`)
+- `EditBoxRadio.vue` (deleted)
+  - `RadioPage.vue` — **Done** (`#edit-box-radio` slot)
+- `RecordingItemButton.vue` (deleted)
+  - `PodcastModuleBox.vue` — **Done** (`#recording-item-button` slot, passed through `PodcastPage.vue`)
+- `RssSection.vue` (deleted) / `CommentMoreActionsAdmin.vue` (deleted)
+  - `ClipboardModal.vue`, `CommentMoreActions.vue` — **Done**, but via a different mechanism than the rest of this list. Both stubs are reached through multiple, and in the comments case recursive, layers of intermediate components (`ClipboardModal` is reached from 5 independent top-level pages via `ShareAnonymous`; `CommentMoreActions` is 4 layers deep under `CommentSection`/`CommentList`/`CommentItem`, which are self-recursive for comment replies). Threading scoped slots through every layer/entry point wasn't practical here, so instead the SDK leaves the bare `<RssSection>`/`<CommentMoreActionsAdmin>` tags unimported in `ClipboardModal.vue`/`CommentMoreActions.vue` and lets Vue resolve them at runtime against the consuming app's global component registry. The consuming app registers the real implementations once via `app.component("RssSection", ...)` / `app.component("CommentMoreActionsAdmin", ...)` (see frontoffice's `main.ts`). Apps that don't register them simply render nothing there (a dev-only console warning, stripped in prod).
+
+## Non-stub `@/`-alias collisions fixed via provide/inject
+
+A follow-up audit found the same `@/`-alias collision affecting real (non-stub)
+SDK code, not just placeholder components: SDK source importing a path via
+`@/...` that happens to collide with an unrelated frontoffice file at the same
+relative path, where the SDK genuinely depended on frontoffice's version to
+work correctly. Unlike the component stubs, these aren't extension points by
+design, and duplicating frontoffice's logic into the SDK isn't appropriate
+(the real implementation is either backend-contract-specific or pulls in
+frontoffice-only data), so both were fixed with Vue's `provide`/`inject`
+instead: the SDK exposes an injection key with a safe default (its own
+implementation), and frontoffice provides its richer implementation once at
+the app root (`app.provide(...)` in `main.ts`, alongside the `app.component()`
+calls above). Keys are defined in `src/components/composable/keys.ts` and
+re-exported from the root `index.ts`.
+
+- `api/initialize.ts` (`checkToken`)
+  - `RecaptchaModal.vue` — **Done**. SDK's own `api/initialize.ts` never defined `checkToken` (only frontoffice's override did), yet `RecaptchaModal.vue` called it — a live bug in waiting. Now resolved via `inject(CHECK_TOKEN_KEY, async () => true)`; the SDK no longer imports `@/api/initialize` at all. `sendMail` (frontoffice-only, unused by the SDK) was left untouched.
+- `i18n.ts` (`loadLocaleMessages`)
+  - `FooterSection.vue` — **Done**. Frontoffice's `loadLocaleMessages` merges ~13 frontoffice-only locale bundles into the message set; SDK's own version only loads its base translations, and `setLocaleMessage` replaces rather than merges — so an un-aliased SDK call would have wiped most of the app's translated UI text on every language switch. Now resolved via `inject(LOAD_LOCALE_MESSAGES_KEY, loadSdkLocaleMessages)`, defaulting to the SDK's own loader.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@saooti/octopus-sdk",
-  "version": "41.12.1-beta2",
+  "version": "41.12.1",
   "private": false,
   "description": "Javascript SDK for using octopus",
   "author": "Saooti",

package/src/api/rubriquesApi.ts

@@ -24,18 +24,6 @@ async function searchRubriquages(organisationIds: Array<string>, searchOptions?:
     });
 }
 
-/**
- * Fetch rubriquage data by ID
- * @param rubriquageId ID of the rubriquage to fetch
- * @returns The rubriquage
- */
-async function getRubriquage(rubriquageId: number): Promise<Rubriquage> {
-    return classicApi.fetchData<Rubriquage>({
-        api: ModuleApi.DEFAULT,
-        path: `rubriquage/${rubriquageId}`
-    });
-}
-
 async function searchRubriques(searchOptions?: {
     rubriquageId?: number;
     organisationId?: string|Array<string>;
@@ -73,7 +61,6 @@ async function getCachedRubrique(rubriqueId: number): Promise<Rubrique> {
 }
 
 export const rubriquesApi = {
-    getRubriquage,
     getRubrique,
     getCachedRubrique,
     searchRubriquages,

package/src/components/display/filter/AdvancedSearch.vue

@@ -181,8 +181,6 @@ const props = withDefaults(defineProps<{
     rubriqueFilter?: Array<RubriquageFilter>;
     /** The filter on groups */
     emissionGroups?: Array<EmissionGroup>;
-    /** Force hide the emission group filter */
-    hideEmissionGroups?: boolean;
 }>(), {
     sort: "DATE",
     monetisable: "UNDEFINED",
@@ -219,10 +217,6 @@ const filterStore = useFilterStore();
 const authStore = useAuthStore();
 
 onMounted(async() => {
-    if (props.hideEmissionGroups) {
-        showEmissionGroups.value = false;
-        return;
-    }
     // Only show emission groups if there are some
     const nbGroups = await groupsApi.count({
         organisationIds: [props.organisationId]

package/src/components/layouts/PresentationLayout.vue

@@ -3,7 +3,10 @@
 -->
 <template>
   <div class="d-flex flex-column p-3">
-    <h2 v-if="title">
+    <h2
+      v-if="title"
+      class="mb-3"
+    >
       {{ title }}
     </h2>
     

package/src/components/misc/ClassicNotifications.vue

@@ -14,10 +14,7 @@
 <script setup lang="ts">
 import { storeToRefs } from 'pinia';
 import { useNotificationStore } from '../../stores/NotificationStore';
-
-const MessageModal = defineAsyncComponent(() => import('./modal/MessageModal.vue'));
-
-import { defineAsyncComponent } from 'vue';
+import MessageModal from './modal/MessageModal.vue';
 
 const {
     clearNotification

package/src/components/pages/PlaylistsPage.vue

@@ -1,5 +1,6 @@
 <template>
   <section v-if="isInit" class="page-box">
+    <!-- TODO à intégrer dans frontoffice -->
     <router-link
       v-if="isRolePlaylists && !isPodcastmaker"
       to="/main/priv/edit/playlist"

package/src/helper/downloadHelper.ts

@@ -14,17 +14,28 @@ export default {
       }
     }
     xhr.responseType = "blob";
-    xhr.onload = function () {
-      const urlCreator = window.URL || window.webkitURL;
-      const imageUrl = urlCreator.createObjectURL(this.response);
-      const tag = document.createElement("a");
-      tag.href = imageUrl;
-      tag.target = "_blank";
-      tag.download = nameOfDownload.replace(/ /g, "_");
-      document.body.appendChild(tag);
-      tag.click();
-      document.body.removeChild(tag);
-    };
-    xhr.send();
+
+    return new Promise<void>((resolve, reject) => {
+      xhr.onload = function () {
+        if (xhr.status !== 200) {
+          reject(new Error(`Download failed with status ${xhr.status}`));
+          return;
+        }
+        const urlCreator = window.URL || window.webkitURL;
+        const imageUrl = urlCreator.createObjectURL(this.response);
+        const tag = document.createElement("a");
+        tag.href = imageUrl;
+        tag.target = "_blank";
+        tag.download = nameOfDownload.replace(/ /g, "_");
+        document.body.appendChild(tag);
+        tag.click();
+        document.body.removeChild(tag);
+        resolve();
+      };
+      xhr.onerror = function () {
+        reject(new Error("Download failed"));
+      };
+      xhr.send();
+    });
   },
 };

package/src/stores/AuthStore.ts

@@ -227,8 +227,7 @@ export const useAuthStore = defineStore("AuthStore", {
         });
         this.authUpdateOrganisation(activeOrganisation);
         this.fetchProfileAsynchrone();
-      } catch(error) {
-        console.error(error);
+      } catch {
         if (this.authReload > 5) {
           return;
         }

package/src/stores/NotificationStore.ts

@@ -15,8 +15,6 @@ interface Notification {
     type: NotificationType;
     /** When set to false, disallow manual closing of modal notification (default: true) */
     closeable?: boolean;
-    /** Callback called when the notification is closed */
-    closeCallback?: () => void;
 }
 
 export const useNotificationStore = defineStore('notifications', () => {
@@ -36,10 +34,6 @@ export const useNotificationStore = defineStore('notifications', () => {
         if (notif !== null) {
             const idx = notificationQueue.value.indexOf(notif);
             notificationQueue.value.splice(idx, 1);
-
-            if (notif.closeCallback) {
-                notif.closeCallback();
-            }
         }
     }
 

package/BUILD_FIX.md

@@ -1,105 +0,0 @@
-# Fixing `@` alias resolution when consumed by other projects
-
-## Problem
-
-`octopus-sdk` currently publishes raw TypeScript source. When a consumer (e.g. frontoffice)
-bundles the SDK, it processes source files with its own Vite config, so `@/` imports resolve
-against the consumer's `src/` instead of the SDK's. This affects both dev and production builds.
-
-## Solution: build the SDK as a library
-
-The SDK should be pre-built so all `@` aliases are resolved before any consumer sees the files.
-
----
-
-## 1. Install `vite-plugin-dts`
-
-```sh
-npm install -D vite-plugin-dts
-```
-
----
-
-## 2. Update `vite.config.js`
-
-Add a `lib` build alongside the existing app config. The alias resolution in the `resolve` block
-ensures `@` is rewritten to relative paths in the output.
-
-```js
-import dts from 'vite-plugin-dts';
-
-// In the build config:
-build: {
-  lib: {
-    entry: path.resolve(__dirname, 'index.ts'),
-    formats: ['es'],
-    fileName: 'index',
-  },
-  outDir: 'dist',
-  rollupOptions: {
-    // Mark all dependencies as external so they are not bundled
-    external: (id) => !id.startsWith('.') && !path.isAbsolute(id),
-  },
-},
-plugins: [
-  vue(),
-  dts({ rollupTypes: true }),
-],
-```
-
-Run `npm run build` to produce `dist/index.js` and `dist/index.d.ts`.
-
----
-
-## 3. Update `package.json`
-
-Point `exports` to the built output instead of raw source:
-
-```json
-"exports": {
-  ".": {
-    "types": "./dist/index.d.ts",
-    "default": "./dist/index.js"
-  }
-},
-"files": ["dist"]
-```
-
----
-
-## 4. Development workflow
-
-With a built package, `npm link` / `yalc link` alone is no longer enough — consumers need the
-built output, not the source.
-
-**Option A — watch build (recommended for active SDK development):**
-
-```sh
-# Terminal 1 — SDK
-npm run build -- --watch
-
-# Terminal 2 — frontoffice
-npm run dev
-```
-
-frontoffice picks up changes via the symlink each time the SDK rebuild completes.
-HMR in frontoffice will trigger on the rebuilt file, not on source edits directly.
-
-**Option B — yalc push on change:**
-
-```sh
-# In octopus-sdk, after each change:
-npm run build && yalc push
-```
-
-frontoffice receives the new build automatically if `yalc` is configured with `--watch`.
-
----
-
-## What to revert in frontoffice
-
-Once the SDK is built, remove from frontoffice's `vite.config.js`:
-
-- `optimizeDeps.exclude: ['@saooti/octopus-sdk']` — no longer needed
-- `server.watch.ignored: ['!**/node_modules/@saooti/octopus-sdk/**']` — no longer needed
-- `server.fs.allow: ['../../../octopus-sdk']` — no longer needed (for npm link setups)