Ticket SKU is missing

[mihob]

Describe the bug

It looks as if purchased tickets no longer have a unique SKU. The value is still available in the documentation (https://verbb.io/craft-plugins/events/docs/developers/purchased-ticket).

The setting is also still available in the Event Type Settings:

However, I cannot find anything about this in the code of the PurchasedTicket element

When I try to access the ticketSku attribute in the template, I get the following error:

Calling unknown method: verbb\events\elements\PurchasedTicket::ticketSku()

Is this intentional? We need a unique SKU for ticket printing and check-in.

Steps to reproduce

Craft CMS version

5.5.2

Plugin version

3.0.3

Multi-site?

YES

Additional context

No response

[engram-design]

It's correct that purchased tickets no longer have an SKU generated. Instead, we use the UID of the ticket for ticket check in, which is mentioned in the docs.

People were getting some collisions with the SKUs for purchased tickets, so we opted to rely on the already-unique UID for a purchased ticket. I have updated the docs to reflect this.

This isn't to be confused with a Ticket SKU, which still exists as part of the purchasable interface.

[mihob]

Oh sorry, I didn't see that.

Hmm, which attribute would that be? id?

That's quite unfortunate, as we actually need a halfway readable identifier for our processes. For example, if something doesn't work when scanning the ticket, etc

Wasn't the problem rather that the SKU was not checked to see if it was unique when it was created? (

events/src/helpers/TicketHelper.php

Line 44 in 8074cf6

public static function generateTicketSKU(): string

)

Well, we can probably solve the problem ourselves with a custom field that is automatically filled when the ticket is created.

[engram-design]

Sorry, that's the uid attribute, different to the id attribute. It's something that every "thing" in Craft gets.

That's a fair call, we also removed it just to lower the overhead of things, generating a new SKU upon creation, but more than happy to add it back if it's going to be a hassle on your end.

[mihob]

Hmm, I don't know if this is a usecase that is really interesting for other people. For example, if you buy a concert ticket from a large provider, you can usually do little with the number.

I have already solved it with a custom field that is filled in the event PurchasedTicket::EVENT_BEFORE_SAVE, similar to the old logic from v2 with a unique check if the ticket is new.

Thanks for your explanations.