Allow perTenant collections to have relationship fields pointing to isGlobal collections

[etaaaaaaa]

Problem Description

When using the @payloadcms/plugin-multi-tenant plugin with a combination of isGlobal and tenant-scoped (perTenant) collections, the plugin throws an error if a perTenant collection contains a relationship field that references an isGlobal collection:

Error: The collection homepage is a global collection and cannot be related to a tenant enabled collection.

Use Case

We have a multi-tenant website builder where:

1. isGlobal collections (one record per tenant): "Homepage", "FAQ", "Services", "Contact", etc. - these are singleton pages that each tenant has exactly one of.
2. perTenant collection: "Pages" - a flexible collection where tenants can create unlimited custom pages.
3. Link fields: Both isGlobal and perTenant collections need link fields that allow editors to create internal links to ANY page type (polymorphic relationship).

The problem: When the "Pages" collection (perTenant) contains a link field with relationTo: ["homepage", "faq", "services", "pages"], the plugin throws an error because "homepage", "faq", and "services" are isGlobal collections. See lines 46-48 and 56-58.

Why This Restriction Seems Unnecessary

What's happening:

• isGlobal = one document per tenant (e.g., each tenant has exactly one "Homepage")
• perTenant = many documents per tenant (e.g., each tenant can create many "Pages")

What we want:

A "Page" should be able to link to the "Homepage" and visa versa (both belong to the same tenant).

The current code blocks this for no clear reason. Both document types are tenant-scoped, just with different cardinality (one vs many). The relationship is within the same tenant.

Proposed Solution

Simply remove or disable the throw new Error() statements in addFilterOptionsToFields.ts that block this relationship type:

if (typeof newField.relationTo === 'string') {
                /*if (tenantEnabledGlobalSlugs.includes(newField.relationTo)) {
                    throw new Error(`The collection ${newField.relationTo} is a global collection and cannot be related to a tenant enabled collection.`);
                }*/
                if (tenantEnabledCollectionSlugs.includes(newField.relationTo)) {
                    newField = addFilter({
                        field: newField,
                        tenantEnabledCollectionSlugs,
                        tenantFieldName,
                        tenantsArrayFieldName,
                        tenantsArrayTenantFieldName,
                        tenantsCollectionSlug,
                        userHasAccessToAllTenants
                    });
                }
            } else {
                for (const relationTo of newField.relationTo){
                    /*if (tenantEnabledGlobalSlugs.includes(relationTo)) {
                        throw new Error(`The collection ${relationTo} is a global collection and cannot be related to a tenant enabled collection.`);
                    }*/
                    if (tenantEnabledCollectionSlugs.includes(relationTo)) {
                        newField = addFilter({
                            field: newField,
                            tenantEnabledCollectionSlugs,
                            tenantFieldName,
                            tenantsArrayFieldName,
                            tenantsArrayTenantFieldName,
                            tenantsCollectionSlug,
                            userHasAccessToAllTenants
                        });
                    }
                }
            }

This works locally and causes no visible issues right away. Relationship is able to be established successfully.

Questions

1. What was the original reasoning for blocking this relationship direction?
2. Would you consider removing this restriction or making it configurable? I would gladly add a pr, if this truly breaks nothing
3. Is there a recommended alternative architecture for this use case?

Environment
@payloadcms/plugin-multi-tenant: ^3.68.3
payload: ^3.68.3