Built in ticket management

[Mikearaya]

No description provided.

[Mikearaya]

This PR adds full support for ticket management both admin-ui and engine side.

new mutations added

• cancelTicket
• cancelEvent
• setEventScannerPassCode - used to set pass code for gate control purpose where each event cant set a unique pass code which users at the gate can use to access gate control portal in admin-ui. users dont need to be loged in to use gate control as long as they have a valid pass code (admins have access without any pass code requirement)
• authenticateGate - used to login into gate control
• deauthenticateGate - log out from gate control
  Cookie is used to store loged in state not session storage used on other projects for this new envs have been introduced UNCHAINED_GATE_COOKIE_NAME & UNCHAINED_GATE_COOKIE_MAX_AGE_SECONDS

New queries

• ticketEvents
• ticketEventsCount
• isPassCodeValid

new resolver access control permissions

• validatePassCode
• gateControl
• viewTokens (passcode-aware)
• viewUserPrivateInfos (passcode-aware)
• updateToken (passcode-aware) permissions for anonymous gate operators

Message templates

• EVENT_CANCELLED
• TICKET_CANCELLED

Admin-ui has Two-mode access in which Admins skip passcode (see all events), anonymous users authenticate via passcode (see only their events)

[pozylon]

sorry i can't review this, create a github issue with a plan and small self-contained steps so i can properly follow, this just touches too much stuff. then we build this step by step

[pozylon]

what's the purpose of this?

[pozylon]

and this?

[pozylon]

i don't know, i think the event scanner pass code feature should be left out of this pr in general for a first version, it's fine if it works with properly logged in users with corect permissions in the beginning.

[pozylon]

All mutations and queries that are ticket specific have to live in the ticketing package, this extension can't be part of the normal api, it's too specific.

[pozylon]

See my other comment about package

[pozylon]

@Mikearaya check the diffs, it's not clean yet, setHeader and getHeader that kind of helpers is fine in api but isCanceled is ticketing specific

[Mikearaya]

@pozylon i've moved all the remaining ticketing-specific resolvers into ticketing packages now

[Mikearaya]

Now admin-ui needs to somehow determine if the ticketing module is loaded on the engine before showing the gate control feature and ticketing. i am trying to figure out the best way to do this

[pozylon]

@Mikearaya can't you just check for permissions? ticketing has additional acl, right? and that's in User.allowedActions. admin-ui components don't have to be in the ticketing extensions

[pozylon]

I think that all ticket management related features should stay in one main menu point in admin-ui, so don't mix in the ticketing stuff in the normal products/user etc.

[pozylon]

what is important is that if a user has the scan ticket permission, he/she should have the scanner in the admin-ui so we don't have to build a scan page for every ticketing customer

[Mikearaya]

@pozylon The issue with admin-ui being shipped with non-global resolvers only becomes apparent when the ticketing package is registered:

• /ticketing routes result in 500 errors
• Codegen and the typing system break
• Gate Control login using a passcode is no longer possible

What I’ve been thinking about and working on is moving the relevant components into the ticketing module itself. These components could then be imported by any project that uses ticketing and injected through the new Admin UI plugin system.

This approach would allow us to keep the ticketing-specific code within the ticketing module and prevent admin-ui from being shipped with dead code by default.

[pozylon]

@Mikearaya yes it's a perfect case to battle-test your admin ui plugin system

[pozylon]

@Mikearaya i merged the ESM plugin PR, please check this PR here

[pozylon]

rebase and build upon the new esm plugin system

[Mikearaya]

@pozylon Rebase, tested and fixed. everything is in place now