A full-featured, open-source content management framework built with Node.js that empowers organizations by combining in-context editing and headless architecture in a full-stack JS environment.
Summarize the changes briefly, including which issue/ticket this resolves. If it closes an existing Github issue, include "Closes #[issue number]"
What are the specific steps to test this change?
See unit tests. I don't know how an end user can convince the UI to attempt it, but the important thing is that the backend API refuse to do it, which is what I've implemented here. (My new test did fail until I made the fix.)
What kind of change does this PR introduce?
(Check at least one)
[X] Bug fix
[ ] New feature
[ ] Refactor
[ ] Documentation
[ ] Build-related changes
[ ] Other
Make sure the PR fulfills these requirements:
[X] It includes a) the existing issue ID being resolved, b) a convincing reason for adding this feature, or c) a clear description of the bug it resolves
[X] The changelog is updated
[ ] Related documentation has been updated
[X] Related tests have been updated
If adding a new feature without an already open issue, it's best to open a feature request issue first and wait for approval before working on it.
linear[bot]
commented
2 months ago
Summary
Summarize the changes briefly, including which issue/ticket this resolves. If it closes an existing Github issue, include "Closes #[issue number]"
What are the specific steps to test this change?
See unit tests. I don't know how an end user can convince the UI to attempt it, but the important thing is that the backend API refuse to do it, which is what I've implemented here. (My new test did fail until I made the fix.)
What kind of change does this PR introduce?
(Check at least one)
Make sure the PR fulfills these requirements:
If adding a new feature without an already open issue, it's best to open a feature request issue first and wait for approval before working on it.
Other information: