FEATURE: WorkspaceName with reference for unused contentStream

[mhsdesign]

As written in https://github.com/neos/neos-development-collection/issues/5034#issuecomment-2197400445 we actually decided against it, but look how pretty it seems? :D

introduces the syntax WorkspaceName('cs:<ContentStreamId>') ... that way we'd now what to write inside the fetched workspace name of a "forbidden" node.

But we initially didnt want to go down this road:

Neos 9.0 weekly - 01-03-2024

• Decide for WorkspaceName|DetachedWorkspaceName $workspaceName later if we really need it.
  • Changing this later would be a b/c disaster
  • Instead: WorkspaceName::fromString() stricter without colons (so that we can allow for extension, e.g. WorkspaceName::detached(ContentStreamid $csId) (with an internal representation like “cs:”)

---

Additionally we should restrict the workspace name to be stricter: https://github.com/neos/neos-development-collection/issues/5125 and discuss if fromString should allow the cs: notation.

---

TODO

1.) discuss if we are okay with being able to reference the content stream id in a node address per uri:

http://localhost/neos/preview?node=%7B%22contentRepositoryId%22%3A%22default%22%2C%22workspaceName%22%3A%22cs%3Acs-identifier%22%2C%22dimensionSpacePoint%22%3A%5B%5D%2C%22aggregateId%22%3A%22non-existing%22%7D

2.) disallow the 'fake' workspace name to be used in commands like createWorkspace, or modify a node.

3.) check other usages where a fake workspace name can be passed and see if we should allow it there.

[kitsunet]

Ok but why, is there a usecase?

[mhsdesign]

just for the tests a usecase.

the commit TASK: Remove deprecated usage $node->subgraphIdentity->contentStreamId solves this issue https://github.com/neos/neos-development-collection/issues/5043

or see over here in this issue where we discussed how to solve this last riddle: https://github.com/neos/neos-development-collection/issues/5034#issuecomment-2122150792

[kitsunet]

As I wrote over in the discussion I would say this is a low level (non API) testing usecase, where the tests want to check something that hte API "blackbox" shouldn't expose and I would suggest to handle it that way. As in by circumventing API on a loewr level (e.g. direct DB checks) and not adding API for that.

[mhsdesign]

Closing in favour of https://github.com/neos/neos-development-collection/pull/5169