Create Plan Group-Specific QCMM Catalog Menu Items

Configure a Plans menu item to show all published Plan Groups or only selected groups, enabling separate catalogs for different membership families without cloning Plans.

This guide follows the accepted QC Memberships & Meetings 2.0.21 implementation and applies to All plans; administrator. This category covers the membership catalog model: Plan Groups, Plans, publication, Joomla access assignment, customer-visible choices, and controlled paths between Plans. 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

• Decide which membership products are genuinely distinct Plans and which are better represented as durations, prices, or change paths.
• Identify the Joomla groups that should be granted by each Plan and confirm those groups do not accidentally grant unrelated administrative authority.
• Check current publication limits before publishing additional Plan Groups or Plans on Basic or Pro.

Current QCMM Behavior

Step-by-Step Workflow

1. Open Joomla Menus and choose the site menu that should expose QCMM.
2. Create the supported QCMM menu type needed for Plans, Dashboard/Member Area, Host Schedule, or Field Fulfillment.
3. Set the Joomla access level to match the intended audience and publish the item.
4. Log in as the intended non-administrator role and open the route from the menu.
5. Keep Checkout and Meeting Room as workflow destinations reached from their owning Plan/booking rather than generic public landing pages.

Plan Group-Specific QCMM Catalog Menu Items

Configure a Plans menu item to show all published Plan Groups or only selected groups, enabling separate catalogs for different membership families without cloning Plans 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.

Keep the distinction between a reusable Plan definition and a purchased subscription snapshot. Administrators can improve or retire future catalog offers without rewriting the commercial and access context that belongs to an existing membership unless a dedicated migration/change workflow intentionally does so.

Current Details That Matter

• Publication limits are Basic 1 Plan Group/3 Plans, Pro 2/6, and Max/All Access unlimited; saved higher-tier configuration is preserved through downgrade.

How This Fits into QC Memberships & Meetings

This category covers the membership catalog model: Plan Groups, Plans, publication, Joomla access assignment, customer-visible choices, and controlled paths between Plans. 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 Create Plan Group-Specific QCMM Catalog Menu Items, 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

• The Plan appears in the intended Plan Group and published catalog order.
• Plan Detail shows the expected price, duration, description, customer choices, and purchase/change actions.
• A test subscription receives only the intended Joomla groups and Plan-specific capabilities.
• Downgrade or temporary entitlement loss does not delete saved higher-tier Plan configuration.

Common Mistakes to Avoid

• Treating a hidden menu item as an access-control substitute for QCMM/Joomla authorization.
• Publishing more Plans or Plan Groups than the current tier permits and assuming saved data should be deleted.
• Changing a live Plan without considering existing subscription snapshots and historical billing context.
• Creating broad Plan-change paths that let customers move between offers that were not designed to be interchangeable.

Troubleshooting

• Reproduce the exact action with the same user role and record identifiers before changing unrelated configuration.
• If the UI and stored state disagree, refresh the real frontend after checking the owning record and relevant Scheduled Task.
• 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.
• After a correction, rerun the same scenario from the real frontend; a successful Administrator save alone is not end-to-end verification.

Operational Best Practice

Keep the catalog understandable. Prefer a small number of clearly differentiated Plans, assign only the Joomla groups each Plan truly needs, and make customer change paths explicit. Before changing a live Plan, consider existing subscriptions, renewal behavior, and historical billing snapshots.

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.