[BUG](Collections): Items in one-to-many relationship (many-side) cannot be removed in certain scenarios

[hunghvu]

Bug Report

Let's say there are two collections: Articles and Tags.

1. One article has many tags (one-to-many, but the bug is also applicable to the one-to-one relationship).
2. A tag is only readable in a published state.

When a tag is attached to an article and that tag is either unpublished or deleted, it still leaves an ID behind, as shown in an ...cfb item below. This should not happen.

Expected Behavior

If there is a constraint when a tag is only readable after being published, it should disappear from the response when being marked as draft.

The tag should also disappear after its deletion.

Current Behavior

Already shown above.

Possible Solution

N/a.

Steps to Reproduce

• Create 2 collections:

// Articles.ts
...
    {
      name: 'settingsTags',
      label: 'Tags',
      type: 'relationship',
      relationTo: 'tags',
      hasMany: true,
      required: true,
    },
...

// Tags.ts 
import { CollectionConfig } from 'payload/types';

const readQuery = {
  and: [
    {
      _status: {
        equals: 'published',
      },
    },
  ],
};

const Tags: CollectionConfig = {
  slug: 'tags',
  access: {
    read: ({ req: { user } }) => {
      if (user) {
        return true;
      }
      return readQuery;
    },
  },
  fields: [
    {
      name: 'tagTitle',
      label: 'Tag Title',
      type: 'text',
      required: true,
    },
    {
      name: 'tagDescription',
      label: 'Tag Description',
      type: 'textarea',
      required: true,
    },
  ],
};

export default Tags;

• Attach a tag to an article.
• Either delete a said tag or unpublished it.
• Query for the article as a public, non-authorized user to see the bug as described.

Detailed Description

Payload: v1.1.3
MongoDB: v6.0.1 Community

[DanRibbens]

This is a complexity that I need to figure out and will look deeper into. We started a branch that updates relationships on delete using a flag called "cascade" on the relationship.

Next will be looking into the same behavior for publishing and drafts. One problem I'm anticipating is that if a related item is published, then unpublished, then published again, there is no way that republishing will restore it on the updated collections that related to that item. Where as the way it works now that ID is persisted and this workflow would maintain the relationship.

Related work: #1209

[DanRibbens]

I'm moved this to a discussion since there isn't anything to "fix" right now.