Follow-up from Cloud Print redesign Phase 5 (#535), deferred per the agreed minimal scope + the implementer guardrail.
Context
The client cloud-print path uploads raw bytes (CloudEnqueueFn carries only { data: Uint8Array; contentType: string }) — correct for Star CloudPRNT (raw ESC/POS, application/octet-stream), which works today. Epson SDP rejects raw payloads server-side and PrintNode never polls, so for those two the server must render+deliver an order-based job: POST /wcpos/v1/print-jobs with { printer_id, order_id, template_id } (no payload). The server side already supports this (wcpos/woocommerce-pos#1094).
Gap
The client does not send order-based jobs. PrinterProfile.cloudProvider is now persisted (PR #535), so the profile knows the provider — but threading order_id + the server template_id to the enqueue requires extending CloudPrintJob/CloudEnqueueFn with an order-based variant and plumbing orderId + server templateId through receipt.tsx → usePrint → PrinterService → CloudAdapter, then branching in createCloudEnqueueFactory on profile.cloudProvider (~5 files + a contract change that ripples into the cloud tests).
Acceptance
For an Epson/PrintNode cloud printer, a manual print uploads { printer_id, order_id, template_id } and the server renders+delivers; Star CloudPRNT continues to upload raw ESC/POS unchanged.
Follow-up from Cloud Print redesign Phase 5 (#535), deferred per the agreed minimal scope + the implementer guardrail.
Context
The client cloud-print path uploads raw bytes (
CloudEnqueueFncarries only{ data: Uint8Array; contentType: string }) — correct for Star CloudPRNT (raw ESC/POS,application/octet-stream), which works today. Epson SDP rejects raw payloads server-side and PrintNode never polls, so for those two the server must render+deliver an order-based job:POST /wcpos/v1/print-jobswith{ printer_id, order_id, template_id }(no payload). The server side already supports this (wcpos/woocommerce-pos#1094).Gap
The client does not send order-based jobs.
PrinterProfile.cloudProvideris now persisted (PR #535), so the profile knows the provider — but threadingorder_id+ the servertemplate_idto the enqueue requires extendingCloudPrintJob/CloudEnqueueFnwith an order-based variant and plumbingorderId+ servertemplateIdthroughreceipt.tsx → usePrint → PrinterService → CloudAdapter, then branching increateCloudEnqueueFactoryonprofile.cloudProvider(~5 files + a contract change that ripples into the cloud tests).Acceptance
For an Epson/PrintNode cloud printer, a manual print uploads
{ printer_id, order_id, template_id }and the server renders+delivers; Star CloudPRNT continues to upload raw ESC/POS unchanged.