This is to add support for staging simple configuration, e.g., site name, which is critical for Experience Builder
We'll begin with a test that looks something like this:
Four users:
- Anonymous session - obvious
- Non-workspaces user - authenticated user without Workspaces permissions
- Workspaces user #1 - has all Workspaces/Workspaces Config permissions
- Workspaces user #2 - has all Workspaces/Workspaces Config permissions
Tests:
- They all see the same site name in the live workspace at the start.
- The Workspaces users each create and activate a workspace.
- Workspaces user #1 modifies the site name in their workspace.
- Workspaces user #1 sees the new site name in their workspace.
- Workspaces user #2 still sees the initial site name in their workspace.
- Workspaces user #2 can no longer modify the site name.
- They all still see the same initial site name in the live workspace.
- Workspaces user #1 publishes their workspace.
- They all see the new site name in the live workspace.
Does that seem about right to start with? Anything obviously missing or extraneous?
Issue fork wse-3505900
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
traviscarden commentedI've added a WIP branch to show the current state of my work while I attend to another priority. I've got a basic framework (that can probably be extracted for more generalized use later). It's going well, but
wseseems to break Core's workspace test utilities, since they work until I enable it:That's where I'll pick up when I get back.
Comment #3
wim leersThat test looks like a nice start! 👍 😄
#2: seems like the expected
Workspaceconfig entity does not exist yet, since thatNULLcan only come fromComment #4
amateescu commentedI think the test case laid out in the IS is an excellent starting point, thanks for working on this!
The error from #2 is caused by
wse_workspace_presave(), which overrides the workspace ID with its UUID before saving. This is needed because core's assumption that workspace IDs should be reused after publishing doesn't match the expected content editor experience on most sites.Until this is fixed in core, you should use
\Drupal\Tests\wse\Functional\WseTestUtilities::wseCreateAndActivateWorkspaceThroughUi()instead of the core trait.Comment #6
traviscarden commentedThank you, @amateescu; that was an important piece of knowledge.
When I created this issue, I thought simple config staging was supposed to already be supported, so I'm changing this to a feature request, and I'm presuming to mark it "Major" since it's in the critical path for Experience Builder.
The draft MR I created above adds failing tests that are basically complete for the happy path. They should be enough to prove that the basic functionality works once they. Then we can proceed to add tests for secondary functionality, edge cases, and error-handling, etc.
I'm going to move on to writing tests for other functionality in the meantime.
Comment #7
amateescu commentedThe problem here was that the
system.siteconfig object was ignored by the blanket opt-out ofsystem.*config objects.Changing that to opt-out specific config objects and a couple of minor changes to the test makes it pass, which proves that simple config is actually supported :)
I've opened #3563938: Refactor the way we enable/support simple config and config entities to fix this in a more general way though.
@traviscarden, do you want to continue working on this test? There are a couple of @todo's left.
Comment #8
traviscarden commentedHey, @amateescu. I'm afraid I no longer have allocation for this as I've been moved to another project. I'll be cheering from the sidelines. 😄
Comment #10
amateescu commentedI've opened #3564458: [PP-1] Implement workspace conflict validation for config to add the functionality needed for the remaining @todo's in this MR.
Merged into 3.0.x, thanks!