@tekkare/romulus 0.1.242 → 0.1.244

package/layer/app/composables/useAdminAccess.ts

@@ -0,0 +1,86 @@
+import { useOipApi } from "#oip-app/api";
+/**
+ * useAdminAccess - a-t-on le droit de publier un template, et pour qui.
+ *
+ * Deux choses distinctes, souvent confondues :
+ * - `isPlatformAdmin`, porte par `/me/summary`, vaut pour toute adresse
+ *   @tekkare.com : il ouvre les produits, pas l'administration ;
+ * - `isSuperAdmin`, rendu par `/superadmin/me`, est attribue a la main. C'est
+ *   lui qui garde la console d'OIP 7, donc aussi `/superadmin/workspaces`.
+ *
+ * Publier un template met une vue devant des espaces clients : c'est le
+ * second portillon, le meme que la console. Rien n'est demande au chargement
+ * de la page : `ensureLoaded()` n'est appele qu'a l'ouverture du dialogue de
+ * partage, sans quoi tout le monde paierait un aller-retour pour une option
+ * que presque personne ne voit.
+ *
+ * Meme forme que le composable homonyme d'OIP 7 : un `useState` partage, une
+ * seule requete par session.
+ */
+export interface AdminWorkspace {
+  workspaceId: string;
+  name: string;
+  tier: string;
+}
+
+export const useAdminAccess = () => {
+  const isSuperAdmin = useState<boolean>("admin:isSuperAdmin", () => false);
+  const loaded = useState<boolean>("admin:loaded", () => false);
+  const workspaces = useState<AdminWorkspace[]>("admin:workspaces", () => []);
+  const workspacesLoaded = useState<boolean>("admin:workspacesLoaded", () => false);
+  const elysiaApi = useOipApi();
+  const { status } = useAuth();
+
+  async function ensureLoaded(): Promise<boolean> {
+    if (loaded.value) return isSuperAdmin.value;
+    if (status.value !== "authenticated") return false;
+    try {
+      const me = await elysiaApi.admin.me();
+      isSuperAdmin.value = !!me?.isSuperAdmin;
+    } catch {
+      isSuperAdmin.value = false;
+    } finally {
+      loaded.value = true;
+    }
+    return isSuperAdmin.value;
+  }
+
+  /**
+   * Tous les espaces, pour le selecteur de cibles d'un template.
+   *
+   * La route est paginee et rend bien plus que des noms (licences, membres,
+   * comptes) : on la deroule une fois, on ne garde que le nom, et on ecarte
+   * les espaces personnels — offrir un template a l'espace prive de
+   * quelqu'un n'a pas de sens. La recherche se fait ensuite dans le
+   * selecteur, sur la liste en memoire, comme pour les membres.
+   */
+  async function ensureWorkspaces(): Promise<AdminWorkspace[]> {
+    if (workspacesLoaded.value) return workspaces.value;
+    if (!(await ensureLoaded())) return [];
+
+    try {
+      const first = await elysiaApi.admin.workspaces({ page: 1, limit: 100 });
+      const pages = first?.pagination?.totalPages ?? 1;
+      const rest = await Promise.all(
+        Array.from({ length: Math.max(0, pages - 1) }, (_, i) =>
+          elysiaApi.admin.workspaces({ page: i + 2, limit: 100 }),
+        ),
+      );
+
+      workspaces.value = [first, ...rest]
+        .flatMap((res) => res?.workspaces ?? [])
+        .filter((ws) => !ws.isPersonal)
+        .map((ws) => ({ workspaceId: ws.workspaceId, name: ws.name, tier: ws.tier }))
+        .sort((a, b) => a.name.localeCompare(b.name));
+    } catch (err) {
+      console.error("[useAdminAccess] Impossible de lister les espaces:", err);
+      workspaces.value = [];
+    } finally {
+      workspacesLoaded.value = true;
+    }
+
+    return workspaces.value;
+  }
+
+  return { isSuperAdmin, workspaces, ensureLoaded, ensureWorkspaces };
+};

package/layer/app/composables/useAlertBrandSync.ts

