Invalid schema usage after revert of field localisation

[flaming-codes]

Bug Report

When creating an entity with localization: true, then changing the schema to localization: false, the stored entity becomes unusable. The locales are still stored and viewing/editing the entity becomes impossible, as now the value is a set of keys, which React can't render as children.

Expected Behavior

The default locale field value is picked for the new schema. Entities stay usable after disabling localisation for fields of saved entries.

Current Behavior

Entities become unusable after

• storing field value in multiple locales
• disabling localisation for the field
• starting the CMS again and viewing the entity

Possible Solution

Default locale value gets picked in restoration process.

Steps to Reproduce

I created a repo for quick testing. All instructions are included the in the README.md.

https://github.com/flaming-codes/payload-cms-localization-collection-issue

Detailed Description

Description	Image
	valid after initial save in multiple locales
	invalid, locales still present after entity is not localised anymore

[flaming-codes]

A naive thought after going through the Payload codebase for some minutes: Maybe this statement lacks the context to determine that only the default locale should be selected

• if multiple locales are used and
• if no localisation is used now

[jmikrut]

Hey @flaming-codes — thanks for the issue. This is actually probably something that should be taken care of with a migration script, which can be written and run specific to your database. I don't think that Payload should maintain any functionality to be able to determine if a field's data was once localized, but is now not, because that would add some pretty abstract and hard-to-follow logic. And it would be unprecedented.

An extreme analog of this would be to say something like - if I have a text field, but I change it to an array field, Payload should know that I changed the field and should try to safely adapt the data. I think this is where a migration script would be better served, personally.

Here is an example for how to do a migration script:

const payload = require('payload');

require('dotenv').config();

const { PAYLOAD_SECRET_KEY, MONGO_URL } = process.env;

payload.init({
  secret: PAYLOAD_SECRET_KEY,
  mongoURL: MONGO_URL,
  local: true,
});

const migrateStatus = async () => {
  const args = process.argv.slice(2); // nodejs command line args are an array that begin at the third item
  const [
    collectionSlug,
  ] = args || [];

  const docs = await payload.find({
    collection: collectionSlug,
    depth: 0,
    limit: 700,
  });

  await Promise.all(docs.docs.map(async (doc) => {
    try {
      await payload.update({
        collection: collectionSlug,
        id: doc.id,
        data: {
          ...doc,
          _status: doc.status || 'draft',
        },
      })

      console.log(`Success! Doc with slug: '${doc.slug}' in collection: '${collectionSlug}' successfully migrated its '${doc.status}' status.`);
    } catch (err) {
      console.error(`Failed. Doc with slug: '${doc.slug}' in '${collectionSlug}' failed to migrate its '${doc.status}' status.`);
      console.error(err);
    }
  }));

  console.log('Complete');
  process.exit(0);
};

migrateStatus();

In the above script, we are migrating old (pre-Drafts) collections from relying on a custom doc.status field to the new and internally supported doc._status field which works with Versions and Drafts. But the principle is the same. Find existing docs, update each one to the new data shape. This can be done with Payload operations and can also be done straight with Mongoose raw documents by accessing the internal Mongoose models via payload.collections[collectionSlug].Model.

What do you think? I'm going to convert this to a discussion for now, but I'd like to keep this conversation going!