Default pdf templates

[Mikearaya]

No description provided.

[Mikearaya]

@pozylon what do you think?
Default order pdf svg template
Importable order PDF that uses react-pdf

and importable google wallet pass

All imprts are with optional dependencies

[pozylon]

Please check my comments, there is various topics that needs a bit polishing. After that's done we need to check again how we can make the createPDFTicketRenderer actually useful to create customized tickets.

[pozylon]

Comes together nicely, now we need a factory patter for the pdf ticket renderer so someone can easily set logo, image, colors and such stuff to actually generate tickets that resemble a custom brand.

[Mikearaya]

I haven't tested the apple wallet pass, please do on your end if you can

[pozylon]

It's hard to test this functionality as the ticketing example does currently not use the new functions, i'd expect something like this in the ticketing example:

setupTicketing(platform.unchainedAPI as TicketingAPI, {
    renderOrderPDF: createPDFTicketRenderer((orderId: string, context): DefaultTicketProperties => {
      const order = context.modules.orders.getOrderById(orderId);
      const tokens = await modules.warehousing.findTokens({
        "meta.orderId": orderId,
      });
      return {
        title: "Event XY",
        logoUrl: "https://example.com/logo.png",
        orderNumber: orde.orderNumber
        tickets: tokens.map(token => ({
          title: `VIP Ticket: ${token.serialNumber}`,
          qrCode: token.id,
          stripText: `Place: blabla, come early or get the fuck out of here`,
        })),
      }
    }),
  });

renderOrderPDF should be typed to something like this:

createPDFTicketRenderer: (orderId, context) => { contentType: string; blob: ArrayBuffer }

Goal is to give users of the ticketing module a sane default to at least generate usable tickets. If the document generated is unusable it doesn't make sense to give helpers. It should actually print general tickets like in the theater or gastro projects but with a much more generalized design.

User can do:

1. use the default pdf ticket renderer (no pdf but generateOrderSVG renderer, this should generate svg tickets that are completely unbranded but look like tickets and could be used in a mvp)
2. configure the ticketing renderer like above to create at least "logo" branded customized tickets
3. completely re-implement the renderer and take over binary creation

[pozylon]

See my other comment, although the way you structured it comes together well, the actual "value" for the developer is not leveraged

[pozylon]

@Mikearaya i have rebased this branch on master and did some code cleanups and added default initialization logic to the ticketing example with claude so make sure to hard reset before continuing your work. When done, we should be able to cleanup the Theater im Hof Repository substantially leveraging the factory functions to implement the simple ticket case.

Please make sure the tests pass in the ticketing example and use that to test ticketing stuff. Somehow we need to be able to easily test the processes there so it should seed a product that is a ticket and do some checkout and everything.

[Mikearaya]

Added few more tests and fixed existing ones

In general, the fix is to attach rate limiting middleware to the Fastify routes whose handlers perform authorization or other expensive operations. In Fastify applications this is commonly done with the @fastify/rate-limit plugin, which can be configured globally or scoped per-route/per-prefix. To avoid changing existing behavior, we should add a modest, configurable rate limit just to the Apple Wallet webservice routes defined here. This will constrain the number of requests per client IP in a given window while leaving the handlers’ logic, URLs, and methods unchanged.

The best targeted fix within this file is to register the @fastify/rate-limit plugin in a scoped way for the Apple Wallet routes by using fastify.register with a prefix equal to APPLE_WALLET_WEBSERVICE_PATH, and then defining the Apple Wallet route(s) inside that scoped instance with rate-limit options. However, we are constrained to only modify the given snippet and not change imports other than adding well-known packages, and we currently register that route directly on fastify. A minimal and clear approach is:

• Import @fastify/rate-limit.
• Register it near the top of the default export with a configuration appropriate for authorization endpoints (for example, 60 requests per minute per IP) and, to avoid affecting unrelated routes unexpectedly, apply the rate limit per-route via route-level config or plugin options.
• Attach the rate limit specifically to the Apple Wallet route by adding a config property specifying rate-limit settings.

Concretely in packages/ticketing/src/fastify.ts:

1. Add import rateLimit from '@fastify/rate-limit'; alongside the other imports.
2. Inside the exported default function, before defining routes, ensure the plugin is registered with the Fastify instance using fastify.register(rateLimit, { global: false }); so that no routes are rate-limited unless explicitly configured.
3. Update the Apple Wallet route definition to include a config block such as:

   config: {
     rateLimit: {
       max: 60,
       timeWindow: '1 minute',
     },
   }

   This keeps behavior for other routes the same while enforcing a sensible default for authorization-heavy Apple Wallet endpoints.

[Mikearaya]

I think this is not needed anymore because it is part of master already