Allow updatedAt to be set in create + update data payload

[sebastianmulders]

Context

Currently, updatedAt is always overridden with new Date().toISOString() by traverseFields.ts, preventing it from being explicitly set when creating or updating documents. While this behavior makes sense for most cases, it creates challenges when performing database migrations, where retaining the original updatedAt timestamps is crucial.

My Attempt & Realization

I initially created a PR to modify traverseFields.ts, allowing updatedAt to be explicitly set in the payload while keeping the current default behavior intact if no value is provided. However, after submitting the PR, the test suite failures made me realize that this behavior is intentionally enforced.

Here’s the PR: #11407

Challenges with the Current Behavior

1. Collection Hooks Do Not Work Well for This –
   It seems that traverseFields.ts is always the last thing that runs, meaning there is no opportunity to modify updatedAt within collection hooks. If I'm missing something here, I'd love clarification on whether there's an existing way to handle this within the framework.

2. Direct DB Insertions as a Workaround? –
   Another potential approach would be to perform direct database insertions, bypassing Payload's lifecycle methods entirely. However, this feels like an incomplete solution since it would miss out on other features that Payload and Drizzle ORM provide, such as validation, access control, and hooks.

Discussion: Should This Be Configurable?

Since the current behavior is by design, I’d like to open a discussion on whether it could be reconsidered, or if there’s a way to introduce configurability. Possible approaches:

1. A Field-Level Boolean – A schema-level setting (e.g., allowCustomUpdatedAt: true) to enable explicitly setting updatedAt when needed.
2. A Global Config Option – A PayloadCMS config option that permits overriding updatedAt values when necessary.
3. Alternative Approaches? – Open to hearing any other ideas from the community and maintainers.

Next Steps

Before revising my PR, I’d love to get input from the PayloadCMS team and the community on whether this is a valid use case worth addressing, and if so, what the best approach would be.

Looking forward to your thoughts!

[r1tsuu]

Something like payload.update({ timestamps: false }) and then you'd be able to pass your own both createdAt and updatedAt makes more sense to me. Not sure about versions, it may not work well with them.

[r1tsuu]

I'd maybe do that argument for payload.db.create and payload.db.update initially only as it'd be much simpler, we already have that for MongoDB since you can pass custom Mongoose options which contains timestamps, but it's not typed well.

[sebastianmulders]

That would also work. I actually did manage to get an afterOperation hook working today, the solution was using the current transaction and avoid using the create/update operations that trigger the traverseFields function:

export const preserveRequestUpdatedAtValueHook: CollectionAfterOperationHook<any> = async ({
  req,
  collection,
  operation,
  result,
}) => {
  if (!req.payload.db.sessions || typeof req.transactionID !== 'string') {
    return;
  }

  if ((operation === 'create' || operation === 'update') && req.data?.updatedAt) {
    const transaction = req.payload.db.sessions[req.transactionID];
    const table = req.payload.db.tables[collection.slug];
    const db = transaction.db as PostgresDB;
    let docs = [];

    if (Array.isArray(result.docs)) {
      docs = result.docs;
    } else {
      docs = [result];
    }

    // eslint-disable-next-line @typescript-eslint/ban-ts-comment
    // @ts-expect-error
    for (const doc of docs.filter(doc => Boolean(doc.id))) {
      await db
        .update(table)
        .set({
          updatedAt: req.data.updatedAt,
        })
        .where(eq(table.id, doc.id));

      req.payload.logger.info(
        `preserveRequestUpdatedAtValueHook called for ${collection.slug} with id ${doc.id}, setting updatedAt to ${req.data.updatedAt}`,
      );
    }
  }
};

Can probably still polish a bit further as I did get a mixed result back in different scenario's but seems to be working for now. I suppose there aren't any problems with this - if that's the case, happy to use this during our migration and then later get rid of it.