Custom Edit modal on create from a document with doc data (for Relationship fields)

[rubnvp]

Hi,

We are seeking for the ability to access the parent document and the triggering field when a modal is opened, allowing us to autocomplete specific fields based on the relevant document or field during creation.

At present, when developing a custom component for the Edit component, we receive certain props (such as id, internalState, collection, etc.) that can be modified, but there is no context indicating where this Edit component was invoked.

Ideally, we propose the introduction of Collection (or Field) Hooks, perhaps named beforeCreate and beforeEdit, which would provide these props along with additional context indicating the origin of the modal trigger. This could resemble the functionality of beforeValidate.

Some related issues that I found on the Discord server:

• How to access data from the opened object (Edit view, custom tab component)
• Two Way Relationships? And Passing Data Between Page and Modal in the Request Context
• Autopopulate id in modal when opening from admin page

[patricsgamma]

Description & Example

Such a feature would be helpful to us, this to keep certain values between related objects in sync.

We have multiple document types that have the same data format.
Therefore we separate them by a type field, instead of having multiple collections with the same data model.
We assign these documents to parent docuement fields based on the type. Some assignments are valid some are not.

We can always validate values on the backend with hooks on the parent, but its really not ideal to push all responsibility for data consistency fully to the user and just reject his saves until it fits.

Solution Proposition

As @rubnvp wrote I'd see it as helpful if we had 2 admin hooks so we could prepopulate certain values in a new Modal window.

Proposed hook example.

admin: {
    hooks: {
      beforeDuplicate: ({ data }) => {
        return {...data, id : 'new'}; 
    },
      beforeCreate: ({ parentData, parentCollection, parentField }) => {
        return {
          type = parentField.name;
        }
      },
      beforeUpdate: ({ data, parentData, parentCollectio, parentField }) => {
        return {
          ...data,
          type = parentField.name;
        }
      },
    },
  },

This could be achieved by what he described adding a context to the functionality that is opening a modal window.
This context would get populated for modal windows opened from Edit or Create out of a relationship or upload field.

Create ➕

Edit ✏️

This context is them passed to the modal window.

If the modal window finds a admin.hooks.beforeCreate or admin.hooks.beforeUpdate function.
It will get called and the returned data object is used to populate the modal window with context aware data.

If someone needs even more configuration, then collection config shaping the modal window can also contain special field types that could react with field functionality to such a provided parent context.

But implementing the creation and passing of such a context object to a modal windows appears safer and cleaner to me, if implemented as part of payload, instead of implemented purely with custom fields on all sides.

Implementation

Would the Payload team be open to receive a potential contribution for such a feature?