Enhancement: Add email field to Paid and Registration sections of Ticketing options

[troughc]

User story:
The Offer section of my events needs to support

• paid registration events that may have different prices
• A URL link or an email addresses as the destination link for both paid registration events and Free registration events

Paid registration events - workshops and courses

I have workshops that have fees (may have more than one price available) and require the visitor to my website to register using an online form or by email. I need to be able to choose either an email address or a URL in the CMS as the link under the 'Register' labeled button on my webpage. My front-end web team can choose the label for the button according to the event type:

• any event type that is under 'Workshop' or 'Course' will have a button labeled something like "Register for event" (choice of web team)
• every other event type will be mapped to a button labeled something like "Buy ticket" (choice of webteam)
  For this user story, I can use Paid Tickets but need an enhancement - I need a field to be able to add an email address.

Free registration events

I have workshops (and/or other events) that are free and require the visitor to my website to register using an online form or by email. I need to be able to choose either an email address or a URL in the CMS as the link under the 'Register' labeled button on my webpage. I don't need to set any prices.

I can use the Registration option with one small enhancement - I need a field to be able to add an email address.

Figma is here

[fjjulien]

Is a new field really needed? This seems overkill when alternatives exist:

1. We could we reuse the organizer.contactPoint email address if no offer.url is available AND "additionalType": "http://kg.artsdata.ca/resource/RequiresRegistration";
2. We could allow users to supply either a URL or an email address under offer.url and then use a Regex to prefix any email address with mailto:.

Option is likely to be deemed an invalid schema by Google. However, it would yield the expected outcome when clicked on by a user: it would open an email message in their email client.

[AbhishekPAnil]

Frontend estimate: 6h
1.Make the prefix "URL" field selectable.
2.Add api integration if needed.
3.Testing the same with email and url.

[saumier]

@fjjulien Thanks for your feedback.

There are 2 parts to the discussion: UI and JSON-LD. For the UI the outcome is in the good hands of Caitlin and our UI/UX designer Stephanie.

For the JSON-LD, I think your option 2 is an excellent idea when creating the Offer JSON-LD. Since there is no "email" property for Offers in schema.org. I tested the following and it seems to pass the validator.schema.org and the Google rich results test. Also, the protocol mailto: is a valid protocol for a URI.

{
      "@context": "https://schema.org",
      "@type": "Event",
      "name": "The Adventures of Kira and Morrison",
      "startDate": "2025-07-21T19:00-05:00",
      "endDate": "2025-07-21T23:00-05:00",
      "eventAttendanceMode": "https://schema.org/OfflineEventAttendanceMode",
      "eventStatus": "https://schema.org/EventScheduled",
      "location": {
        "@type": "Place",
        "name": "Snickerpark Stadium",
        "address": {
          "@type": "PostalAddress",
          "streetAddress": "100 West Snickerpark Dr",
          "addressLocality": "Snickertown",
          "postalCode": "19019",
          "addressRegion": "PA",
          "addressCountry": "US"
        }
      },
      "description": "The Adventures of Kira and Morrison is coming to Snickertown in a can't miss performance.",
      "offers": {
        "@type": "Offer",
        "url": "mailto:[email protected]",
        "price": "30",
        "priceCurrency": "USD",
        "availability": "https://schema.org/InStock",
        "validFrom": "2024-05-21T12:00"
      }
    }