How QCMM Measures Meeting Attendance and Participation

Explain presence pings, cumulative Host-plus-admitted-attendee overlap, the configurable participation threshold, and why lobby/pre-join time does not count as completed participation.

This guide follows the accepted QC Memberships & Meetings 2.0.21 implementation and applies to Max / All Access; administrator and Host. This category covers the native QCMM Meeting Room, Host/customer entry, lobby and participant controls, authoritative Host End, attendance overlap intelligence, and calendar integration. When older walkthrough or project-manual wording conflicts with 2.0.21 source or later accepted Authorized-Domain behavior, the current implementation takes precedence.

Before You Begin

• Confirm the booking is valid and Scheduling/Meeting Room entitlement is active before troubleshooting media or room access.
• Use a supported modern browser over HTTPS and grant camera/microphone permissions only to the device/browser profile used for the test.
• Test with separate Host and customer accounts; room roles and timing are deliberately different.

Current QCMM Behavior

Step-by-Step Workflow

1. Open the exact booking from Host Schedule or the customer schedule and verify its Meeting Time and status.
2. Enter through the Start/Join action during the allowed timing window so QCMM can issue role-specific short-lived authorization.
3. Test the relevant lobby, admit, participant, media, or Host control with separate Host/customer sessions.
4. End or leave the session according to the scenario being tested and allow attendance presence to finalize.
5. Verify booking completion, attendance overlap/history, and re-entry behavior from both Host and customer views.

How QCMM Measures Meeting Attendance and Participation

Explain presence pings, cumulative Host-plus-admitted-attendee overlap, the configurable participation threshold, and why lobby/pre-join time does not count as completed participation is part of the current QCMM 2.0.21 behavior. Treat the stored QCMM record and server-side authorization as authoritative: frontend controls guide the user, but QCMM still validates identity, ownership/access, current object state, entitlement, and request integrity when an action is submitted.

Scheduling and Meeting workflows are stateful and time-sensitive. Distinguish Plan eligibility, Host availability, Meeting Time capacity, the customer booking, room/session state, and attendance history; they are related, but none is a substitute for the others.

Current Details That Matter

• Scheduling is Max/All Access and includes customer conflict protection, booked-capacity safety, rescheduling, No Show handling, optional courtesy replacement, reminders, and calendar integration.
• Existing purchased appointments and their history are preserved if the installation later drops below Max.
• Native Meeting Room is Max/All Access, uses managed short-lived credentials, and re-authorizes the booking/role server-side.
• Authoritative Host End marks the Meeting complete immediately; attendance uses participant presence/overlap intelligence.

How This Fits into QC Memberships & Meetings

This category covers the native QCMM Meeting Room, Host/customer entry, lobby and participant controls, authoritative Host End, attendance overlap intelligence, and calendar integration. A reliable QCMM configuration keeps Joomla authoritative for users, groups, access levels, sessions, mail transport, and Scheduled Tasks while QCMM owns Plan, subscription, billing, scheduling, Meeting, Custom Field, resource, and member-facing state.

For How QCMM Measures Meeting Attendance and Participation, verify the behavior with the role that will actually use it. Administrator, member, Host, and Fulfillment Editor experiences intentionally differ. A successful test as Super User does not prove that a normal user has the correct ownership, access, timing, or feature entitlement.

Permissions, Entitlement, and Data Safety

• Joomla menu access, QCMM object ownership/access, role-specific permissions, and commercial feature entitlement are separate checks.
• QCMM re-authorizes state-changing requests server-side; never treat a visible or hidden frontend control as the security boundary.
• Do not expose PayPal credentials, encrypted settings, legacy keys, private room credentials, or other secrets in screenshots, URLs, public documentation, or community posts.
• Preserve subscription, billing, booking, attendance, Custom Field, credit, and entitlement history when correcting a problem; current QCMM is designed to repair in place rather than erase evidence.
• When Effective tier falls, premium configuration/history is preservation-first: features can become unavailable without deleting the saved data.

Verify the Result

• Host Start and customer Join follow the intended timing and booking authorization rules.
• Browser/device permissions are the only local media permissions required; permanent provider credentials are never exposed to customers.
• Host End immediately produces the accepted Completed state and prevents room re-entry.
• Attendance reflects actual overlap/presence information and not merely the existence of a booking.

Common Mistakes to Avoid

• Sharing internal realtime-provider credentials or treating the private QuantaCade operations runbook as customer configuration.
• Diagnosing camera/microphone permission denial as an entitlement error.
• Assuming scheduled end alone is identical to authoritative Host End while an overtime room remains active.
• Using a Super User browser session to validate normal customer room authorization.

Troubleshooting

• Check Plan/Host assignment, availability, notice window, capacity/holds, customer conflicts, and current booking state in that order.
• Confirm the site/user time-zone context before treating a displayed time difference as a stored-data error.
• Separate booking authorization and timing from browser media permissions and realtime-provider connectivity.
• When attendance looks wrong, compare participant join/leave overlap and authoritative Host End state rather than assuming a booked attendee was present.
• Reproduce the exact action with the smallest safe test and record the user role, Plan/subscription/booking/billing identifiers, current state, and time zone where relevant.
• If a control is missing, check Joomla access, QCMM permission/ownership, record state, Effective tier, and task health before assuming packaged files are damaged.
• If behavior is asynchronous, inspect the owning Scheduled Task and its last result instead of repeatedly performing the business action.

Operational Best Practice

Test Meeting Room behavior end-to-end on the browsers/devices your Hosts and customers actually use. Keep room credentials short-lived and managed, use Host End deliberately, and treat attendance as evidence derived from presence overlap rather than a manually guessed status.

Community Discussion

Want to compare membership or Meeting workflows, share practical QCMM tips, or discuss how other Joomla site owners use this feature? Visit the QC Memberships & Meetings Community. For private support, bug reports, account-specific entitlement or billing problems, or feature requests, use the QuantaCade support system.