v1.12.2

Publiée le 19 août 2026.

Transactions

Chaque winning option de jeu de reçus a besoin d'un attribution slot. Un attribution slot est l'endroit où vous indiquez quand une récompense peut être gagnée, et une winning option qui n'en avait aucun n'était en réalité jamais gagnable : le participant qui l'atteignait était refusé à la dernière étape, faute de fenêtre ouverte pour la débloquer. La publication laissait passer cette situation avec un avertissement ; elle la refuse désormais, pour que le problème apparaisse dans votre phase de construction et non devant un participant.

Cela a une conséquence à anticiper : une winning option de jeu de reçus ne peut plus avoir de stock illimité. Chaque slot porte une quantité supérieure à zéro, et Total Quantity doit être égale à la somme des slots ; « laisser la quantité à 0 pour un stock illimité » n'est donc plus une configuration valide. Si c'est ce sur quoi vous vous appuyiez, décidez du nombre que vous acceptez de distribuer et placez-le dans un slot couvrant la campagne.

Voir Winning options et attribution slots.

Les attribution slots doivent tenir dans la fenêtre de jeu. La publication vérifie aussi chaque slot par rapport à la période pendant laquelle le jeu de reçus est réellement jouable — les dates de la campagne, ou celles du point de contact quand elles s'y substituent. Un slot qui commence avant cette fenêtre ou se termine après elle bloque la publication, et le message nomme les dates dans lesquelles il doit tenir. Une quantité placée hors de la fenêtre jouable ne pouvait jamais être gagnée : elle réduisait donc silencieusement le stock que vous pensiez avoir planifié. Attention à ce point après avoir raccourci une campagne, ou après avoir activé des dates dérogatoires sur un jeu de reçus dont les slots avaient été calés sur les anciennes dates.

Voir Winning options et attribution slots et Attribution slots.

Events

Les activités construites sur l'ancienne structure interne sont refusées à la publication. Les contrôles d'OmniLab sur les activités sont écrits pour la manière dont les activités sont construites aujourd'hui. Une activité antérieure à ce changement pouvait passer la validation avec des éléments manquants, puis casser devant un participant en train de réserver — la publication la nomme donc et s'arrête, au lieu de laisser la panne atteindre le jour de votre événement.

Le correctif consiste à reconstruire le point de contact sous forme de nouvelle activité, avec les mêmes informations, planning, billets et réglages de check-in, puis à supprimer l'ancien. Préparez cette bascule : la nouvelle activité a son propre lien de partage et ses propres QR codes, et les réservations et check-ins déjà enregistrés restent attachés au point de contact que vous remplacez. Si l'événement est en ligne et prend des réservations, parlez-en à votre Customer Success Manager avant de supprimer quoi que ce soit.

Voir Erreurs de validation des événements.

Integrations

Les expériences embarquées dans vos propres pages se comportent mieux dans la page qui les entoure. Une série de corrections sur la façon dont OmniLab s'insère dans une iframe : les tiroirs et formulaires s'ouvrent désormais dans la zone que le visiteur regarde vraiment, et non derrière un en-tête collant ou hors écran ; l'embed ne grandit plus par paliers ni ne tremble quand le contenu change ; et sur mobile, la page derrière l'embed reste immobile pendant qu'un tiroir est ouvert. Gratter une carte à gratter ne fait plus défiler la page hôte avec le geste, et passer d'une étape à l'autre dans l'embed ne fait plus perdre la session du visiteur.

L'essentiel ne demande rien de votre part — OmniLab détermine seul où se trouve votre en-tête. Si le vôtre sort de l'ordinaire, votre équipe web peut l'indiquer directement à OmniLab. Un test rapide sur mobile est utile si vous avez un embed en ligne.

Voir Intégrer OmniLab dans une page web.

Developers

ready-to-open-modal a été retiré de l'intégration embarquée. Une modale dans une expérience embarquée s'ouvre désormais d'elle-même au lieu d'attendre la page parente. Si votre wrapper envoie ready-to-open-modal, retirez-le : plus rien ne l'attend. Le message de fermeture, ready-to-close-modal, est inchangé.

En parallèle, les tiroirs sont maintenant placés et dimensionnés en fonction de la place que votre page laisse réellement à l'embed : ils s'ouvrent donc là où le visiteur regarde, et non derrière un en-tête collant ou hors écran. Le tag JavaScript player s'occupe pour vous du côté page parente ; si votre expérience utilise des tiroirs et que vous écrivez aujourd'hui la page parente à la main, le tag player est désormais le meilleur choix.

Voir Intégration en embed et WebView.

Les options du tag player prennent effet, et trois ont été ajoutées. Les options de présentation du tag JavaScript player — largeur, hauteur et attributs d'iframe — s'appliquent à partir de cette version. Si vous aviez habillé l'embed avec des surcharges CSS sur #omnilab-iframe, vérifiez que celles-ci et vos options concordent.

Les trois nouvelles options sont stickyHeaderSelector, pour désigner votre en-tête collant afin que les tiroirs s'ouvrent en dessous ; topOffset, pour laisser à la place un nombre fixe de pixels libres en haut ; et scrollIntoViewOnNavigate, pour empêcher OmniLab de ramener l'embed dans le champ de vision quand un visiteur passe d'une étape à l'autre.

Voir Options du tag player.