Lifecycle Functions Overview

INFO

The following table shows only collection types which have a lifecycle and the lifecycle types which are implemented

Collection	Trigger	Functionality
Alternative Directions	beforeCreate	Set location_name to the runsite_name of the related location
Applicants	afterCreate	Lifecycle event triggered after creating an applicant record. Sends notification emails based on the applicant's publication status. For draft applicants: - Sends an email to the OnSec with a link to the applicant's admin page. - Sends an email to the applicant with their image link. For published applicants: - Copies applicant data to the member collection. - Intended to delete the applicant record after processing, but currently left intact.
Cards	beforeCreate	Assigns a random UUID to card_uid and validates the card before creation. For member cards: checks the member is active and has no existing active card. For guest cards: auto-assigns the next guest_number if not set.
	afterCreate	Fires only for member cards when CARD_EMAILS_ENABLED=true. Generates the member card image and Google Wallet URL, then sends the card email via email-designer-5. Runs in setImmediate so the HTTP response is not blocked.
Cash Expenses	beforeCreate	Before creating a new cash expense entry, this method checks: - For a Free text item you MUST enter item Content - If the amount spent is greater than 0, it multiplies it by -1 - If the amount spent is 0 or not provided, throws an error Throws an error if the checks fail.
Drink Redemption	beforeCreate	Validates the card is active; for member cards also checks the member is signed in for the run.
Event Banner	beforeCreate	Before creating an event banner, check that the start date is before the end date and that there isn't already an event banner for the same period. Throws an application error if either of these checks fail
	beforeUpdate	It ensures that the start date is before the end date and checks for any existing event banners that overlap with the new dates, excluding the current entry. Throws an error if the date validation fails or if there is an overlapping event banner.
Guests	beforeCreate	Lifecycle event triggered before creating a guest record. - Retrieves all guests not marked as archived to check for duplicates. - If the contact number does not start with '+00', it performs a duplicate check: - Normalizes the mobile number to a 10-digit format. - Ensures the mobile number has at least 8 digits, excluding spaces and '+'. - Checks for existing guests with the same normalized mobile number. - Throws an ApplicationError if the mobile number is too short or if a duplicate is found.
Guests Sign-in	beforeCreate	It checks whether a guest is already signed in for a specific run to prevent duplicate entries. If an entry already exists for the given guest and run, it throws an ApplicationError.
	afterCreate	It creates a new guest record with the payment information.
	beforeDelete	It retrieves the associated guest and run details and stores the entity state for use in subsequent lifecycle events.
	afterDelete	It removes the associated guest record from the guest records collection.
	afterUpdate	It updates the corresponding guest record in the guest records collection with the new payment amount and type.
Guestrecords	afterCreate	It updates the last_run_date of the guest to the most recent run date. It does this by finding all the runs of the guest, sorting them in descending order, and taking the first run date as the most recent. If no runs are found, it sets the last_run_date to null.
	beforeDelete	It retrieves the associated guest details and stores the entity state for use in subsequent lifecycle events.
	afterDelete	It updates the last_run_date of the guest to the most recent run date after the deletion. This is done by finding all remaining guest records, sorting them by run date in descending order, and taking the most recent date. If no records are found, it sets the last_run_date to null.
Locations	beforeCreate	It checks whether there is already a location within approximately 500 meters. If such a location exists and the force_creation flag is not set, an ApplicationError is thrown.
	beforeUpdate	It updates the geo-coordinates and navigation links accordingly.
Members	beforeCreate	It validates waist size input, checks for duplicate members based on date of birth, assigns a new member_id if none was provided, and sets default values for joined_date and alias if not provided.
	afterCreate	Creates a member card for the new member, unless the member is inactive (e.g. during data migration of already-resigned members).
	beforeUpdate	It validates waist size input and automatically updates the resigned_date and rejoined_date fields when the active status of the member is changed.
	afterUpdate	Synchronizes the member's card with their active status: - If the member is set inactive (resigned), their active card is inactivated. - If the member is set active again (rejoined), a fresh card is created; the previous card remains inactive for historical reference. No action is taken if the active status was not part of the update.
Members Sign-in	beforeCreate	It checks whether a member is already signed in for a specific run to prevent duplicate entries. If an entry already exists for the given member and run, it throws an ApplicationError.
	afterCreate	It creates a corresponding run record for the member and run associated with the sign-in.
	beforeDelete	It retrieves the associated member and run details and stores the entity state for use in subsequent lifecycle events.
	afterDelete	It deletes the associated run record from the run records collection.
Onsite Sales	beforeCreate	Before creating a new onsite sale entry, this method checks: - Either Guest or Member must be present - An entry can only be for a Member OR a Guest - Sales item must be present - Sales item must be valid - Members can only buy a subscription if it is of the same type as the member - Payment type defaults to Cash if not provided - Total amount spent is calculated as the item price multiplied by the quantity Throws an error if the checks fail.
Hareline	beforeCreate	It ensures that the run number and date are assigned if not provided, by incrementing from the last run's details. Additionally, it validates whether the assigned hare is permitted to set runs based on their active status and exemption flag. Throws an error if the hare is not allowed.
	beforeUpdate	It checks whether the assigned hare is permitted to set runs based on their active status and exemption flag. Throws an error if the hare is not allowed.
	afterCreate	It fetches the run summary and updates the run record with the summary.
	afterUpdate	It fetches the updated run summary and compares it with the existing summary. If there is a difference, it updates the run record with the new summary. Handles errors during the process by logging them.
Runrecords	beforeCreate	It fetches the alias of the associated member and the summary of the associated run, and adds them to the entry.
	afterCreate	It updates the actualRuns field of the associated member with the new value.
	beforeDelete	It updates the actualRuns field of the associated member with the decremented value. This is done because afterDelete doesn't work here, as the record is already gone.
	beforeUpdate	It throws an error because run records should not be updated. Instead, the existing record should be deleted and a new record created.
Sales Items	beforeUpdate	It checks for any changes in the entry's fields and ensures that updates to certain fields like 'item_price', 'item_type', and 'item_subtype' are not allowed. If these fields are attempted to be updated, an error is thrown indicating that these fields cannot be modified and a new item should be created instead.