🦋🤖 Forward receipt to customer from order page (#2375)

[Tirodem]

• Employees can now forward a receipt to a customer directly from the order page
• Available on paid orders only, for both classic POS and POS Touch
• Supports sending via email (sends the order.paid email) or Nostr DM (sends ticket content + order link)
• Inline form with contact address input (email or Nostr npub), same pattern as the RSVP form
• Success confirmation displayed after forwarding

[Tirodem]

@gntw @roosemberth Either vibefix or vibeprototype, depending of your's review feedbacks. Pilot's request. QA is OK ✅

[gntw]

@Tirodem got a questsion about the Nostr DM content in forwardReceipt: currently the DM sent to the customer only contains a link — Order #N receipt: . The original issue description mentions "the customer receives a DM with the ticket content and order link". Is this intentional to keep it minimal (just the link), or should we include more order details in the DM (items, total amount, payment method etc.)?

[Tirodem]

yeah, I changed the behavior after test-exploring. Trying to recreate the ticket on nostr dm was a bad idea, sending the link is better. In the future when implemented we'll use the order.paid nostr template instead, and for now we'll send the link. Le ven. 13 févr. 2026, 11:11, Vadim ***@***.***> a écrit :

…

*gntw* left a comment (be-BOP-io-SA/be-BOP#2377) <#2377 (comment)> @Tirodem <https://github.com/Tirodem> got a questsion about the Nostr DM content in forwardReceipt: currently the DM sent to the customer only contains a link — Order #N receipt: . The original issue description mentions "the customer receives a DM with the ticket content and order link". Is this intentional to keep it minimal (just the link), or should we include more order details in the DM (items, total amount, payment method etc.)? — Reply to this email directly, view it on GitHub <#2377 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL7BKPVI2RPVNPYNKSW3CTD4LWPLRAVCNFSM6AAAAACUDQ2WHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQOJWGI3DONJZGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Tirodem]

Filling partial npub =

Otherwise, a valid npub is OK, a valid email is OK ✅
It's clearly acceptable, but if it can be done in front, with error message + highlighted input field, it would be great
BTW, it can be another ticket, as it's currently not done in /schedule/{id_schedule}/rsvp/{schedule_event}?/notify.
So :
@gntw , if you're OK with @roosemberth , we can merge like this
@CypherJack , can you create the new ticket to improve this input please

[roosemberth]

I'm not a fan of introducing behaviour in “Various code grooming” commits:

• The refactor and added permission check in this change is a band-aid.
• We hid new behavior in a “grooming” commit, if we find this behaviour to be faulty, it will waste people's time to figure out the extent of the problem.

Please move this to a separate commit.

[gntw]

I'm not a fan of introducing behaviour in “Various code grooming” commits:

• The refactor and added permission check in this change is a band-aid.
• We hid new behavior in a “grooming” commit, if we find this behaviour to be faulty, it will waste people's time to figure out the extent of the problem.

Please move this to a separate commit.

If we are going to merge all of this, then we probably wanted to squash it into one commit, as we do it in most of our pull requests? There are currently five commits in the branch, and I don't see much point in keeping them separate. I agree, the topic of my commit is ridiculous, but I thought that after the review I would squash all these commits into one so as not to clutter up the main branch. And then I could write a normal description for this single commit.

@roosemberth is that ok ?