Workspaces' entity presave hook omits entities provided by the workspaces module. When trying to combine it with the content_moderation module, I found out that the content_moderation_state entity should be omitted as well. @amateescu suggested that this is probably true for all internal entity types.
In this case, all workspaces get their own revision of an entities moderation state, which means they can have different moderation states per workspace. This is exactly the behaviour my current use case needs, but I'm not sure this is intended.
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | 3027598-18-8.7.x.patch | 8.78 KB | amateescu |
| #14 | 3027598-14.patch | 8.88 KB | amateescu |
| #11 | interdiff-11.txt | 4.45 KB | amateescu |
| #11 | 3027598-11.patch | 8.69 KB | amateescu |
| #5 | 3027598-5.patch | 9.32 KB | amateescu |
Comments
Comment #2
pmelab commentedComment #3
plachNeeds review?
Comment #4
amateescu commentedWorking on an updated patch.
Comment #5
amateescu commentedThis change makes the
workspaceentity type (which is not internal) unable to be changed in a non-default workspace, as the test fails show :)Also, we need to skip the pre-delete hook for internal entity types as well, which shows that this code can be a little confusing. Let's introduce a dedicated method for the checks in pre-save and pre-delete, so we don't get into the same problem again.
Reworked the test coverage because a phpunit test method should set an expected exception only once.
Comment #6
pmelab commentedReviewed the patch and tested with our current use case (involving quite a lot of different internal entities). All works as expected.
Comment #8
larowlanDoes workspaces have a notion of handlers? This feels like something we might want the entity providers to have a say in?
E.g. content moderation has handlers with a default and then node has its own with some extra sauce
Comment #9
amateescu commented@larowlan, nope, we didn't find the need to have per-entity type customizations so far.
Comment #10
alexpottOut-of-interest how come this is on WorkspaceManager and not a protected method on \Drupal\workspaces\EntityOperations? It seems odd for this implementation detail to be in the Workspace manager.
Comment #11
amateescu commented@alexpott, very good point :) The only reason I put that helper method on the workspace manager is to make it easier to override if anyone needs some custom behavior. But after your question, I realized that we instantiate the entity operations class with the class resolver service, which means that developers can provide a service with that class name and the override ability is not lost.
Comment #12
alexpottI've read this a few times and I'm just not sure we can make this assumption. Here are docs for isInternal()
I'm not sure that
is really an assumption that can be made. Or if it can be then we really need to explain why.
Comment #13
amateescu commentedDiscussed this issue with @alexpott at Dev Days Transylvania, and, after reviewing all the usages of
internalin core and contrib, we agreed to move forward with the current patch and discuss improving the documentation of that property in a follow-up issue: #3061252: Improve the documentation of the 'internal' property of entity typesComment #14
amateescu commentedRerolled after #3059090: Deprecate \Drupal\Tests\PhpunitCompatibilityTrait::setExpectedException().
Comment #15
amateescu commentedComment #16
alexpottCommitted 76fa7e9 and pushed to 8.8.x. Thanks!
I'm going to commit #11 to 8.7.x once it has had a test run.
Comment #18
amateescu commentedI just checked and #11 doesn't apply anymore to 8.7.x either, so here's a reroll for that.
Comment #19
alexpottCommitted 37e4d4b and pushed to 8.7.x. Thanks!