@@ -0,0 +1,85 @@
+/**
+ * useAlertBrandSync - proposer a une alerte de marque de suivre sa vue.
+ *
+ * Une alerte de vue est repointee toute seule quand la vue bouge : l'API
+ * compare les criteres et la page lui remet sa requete (cf.
+ * `alertRefreshPayload`). Une alerte de MARQUE, elle, ne peut pas l'etre :
+ * elle ne lit ni les filtres de la vue ni son index, elle porte sa propre
+ * liste de marques, figee a la creation.
+ *
+ * Sur les pages de ventes c'est le seul genre d'alerte possible, et la vue y
+ * est justement une selection de produits : elargir la vue sans toucher a
+ * l'alerte laisse une veille qui ne couvre plus ce que l'ecran montre, sans
+ * que rien ne le dise.
+ *
+ * D'ou cette demande, posee au moment ou la vue est enregistree. Demander, et
+ * non suivre en silence : une alerte de marque qui suivrait sa vue d'
+ * elle-meme deviendrait une alerte de vue deguisee, alors que les deux ne se
+ * remettent pas a jour de la meme facon et ne survivent pas aux memes
+ * changements.
+ */
+import type { Alert } from "#oip-app/api";
+
+export interface AlertBrandSyncRequest {
+  alert: Alert;
+  /** Marques que porte desormais la vue. */
+  brands: string[];
+  /** Celles que l'alerte suit encore. */
+  current: string[];
+}
+
+const pending = shallowRef<AlertBrandSyncRequest | null>(null);
+const syncing = ref(false);
+
+export function useAlertBrandSync() {
+  const alerts = useAlerts();
+
+  /**
+   * Regarde si la vue enregistree porte une alerte de marque a decaler.
+   *
+   * Rien n'est demande quand les listes sont deja identiques, ni quand la vue
+   * n'a plus de marques du tout : une vue videe ne veut pas dire « ne
+   * surveille plus rien », et l'API refuserait une alerte sans marque.
+   *
+   * Une seule alerte a la fois : deux demandes empilees feraient deux modales
+   * l'une derriere l'autre, et le cas ne s'est jamais presente.
+   */
+  function ask(pulseId: string, brands: string[]) {
+    if (brands.length === 0) return;
+
+    const alert = alerts.alerts.value.find(
+      (entry) => entry.kind === "product" && entry.pulseId === pulseId,
+    );
+    if (!alert) return;
+
+    const current = alert.brands ?? [];
+    const same =
+      current.length === brands.length &&
+      [...current].sort().join("|") === [...brands].sort().join("|");
+    if (same) return;
+
+    pending.value = { alert, brands, current };
+  }
+
+  function dismiss() {
+    pending.value = null;
+  }
+
+  /** Reporte les marques de la vue sur l'alerte. L'API la reseme. */
+  async function confirm() {
+    const request = pending.value;
+    if (!request) return;
+    syncing.value = true;
+    try {
+      await alerts.update(request.alert.id, { brands: request.brands });
+      // L'alerte repart en `seeding` cote worker : la carte doit le dire.
+      await alerts.load(true);
+      alerts.followSeeding();
+      pending.value = null;
+    } finally {
+      syncing.value = false;
+    }
+  }
+
+  return { pending: computed(() => pending.value), syncing, ask, dismiss, confirm };
+}

package/layer/app/composables/useAlertSource.ts

