Push notifications module

v1.0.12026/10/07

Security fixes. An update is recommended.

• Every back-office action now checks profile permissions. PrestaShop only checks them for actions it recognizes (deleting from a list, saving a standard form); module-specific actions used to be accessible to any employee with access to the tab. A read-only profile could send a campaign to all subscribers , change the URL and relay keys, regenerate the VAPID pair, or delete notification variants. Now: view for exporting and reporting, add for creating and importing, edit for saving, scheduling, and testing, and delete for deleting.
• The export with keys is only downloaded by a SuperAdmin , and by default it is exported without them. This file contains the browser keys and the VAPID private key: with it, you can write to all subscribers from anywhere. Generating and rotating the VAPID pair is also only available to SuperAdmins.
• Tests can no longer be sent to a customer. They used to go to the last viewed subscriber, who in an open store is usually a customer: they would receive the campaign half-written. Now they only go to the test devices that the merchant selects in Settings from their own browser, with a button that reads that browser's subscription: you can't select someone else's.
• The back-to-stock notification only applies to the browser itself. It accepted one subscriber ID per parameter, so it was possible to subscribe another user to notifications they hadn't requested.
• The service worker no longer saves back-office pages. Its / includes the administration folder, and pages containing customer data, orders, and tokens were previously stored in the employee's browser cache. Now, it doesn't save anything marked as no-store or private by the server, which is how PrestaShop serves the back office. When the service worker version changes, it deletes the caches from version 1.0.0 , which also removes any existing cached data.
• The configuration export no longer includes the cron token or the relay account key. It can be downloaded using a read-only profile, and the cron token is used to initiate transmissions.

v1.0.02026/09/28

First version.

• Complete PWA: manifest generated from the configuration, icons in all sizes —including maskable ones— from the store logo, service worker with caching strategies by type and its own offline page.
• The service worker is served from the store's domain with the Service-Worker-Allowed header, and the settings screen checks the actual reach by looking at the headers that actually arrive, including the CDN in front.
• Capture subscribers with your own notification in two steps and A/B testing, with triggers for time, scroll, exit, add to cart and number of views.
• Consent record with date, time, truncated IP address, displayed text, and version.
• Seven automations: abandoned cart in three steps with coupon, return to stock, price drop, order status, abandoned navigation, replenishment due to consumption and reactivation of inactive items.
• Campaigns with behavioral segmentation, scheduling, topic , action buttons, preview, and real byte counter after encryption.
• Complete metrics — sent, displayed, clicked, closed, expired — and attributed revenue with configurable window.
• Import from PushOwl/Brevo, OneSignal, PushEngage, Webpushr and generic CSV, with sample testing before accepting the batch, and silent resubscription progress panel.
• Complete export in one click, with keys and VAPID pair, in CSV and JSON.
• First-class standalone mode: the module handles delivery independently using curl_multi and its VAPID partner. With the RKR Push Relay connected, it delegates bulk delivery, and if the relay fails to respond, critical transactions are sent from the store.
• Frequency budget per subscriber, quiet hours in each subscriber's time zone, and deduplication.
• Rotation of the VAPID pair with a grace period.
• Multi-store and multi-language support, WCAG 2.2 AA accessibility in the notice, no inline JavaScript and no third-party dependencies.

Checked before publishing

Installed and run on PrestaShop 9.1.5 (multi-store, two stores). Four things came out of it that aren't visible when reading the code:

• A friendly URL ending in .js doesn't work in PrestaShop. The server ignores routing for anything ending in .gif , .jpg , .png , .css , .js , or .ico . The service worker's path has no extension; the browser looks at the Content-Type .
• ObjectModel rejects a null date in each UPDATE if the field is not declared with allow_null . It was triggered on the second save, that is, the second time someone subscribed using the same browser.
• Db::getValue() adds its own LIMIT 1 , so a query with LIMIT ... OFFSET ends up as LIMIT 1 OFFSET 5000 LIMIT 1 and MySQL rejects it. It only happened during daily cleanup: one error per day.
• Google rejects Urgency: very-low with a 400 error, even though RFC 8030 defines it; it only accepts high , normal , and low . Without translation, the sample import test would have resulted in all Chrome subscriptions being terminated. Delivery was verified against fcm.googleapis.com : a non-existent endpoint returns a 410 error, which proves that the service accepts the VAPID signature and encryption, and that the module interprets it as a permanent termination.