Multi-Tenant Globals

[IAmNatch]

The Problem

Globals operate as singletons within a single table on the DB, and a single config page for each global within the admin. This works great for single tenant websites, but is tricky to scale into multi-tenant applications.

Since payload advertises (and follows through exceptionally!) as a CMS with strong multi-tenancy capabilities I'm wondering if there are any plans to extend the globals api to include an officially supported multi-tenant globals workflow?

Possible implementation

One way to approach this could be a access control style resolver method which allows developers to provide their own segmentation criteria via either an async function, a boolean, or a Where query. This would leave the developer free to segment globals by any field they wish, and based on whichever criteria they prefer.

Example

  ...
  selectScopedGlobal: {
       "tenant.domains.domain": {
          equals: getTenantFromHeaders(headersList),
       },
  }
  ...

[matthijs166]

I think you can achive this already without needing this feature.

I would do it like this:

1. Create a globals collection with the same sturcture as your global
2. Add a field to this collection for the scope (your domain for example)
3. Add in the global a new hook beforeChange
4. In this hook store the values via the internal payload api to the globals collection (with scope)
5. Add a new hook beforeRead or afterRead
6. Fetch based on the scope the value from the globals collection and return the data within this hook

If you got it working I would love to see a demo!

You can also have a look to this plugin (https://github.com/joas8211/payload-tenancy)

[matthijs166]

@IAmNatch You can hide the globals collection (to use it as an internal collection) and still use the singleton focused UI. When a user opens the global the afterRead hook is triggered. In this hook you fetch the correct data for that user based on the scope. (works also in the API output). Now the global is filled with the correct data. The moment the user saves the singleton global the beforeChange hook is triggered where you store the data to the globals collection.

Bonus is that you can now have super admins who can look into all the globals. (maybe by a checkbox on the user)

My solution is not hard to implement and would achieve the same results with some nice extra bonus.

[IAmNatch]

Thanks for the explanation, I think I'm following. Diving deeper into the process, these are the steps I'll try out:

1. Make a global representing my data, which is purely for presentational purposes. (ex. SiteConfigGlobal)
2. Make a collection which is the "behind the scenes" data source for my global, with hidden: true, except for super admins. (ex. SiteConfigGlobalCollection`) The fields are 1:1 with the global.
3. Add a beforeChange hook to the global (not the collection) which updates the related collection instead of the global.
4. Add a afterRead hook to the global which fetches the related collection instead of the global itself.

This in theory should maintain the singleton UI and validation, while allowing easy super-admin access, and not requiring any changes to payload itself. While it does feel a bit hacky, it should get the job done. The admin will still have to pull two records (the global and the collection), but API calls can at least call the collection directly.

My one question right now is how I might avoid writing to the global in step 3. I suppose it's fine to overwrite the unused global each time and have that little bit of data duplication.

Once I achieve this I'll report back here with my results, and consider a PR into the multi-tenant-plugin if I have some free time.

[IAmNatch]

Thanks for the help, @matthijs166, this totally worked. I appreciate your patience walking me through the steps.

Here's the generic utility I landed on after testing your approach:

const createMultiTenantGlobal = (
  config: GlobalConfig
): [GlobalConfig, CollectionConfig] => {
  const fields = config.fields;
  // type assertion is required since we'll be writing `payload.find|create|update` and a valid collection name is required`
  const collectionName =
    `${config.slug}-multi-tenant-collection` as keyof Required<
      Config["collections"]
    >;

  const global: GlobalConfig = {
    ...config,
    hooks: {
      beforeChange: [
        async ({ req, data }) => {
          const tenant: Tenant = req?.user?.lastLoggedInTenant;

          const existing = (
            await req.payload.find({
              collection: collectionName,
              where: {
                tenant: { equals: tenant.id },
              },
            })
          ).docs;

          if (existing[0]) {
            await req.payload.update({
              collection: collectionName,
              id: existing[0].id,
              data: {
                ...data,
                tenant: tenant.id,
                // We want the collection to create its own ID, and to exclude the `globalType` field
                id: undefined,
                globalType: undefined,
              },
            });
          } else {
            await req.payload.create({
              collection: collectionName,
              data: {
                ...data,
                tenant: tenant.id,
                id: undefined,
                globalType: undefined,
              },
            });
          }

          return data;
        },
      ...(config.hooks?.beforeChange || []),
      ],
      beforeRead: [
        async ({ req }) => {
          const tenant = req?.user?.currentTenant;

          const globalMultiTenantCollection = await req.payload.find({
            collection: collectionName,
            // The admin expects to fetch its own relationships, so we must force depth to 0,
            depth: 0,
            where: {
              tenant: { equals: tenant.id },
            },
          });

          if (globalMultiTenantCollection.docs[0]) {
            return globalMultiTenantCollection.docs[0];
          } else {
            return {};
          }
        },
       ...(config.hooks?.beforeRead || []),
      ],
    },
  };

  const collection: CollectionConfig = {
    ...config,
    slug: collectionName,
    graphQL: {},
    admin: {
      ...config.admin,
      // in my case, I don't even want to show this collection to admins, since they are able to cycle between 
     //impersonating each relationship via the `currentTenant` field on their user profiles. 
      hidden: true,
    },
     // hooks should be passed to the global, not the collection, since the global is the main interface. 
    hooks: {},
    // custom tenant field is passed here to manage ownership of collections. 
    fields: [...fields, tenant],
  };

  return [global, collection];
};

And here's an example of its usage

export const [NavGlobal, NavGlobalMultiTenantCollection] =
  createMultiTenantGlobalConfig({
    slug: "nav",
    admin: {
      group: "Site Config",
    },
    fields: [
      {
        name: "items",
        type: "array",
        required: true,
        maxRows: 4,
        minRows: 4,
        fields: [
          {
            name: "page",
            type: "relationship",
            relationTo: ["pages", "post-category"],
            required: true,
          },
        ],
      },
    ],
  });

[matthijs166]

This looks very clean! Good job! And no worries, you can pay it forward ;)

[vladvlasov256]

Access rights for a global multitenant collection gave me hard times today. A workaround for createMultiTenantGlobalConfig() was the opposite of what @IAmNatch did with hooks. So instead of passing access settings to the global, I used them in a regular collection.

All other stuff worked great, btw!

[matthijs166]

@IAmNatch I see that it is now included by default in the plugin https://github.com/joas8211/payload-tenancy#globals 🕺

[IAmNatch]

Nice! The commit looks really great. I'm sure this will really help a lot of developers!