@communecter/cocolight-api-client 1.0.198 → 1.0.200

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@communecter/cocolight-api-client",
-  "version": "1.0.198",
+  "version": "1.0.200",
   "description": "Client Axios simplifié pour l'API cocolight",
   "repository": {
     "type": "git",

package/types/api/EndpointApi.d.ts

@@ -1392,7 +1392,7 @@ export declare class EndpointApi {
      */
     generateMilestoneFromDepense(data: GenerateMilestoneFromDepenseData): Promise<any>;
     /**
-     * Trouver les informations sur les enveloppes d’un formulaire : Trouver les informations sur les enveloppes d’un formulaire
+     * Trouver les informations sur les enveloppes d’un formulaire : Trouver les informations sur les enveloppes d’un formulaire et payer une cagnotte (stripePay, helloassoPay, helloassoStatus, cagnotteSettle, cagnotteBills). `order` : contribution `{answerId, financerId, fundings:[{milestoneId|depenseKey, amount}]}` ou promesses `{pledges:[{answerId, depenseKey, financerId, finkey|finIndex, amount}]}`, éventuellement avec un crédit d'enveloppe `envelope:{formId[, amount]}` (seul : `{financerId, envelope:{formId, amount}}`) ; obligatoire pour stripePay et helloassoPay ; son montant est débité, puis le serveur enregistre engagements et versements une fois le paiement vérifié. stripePay et helloassoPay exigent un utilisateur connecté. stripePay exige aussi `amount` (> 0, remplacé par le montant de la commande) et `payment_method_id`, à renvoyer au rejeu ; il prend `key`, clé de la tentative (16 à 64 caractères `[A-Za-z0-9-]`) : rejouée, la requête retrouve la même facture et la même clé d'idempotence Stripe, sans second débit. helloassoStatus prend `checkoutIntentId`, cagnotteSettle `bill`, cagnotteBills `filter` (`attention` | `all`) : toutes les factures pour un admin de l'entité, les siennes pour un autre utilisateur connecté. getEnvelopeData annonce `paymentMethods.serverSettlement` (paiements facturés et enregistrés par le serveur) ; il règle d'abord au plus deux factures de la cagnotte restées en attente (vérification chez Stripe ou HelloAsso, puis écriture des engagements et versements).
      * Constant : FUNDING_ENVELOPE
      * @param data - Données envoyées à l'API
      * @returns Les données de réponse.

package/types/costum/runtime.d.ts

@@ -4,6 +4,20 @@ import type { Event } from "../api/Event.js";
 import type { Organization } from "../api/Organization.js";
 import type { Poi } from "../api/Poi.js";
 import type { Project } from "../api/Project.js";
+/**
+ * Forme d'un slug de costum, celle qu'exige la requête de `COSTUM_RESOLVED` (`costum/co/resolved`).
+ * Recopiée du contrat : `tests/unit/costum-prefetch-slug.test.ts` la compare au `pattern` du module d'endpoints.
+ */
+export declare const COSTUM_SLUG_RE: RegExp;
+/**
+ * Slug de costum d'un document CHARGÉ : `source.key`, repli sur `source.keys[0]` — la préséance des trois
+ * lecteurs d'avant (`get()`, finalizer de `searchCostum`, `_setData`) — retenu SEULEMENT s'il a la forme
+ * d'un slug. Ces lecteurs typaient la donnée `{ key?: string; keys?: string[] }`, ce qu'elle n'est pas
+ * toujours (cf. `prefetchCostums`) : `_setData` passait un tableau à `resolveCostumCtxFromSource`, où
+ * `COSTUM_RUNTIME[sourceKey]` le convertissait en chaîne (`["x"]` → `"x"`). Une clé invalide ne se rabat
+ * PAS sur `keys[0]` : seule une clé absente le fait, comme avant.
+ */
+export declare function sourceKeyOf(doc: unknown): string | undefined;
 /** Active/désactive FORCE-LIVE (cf. `COSTUM_FORCE_LIVE`). */
 export declare function setCostumForceLive(actif: boolean): void;
 /** État courant de FORCE-LIVE. */
@@ -25,8 +39,18 @@ export declare function describeCostumForms(user: BaseEntity, slug: string): Pro
  * Pré-charge EN BATCH les costums (par slug) manquants/périmés du cache live, AVANT un revive synchrone
  * (finalizer de `searchCostum`, `get()`, `entitySlug`). Dédup + TTL : un slug déjà frais est ignoré.
  * Chaque fetch qui échoue est avalé (offline → le revive retombera sur le bundle). Concurrence bornée.
+ *
+ * Seules les clés à la forme d'un slug de costum partent. La base porte des `source.key` qui n'en sont pas
+ * (mesuré le 2026-10-15) : des TABLEAUX sur 820 éléments — `["crowdfunder"]` d'un import de 2016 sur un
+ * membre d'Open Atlas, mais aussi 5 organisations créées en 2024-2025 avec `insertOrign: "costum"` — et des
+ * chaînes hors format (`"MCZD33 Import2"`, `"<id>@organizations"`). La validation de `COSTUM_RESOLVED`
+ * refusait ces clés avant tout envoi : les écarter ne perd aucune résolution, et `safeCall` ne journalise
+ * plus une ERREUR à chaque recherche qui liste l'élément.
+ * Certaines nomment pourtant un vrai site (`["reunion10"]`, `["occitanie1"]`), et le legacy les y compte :
+ * MongoDB fait correspondre `{"source.key": "reunion10"}` à un tableau qui contient la valeur. La lib ne
+ * leur résolvait déjà aucun costum ; les rattacher relève de la normalisation des données, pas de ce filtre.
  */
-export declare function prefetchCostums(user: BaseEntity, sourceKeys: (string | null | undefined)[]): Promise<void>;
+export declare function prefetchCostums(user: BaseEntity, sourceKeys: readonly unknown[]): Promise<void>;
 /**
  * Contexte costum résolu, attaché à une instance d'entité via `config.costumCtx`.
  * Porté tel quel par `BaseEntity._costumCtx` et consommé par les 3 couches de filtrage.