Opt-in to cross tenant relationships on a per-field basis when using the multi-tenant plugin

[evelynhathaway]

Summary

It would be beneficial for some multi-tenant applications to selectively allow relationships to cross the tenant boundary, especially for linking.

Background

The multi tenant plugin does a great job of separating documents by tenant, but it doesn't allow for selectively bridging between tenants in relationships since the plugin's filterOptions is added unconditionally:

payload/packages/plugin-multi-tenant/src/utilities/addFilterOptionsToFields.ts

Line 123 in 6c4dfe4

field.filterOptions = async (args) => {

However, the filters on the tenants, users, and each multi-tenant collection list view can already be toggled off, and serve as a good model for how the relationship filters can be disabled:

payload/packages/plugin-multi-tenant/README.md

Lines 38 to 43 in 6c4dfe4

	/**
	* Set to `false` if you want to manually apply the baseListFilter
	*
	* @default true
	*/
	useBaseListFilter?: boolean

payload/packages/plugin-multi-tenant/README.md

Lines 153 to 160 in 6c4dfe4

	/**
	* Opt out including the baseListFilter to filter tenants by selected tenant
	*/
	useTenantsListFilter?: boolean
	/**
	* Opt out including the baseListFilter to filter users by selected tenant
	*/
	useUsersTenantFilter?: boolean

Request

While I am not attached to the syntax, it would be nice to have granular control of relationship filters like the below.

const documentField = {
	name: "doc",
	label: "Document",
	type: "relationship",
	required: true,
	relationTo: ["pages", "posts"],
	custom: {
		// Opt out of filtering options by tenant, either allowing all options (no `filterOptions`),
		// or leaving the tenant filtering up to the developer (custom `filterOptions` only)
		useTenantFilter: false,

		// Default (`true` or `undefined`) to filtering options by tenant, extending the custom
		// `filterOptions` if present, just like the current behavior
		// useTenantFilter: true,
	},
} satisfies RelationshipField;

Similar to the underlying request from #10983

"Relation fields are not using base list filter and can't be overwritten"
but with a use case that I'd argue isn't well met by a straightforward refactor of our use of tenants.

Use Case

If implemented, most of the relationships in my instance would take advantage of the current behavior as the default. The safety from the separation being the remaining the default is desired, just like baseListFilter. I think that makes sense for most cases, and is of course critical for fields like the parent relationship from the nested documents plugin.

The relationships fields that I would opt out in my instance would be links (rich text, button blocks, navigation items) and redirect destinations. My instance would be able to support the access controls required to accomodate this, and I am not advocating for the plugin to provide access controls for cross-tenant relationships as I believe it would be too much of a implementation-specific niche for the plugin to handle itself.

Advantages for My Use Case

• Cross-tenant internal links would stay up-to-date, in contrast to restorting to custom URLs when linking cross-tenant
• Pages and posts (multi-tenant collections) can be moved to another tenant by a super admin and their links will still work without breaking any expectations that the Payload CMS UI has.
  • Our frontend already has to handle cross-tenant linking to support this case even with the filter, so we might as well make linking cross tenant an option to our admins.
• Links to cross-tenant pages can keep the context stored in Payload CMS
  • We actively are using this to dynamically convert links to legal pages into modals when when in kiosk mode. This prevents the kiosk mode for an application in one tenant to use the synced version of the Terms of Use page without adding a method of escaping the kiosk or an loading an iframe that can be navigated around the tenant that holds the Terms of Use page document.

[evelynhathaway]

Adding a condition to the multi tenant filterOptions mutation can solve this with a simple one line pnpm patch for relationships that use the dropdown:

/patches/@payloadcms__plugin-multi-tenant.patch

diff --git a/dist/utilities/addFilterOptionsToFields.js b/dist/utilities/addFilterOptionsToFields.js
index 72e0cd45632fc2b2387694d6de3eb2840d3f50cd..fc576c979e9998e410993c770ca6f9698b120a70 100644
--- a/dist/utilities/addFilterOptionsToFields.js
+++ b/dist/utilities/addFilterOptionsToFields.js
@@ -85,6 +85,11 @@ export function addFilterOptionsToFields({ config, fields, tenantEnabledCollecti
     });
 }
 function addFilter({ field, tenantEnabledCollectionSlugs, tenantFieldName, tenantsArrayFieldName = defaults.tenantsArrayFieldName, tenantsArrayTenantFieldName = defaults.tenantsArrayTenantFieldName, tenantsCollectionSlug }) {
+	// TODO: Remove if a option is added in a new version of the plugin
+	// Skip filtering by tenant on a per-relationship field basis
+	// - Defaults to filtering, overridden only by `false`
+	// - See: https://github.com/payloadcms/payload/discussions/12872
+	if (field.custom?.useTenantFilter === false) return;
     // User specified filter
     const originalFilter = field.filterOptions;
     field.filterOptions = async (args)=>{

But relationship drawers will still apply the tenant baseListFilter, which doesn't appear to have enough context to disable conditionally (e.g. apply base list filter to lists except when in that specific relationship drawer) even with a small amount of patching.

A core change would be appreciated since a workaround isn't possible.