@@ -0,0 +1,210 @@
+/**
+ * useAlertSource - ce qu'une page donne a surveiller.
+ *
+ * Une alerte rejoue la requete d'une vue sauvegardee et rapporte ce qui y
+ * apparait, y change ou en sort. L'API ne sait pas construire cette requete :
+ * la DSL Elasticsearch est assemblee dans le navigateur, clause par clause,
+ * par les composants de filtre de la page (`elasticQueryStore`). La page la
+ * remet donc telle quelle au moment ou l'alerte est creee, et l'API la garde
+ * figee.
+ *
+ * Consequence assumee : une vue modifiee doit repointer ses alertes. Quand
+ * l'edition part de la page, le client renvoie la nouvelle requete avec les
+ * criteres et l'API repart d'une nouvelle reference. Par tout autre chemin,
+ * l'alerte passe en `stale` et attend d'etre rearmee ici.
+ *
+ * Meme forme que `useExportSource` et `useViews` : un `shallowRef` de module,
+ * pose au montage, retire au demontage, donc rien a nettoyer a la main et rien
+ * qui traverse le rendu serveur (les descripteurs portent des fonctions).
+ */
+import type { AlertResourceType as HubrResourceType } from "#oip-app/alerts";
+import { VIEW_BRAND_FILTERS } from "#oip-app/views";
+
+/** Un champ que la page propose de surveiller. */
+export interface AlertField {
+  /** Chemin du champ dans le `_source`, points admis. */
+  value: string;
+  /** Libelle affiche, deja traduit. */
+  label: string;
+}
+
+export interface AlertSource {
+  /** Index Elasticsearch interroge par la page. */
+  index: string;
+  /** Famille du document, cf. `useHubrResourceKinds`. */
+  resourceType: HubrResourceType;
+  /**
+   * Requete de l'ecran, relue au moment ou l'alerte est creee.
+   *
+   * La clause `query` seule : ni tri, ni agregation, ni pagination. Le tri ne
+   * decrit rien pour une alerte (le diff porte sur un ensemble, pas sur un
+   * classement) et les agregations couteraient cher pour rien.
+   */
+  query: () => any;
+  /**
+   * Champs relus pour nommer un element dans le journal : titre, puis
+   * sous-titre. Ils sont aussi gardes dans la reference, seul endroit ou le
+   * nom d'un element sorti de la vue existe encore.
+   */
+  labelFields: [string] | [string, string];
+  /** Champs surveillables, tels que la page les propose a l'ecran. */
+  fields: AlertField[];
+  /** Titre suggere a la creation. Defaut : le nom de la vue. */
+  defaultTitle?: string;
+}
+
+const registry = shallowRef<(() => AlertSource | null) | null>(null);
+
+/**
+ * Marques que la page affichee met en avant, quand elle en met une.
+ *
+ * Deuxieme registre plutot qu'un champ de `AlertSource` : une fiche produit et
+ * l'ecran de recherche ne livrent aucune requete surveillable (l'une est un
+ * document, l'autre un agregat de dix index), ils n'ont donc pas de source du
+ * tout. Ils ont pourtant la seule chose dont une alerte de MARQUE a besoin :
+ * le nom du produit qu'on regarde.
+ *
+ * Ce sont des candidats, pas des marques : le panneau les confronte au
+ * repertoire avant de cocher quoi que ce soit, parce qu'un terme de recherche
+ * peut etre une molecule (« pembrolizumab ») ou n'exister nulle part.
+ */
+const brandRegistry = shallowRef<(() => string[]) | null>(null);
+
+export function useAlertSource() {
+  /**
+   * Declare la source de la page. A appeler dans le `setup`, une seule fois :
+   * le descripteur est relu a chaque acces, donc il peut lire des refs.
+   */
+  const declare = (build: () => AlertSource | null) => {
+    // Page du tiroir de projet : les alertes restent celles de l'ecran dessous.
+    if (useHubrEmbedded()) return;
+    // Le moteur d'alertes interroge Elasticsearch lui-meme, par NOM : l'id
+    // Directus du catalogue est traduit ici, une fois pour tous les appels.
+    const { nameOf } = useOipEsIndices();
+    const named = () => {
+      const source = build();
+      return source ? { ...source, index: nameOf(source.index) } : null;
+    };
+    registry.value = named;
+    onScopeDispose(() => {
+      if (registry.value === named) registry.value = null;
+    });
+  };
+
+  /** La source de la page affichee, ou `null` si elle n'en declare pas. */
+  const current = computed(() => registry.value?.() ?? null);
+
+  /**
+   * Declare les marques de la page. Meme forme que `declare`, et independant :
+   * une page peut n'avoir que ca.
+   */
+  const declareBrands = (build: () => string[]) => {
+    if (useHubrEmbedded()) return;
+    brandRegistry.value = build;
+    onScopeDispose(() => {
+      if (brandRegistry.value === build) brandRegistry.value = null;
+    });
+  };
+
+  /** Les marques candidates de la page affichee, vides si elle n'en propose pas. */
+  const brands = computed(() =>
+    (brandRegistry.value?.() ?? []).map((brand) => String(brand).trim()).filter(Boolean),
+  );
+
+  return { declare, current, declareBrands, brands };
+}
+
+/**
+ * Noms sous lesquels une vue range sa selection de produits.
+ *
+ * Le portail ecrit `brands` (cf. useDrugsViews), les delivrances
+ * hospitalieres `brandSelection` : c'est le nom qu'elles donnent en base
+ * depuis l'origine, garde tel quel pour ne pas perdre les vues deja
+ * enregistrees.
+ */
+
+/**
+ * Les marques que porte une vue, s'il y en a.
+ *
+ * Sur les pages de ventes, une vue EST une selection de produits : faute de
+ * requete de documents a livrer, « surveiller cette vue » ne peut vouloir
+ * dire que « surveiller ces marques ». C'est ce qui pre-remplit le formulaire
+ * d'alerte, et ce qu'on propose de reporter sur une alerte existante quand la
+ * vue change.
+ */
+export function viewBrandsFromCriteria(criteria: any[]): string[] {
+  const entry = (Array.isArray(criteria) ? criteria : []).find((item: any) =>
+    VIEW_BRAND_FILTERS.includes(item?.filter),
+  );
+  return Array.isArray(entry?.values) ? entry.values.map(String) : [];
+}
+
+/** Deux chemins qui designent la meme page, `trailingSlash` etant actif. */
+const samePage = (a: unknown, b: unknown): boolean =>
+  String(a ?? "").replace(/\/$/, "") === String(b ?? "").replace(/\/$/, "");
+
+/**
+ * Ce qu'une mise a jour de vue doit emporter pour que ses alertes survivent.
+ *
+ * L'API repointe toute seule les alertes d'une vue dont les criteres ont
+ * bouge, mais elle a besoin de la requete : sa DSL est assemblee dans le
+ * navigateur, elle ne sait pas la reconstruire. Sans elle, les alertes
+ * passent en `stale` et attendent un rearmement a la main depuis la page.
+ *
+ * Rien n'est envoye si la vue mise a jour n'est pas celle de la page
+ * affichee : la requete de l'ecran decrirait alors une autre page que la vue
+ * qu'on enregistre.
+ */
+export function alertRefreshPayload(
+  page: unknown,
+): { alertQuery?: any; alertIndex?: string } {
+  const declared = registry.value?.() ?? null;
+  if (!declared) return {};
+  if (!samePage(page, useViews().current.value?.page)) return {};
+  return { alertQuery: declared.query(), alertIndex: declared.index };
+}
+
+/**
+ * Ce que la snackbar ajoute quand des alertes ont suivi, ou pas.
+ *
+ * Sans ce mot, l'API rendait deja ces deux nombres et personne ne les lisait :
+ * une vue elargie endormait ses alertes en silence, et la panne ne se
+ * decouvrait qu'en ouvrant le panneau, parfois des jours plus tard.
+ */
+export function alertRefreshNotice(result: unknown): string {
+  const refreshed = Number((result as any)?.alertsRefreshed ?? 0);
+  const stale = Number((result as any)?.alertsStale ?? 0);
+  // Appelee depuis les magasins, hors setup : la langue vient de l'app, pas de useI18n.
+  const fr = String(tryUseNuxtApp()?.$i18n?.locale?.value ?? "fr") !== "en";
+  const plural = (n: number) => (n > 1 ? "s" : "");
+  if (stale > 0) {
+    return fr
+      ? ` (${stale} alerte${plural(stale)} à réarmer)`
+      : ` (${stale} alert${plural(stale)} to re-arm)`;
+  }
+  if (refreshed > 0) {
+    return fr
+      ? ` (${refreshed} alerte${plural(refreshed)} mise${plural(refreshed)} à jour)`
+      : ` (${refreshed} alert${plural(refreshed)} updated)`;
+  }
+  return "";
+}
+
+/**
+ * Requete d'alerte a partir des filtres d'une page heart.
+ *
+ * Les pages du hub tiennent leurs clauses dans `elasticQueryStore` sous la
+ * forme `{ filter, page, values, keyName }`, et `useHeartElastic` les assemble
+ * en `bool.must` au moment d'interroger le cluster. On reprend exactement le
+ * meme assemblage : une alerte qui ne poserait pas la meme question que
+ * l'ecran ne vaut rien.
+ */
+export function alertQueryFromFilters(filters: any[]): any {
+  return {
+    bool: {
+      must: (filters ?? [])
+        .map((entry: any) => entry?.values)
+        .filter((clause: unknown) => clause !== undefined && clause !== null),
+    },
+  };
+}