Use a modified version of this tool: https://github.com/CyberSource/cybersource-rest-samples-python/blob/master/samples/UnifiedCheckout/generate-unified-checkout

To generate the unified checkout capture context, which will be used by the frontend to create the <iframe> object.

Return this on initiating checkout

Tests merged in #624 periodically fail when the invite's expiry time doesn't exactly match the tested expiry time (down to the second). We flagged this in the original PR, but didn't get around to it.

Here's an example of CI failing in this manner.

Importing uuid from "uuid" has been sunsetted. [1, 2]

1: https://stackoverflow.com/questions/60830848/attempted-import-error-uuid-does-not-contain-a-default-export-imported-as-u
2: https://www.npmjs.com/package//uuid#uuidstringifyarr-offset

• Django checks
• Better CI
• Postgres in Docker

Actions cache suffix seems to be broken

Admins can only send acceptance/rejection emails to club applicants once. If an acceptance/rejection email template is initially incorrect and emails are sent, applicants cannot be re-notified.

For reference, the logic for this is implemented in Backend/clubs/views.py under ClubApplicationViewSet's send_emails().

Proposed fix: add an option for admins to force renotification for all applicants. Ideally, this would show up as a checkbox when sending emails, with a warning upon toggle that confirms whether admins mean for applicants to be re-notified.

Use this API with the TTID (transient token id): https://developer.cybersource.com/docs/cybs/en-us/digital-accept-flex/developer/all/rest/digital-accept-flex/da-payments/da-auth-token-task.html

Validate logic after payment success or failure to reclaim state (ticket holds, ticket ownership, confirmation email, etc)

create_tickets currently deletes and recreates tickets / other parameters around the event every time it is called

This could be very problematic if a bought ticket is deleted since the organizer decides to go in and add a few more tickets.

We should:

• Add a parameter to events specifying a ticket_drop_time
• Make tickets publicly available for purchase only after this time
• Freeze ticket offering editing after this time

Hello 👋

I run a security community that finds and fixes vulnerabilities in OSS. A researcher (@deleterepo) has found a potential issue, which I would be eager to share with you.

Could you add a SECURITY.md file with an e-mail address for me to send further details to? GitHub recommends a security policy to ensure issues are responsibly disclosed, and it would help direct researchers in the future.

Looking forward to hearing from you 👍

(cc @huntr-helper)

See this thread. Will revisit after receiving prod credentials.

Enforce max # of tickets that can be checked out at once on a per-event basis

• Add a report to view all tickets sales for specific clubs, date range
• This should default to: all clubs, monthly

Very important for payouts, need to display this at a transaction level?

Reproducible by logging in with a Penn Key and navigating to account settings. I observed this behavior across multiple browsers for my account -- might just be something wrong with with my specific Penn profile? Would love to know if other people are running into the same issue.

Once we have the transient token, after the <iframe> loads in all the card information and related details, we can display a confirmation page.

On this confirmation page, we need to display metadata for the frontend to allow confirmation. Invoke this API: https://developer.cybersource.com/api-reference-assets/index.html#unified-checkout_transient-token-data_get-transient-token-data_liveconsole-tab-request-headers to use this token and return metadata.

Replace multi-event cart functionality with an event-specific ticket purchase / checkout page (aligning with original designs) for simpler UX.

Users first select number of each ticket class for a given event to purchase (and are shown price of current "cart"), then are shown payment details drawer from Cybersource UI library. Upon successful receipt of details and creation of payment, user receives ticket (or a momentary hold), has payment authorized, and is redirected to owned tickets page.

Cart + holds on checkout will be brought back due to UX concerns.

see title

Reproducible by cloning the repo and running ./manage.py test.

as discussed here

Create an interface for WC admins to add/delete club applications (likely a view for them to run the wharton_council_application script?)

• An interface visible to admins of Wharton Council only (using Django permissions)
• Control centralised application start_time, end_time, application_cycle and result_release_time, checkbox of clubs to include, and control over whether these applications are editable (currently, Wharton apps are not editable when submissions are open)
• Changes to applications need to be approved by Wharton Council (includes edits and deletions)

Frontend - Julian
Backend - Rohan Moniz / Avi

• QR codes should be unique to ticket and owner
• QR code scanner integration with mobile for attendance tracking

TicketsTab tasks:

1. Align design with Figma
2. Implement transfer ownership functionality (between PennKeys for now)
3. Group displayed tickets by event and link to relevant /tickets/[event.id] page. Display count of each ticket class by event.

django/channels_redis#332

• Create an index on holding expiration and maybe the event to easily filter tickets
• This will make the update_holds function substantially cheaper

Add indices? One of the problematic queries is search

Unauthorized users can access /admin. Backend check will prevent any actions from being executed, but we would still want to prevent people from accessing this page in the first place.

We currently provide the option of either using:

• Penn Clubs as application submission management system, allowing the user to send acceptance / reject emails through Penn Clubs as well as customizing many more aspects of the application
• Some external provider (Google Form, Airtable, etc.) by providing a link to the application

The application creation form still asks for templates for external providers, we should eliminate the use of templates.

See title. I discovered this when trying to edit a club's application questions -- haven't validated it across other pages that require auth. My hunch is that renderPage.tsx is causing this. L164 implements a wrapper for any page that requires authentication, which queries the backend with an "is the current user == auth" upon any state change. Obviously, this is horrible when a user's inputting text.

Proposed fix: query once upon auth-locked page load and don't do it again?

Currently, the frontend page structure and general design choices put Clubs' directory function first and other features (e.g. events) second, displaying a list of clubs in the homepage. This leads to high usage at the beginning of each semester with heavy drop-offs, as events are underutilized and most users solely use the directory/application features of the website (unfiltered search is also very expensive for something loaded by default, especially during peak application time). Ideally, Clubs should be a 4-year holistic platform for the club ecosystem at Penn, and currently has the features to be one: with the planned rollout of events ticketing, this is a great time to revamp the homepage.

This involves the re-organizing of the current home page (club directory) and /events page into the following:

• Homepage for unauthed users: Standard landing page with login call-to-action and potentially some marketing print.

• Homepage for authed users: Social media-style feed featuring 1. events/content from subscribed/bookmarked clubs and 2. upcoming events, potentially ranked by relevance to user and/or popularity.

• Events page: current events page, full directory for all events at Penn with search functionality.

• Clubs page: current homepage. Would have its own header link. Should probably put a banner on homepage that leads to this at the start of each semester ideally.

EDIT: Homepage for authed users will now be more differentiated from events page. Will have

1. Google.com-like search bar with autocomplete based on club title (redirects to club search page with relevant query param on enter)
2. Featured events (some selection where upcoming events from bookmarked/subscribed clubs are at top followed by other popular events on campus)
3. Featured club (optional, could be cool to showcase some clubs, especially less pre-professional ones, could be themed for certain holidays as well)

in the view initiate_checkout, we exit early if cart total is 0.

Let's instead make it check individual tickets: all(t.price == 0 for t in cart.tickets.all()) and then simply "sell the tickets" to the person and then exit.

This also should be accompanied with a refactor. We have "sell the tickets" logic in complete_checkout. Move this to a separate helper function so that both the free ticket purchase path and paid ticket purchase path can use this shared function.

We also need one more refactor: the response returned should indicate that the tickets have been sold and the frontend doesn't need to call complete_checkout. This will require changing the response schema.

Bump node version to 18 and Next.js version to 13 (latest)

Allow clubs to define pricing tiers based on number of tickets bought (e.g. group buys) in ticket creation process.

Pesky edge cases