← Back to Gatherings

4.6.2 Gathering Staff Management

GatheringStaff records the people responsible for a gathering. A staff entry may reference a KMP member or hold permitted non-member contact details, and its role can identify stewards or supporting staff.

Ownership

• GatheringStaffTable and GatheringStaff define persistence and validation.
• GatheringStaffController handles add, edit, delete, and member-contact lookup requests.
• Gathering policies determine whether the current identity may manage staff. Steward-specific gathering permissions are policy rules, not template checks.
• GatheringCloneService::cloneStaff() copies appropriate staff records during an event clone.

Implementation rules

• Authorize the parent gathering and the staff mutation.
• Load the gathering and member through the active tenant connection.
• Prefer a member association when the person has an account; store only the non-member contact data the workflow needs.
• Treat contact lookup as sensitive data and authorize it before returning JSON.
• Preserve footprint/audit fields and use table saves rather than direct SQL.
• Do not grant tenant-wide event management merely because a member is staff on one gathering.

Accessible UI

Staff forms need explicit labels, programmatic required/error state, keyboard-operable member lookup, and an announced result when contact data is filled asynchronously. The list must expose role and steward state in text, not only with an icon or color.

Testing

Cover a branch-authorized manager, a steward acting on their own gathering, a denied unrelated member, member and non-member staff entries, contact-data restrictions, delete behavior, and cloning. Include a tenant isolation case for API/lookup endpoints.