Cross-space validation rules that refer to same space should not cause failures

[CharlieHawker]

Context

We are using migration scripts to apply migrations to a number of spaces and keep the content model in sync across each one.

One key principal we have is that we allow a reference to exist upwards to refer to a piece of content in the primary space (Space A) from another space (Space B, Space C etc.), but never the other way around.

To that end, we have validation rules in our content types that allow references to specific content items in the Space A space.

We apply our migrations as part of the CICD pipeline, and the context for which the migration is running will therefore contain the spaceId.

Issue description

We recently encountered an issue with a Rich Text field that contained the following validation rules:

[{ "enabledNodeTypes": ["entry-hyperlink", "resource-hyperlink"], "message": "Only link to entry and link to entry from a different space nodes are allowed" }, 
{ "nodes": { "entry-hyperlink": [{ "linkContentType": ["page"], "message": null }], "resource-hyperlink": { "validations": [], "allowedResources": [{ "type": "Contentful:Entry", "source": "crn:contentful:::content:spaces/${SPACE_A_ID}", "contentTypes": ["page"] }] } } }]

When we use contentful migration to apply that migration within the context of Space A itself, SPACE_A_ID will match context.spaceId. This means the resource-hyperlink is redundant in this case.

We believe the migration should proceed and ignore the rule seeing as it clearly isn't possible to externally reference the same space.

What we're seeing though is an error, and the migration halts:

Error: {"status":"Unprocessable Entity","message":"Validation error","details":{"errors":[{"name":"invalid_resource","details":"Invalid resource specification. Resource links cannot refer to resources in the same space","value":"crn:contentful:::content:spaces/${SPACE_A_ID}","path":["fields",2,"validations",3,"nodes","resource-hyperlink","allowedResources",0,"source"]}]},"url":"https://api.contentful.com/spaces/${SPACE_A_ID}/environments/${ENV_NAME}/content_types/${CONTENT_TYPE_ID}"}

This obviously would likely extend beyond the resource-hyperlink node type on a rich text field to include entry (different space) and inline entry (different space).

Suggested solution

We appreciate that we can hand-write the migration to understand the context of the space in which it is being run and modify the validation rules accordingly, but this feels like a labour-intensive solution on a per-migration basis for something that is likely to come up in a number of places. We could also implement a helper function to handle these cases but again, I think the logic would be better in the migration tool itself.

I see two possible routes to resolving this:

1. contentful-migration could itself issue a warning rather than an error where the problem is the resource link refers to the same space (and remove the validation rule).
2. the merge app should generate a migration file that performs the check and only includes that validation rule if the context isn't the same space id

I appreciate this is not the right place for route 2, but I wanted to put both options forward.

[whitelisab]

Hi @CharlieHawker! Thanks for raising this issue. We are checking with some teams internally and will get back to you soon.

[whitelisab]

Hi @CharlieHawker, just providing an update here. After reviewing your issue and discussing it internally with some teams, we can confirm that the migration tool is currently surfacing valid Contentful API errors. At this time, resource links cannot refer to resources within the same space. We believe the best current approach is to adjust your migration scripts to include validation logic appropriate for the present restrictions of resource links.

We’ve logged your input as a customer signal about enabling resource links to work for same-space references. There is no firm commitment or timeline for this feature yet, but this signal will help inform any future consideration of enhancements in this area.

Thank you again for taking the time to share your feedback and use case with us.