Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
In Content Moderation we have the ModerationState
constraint. This is used on both the computed moderation_state field added to selected entity types, and on the entity reference moderation_state field on ContentModerationState entity type.
- Do we need the same constraint on both fields?
- Is it even valid?
- Does it work since we changed to a computed field?
- Does validation get checked anywhere when creating ContentModerationState entities?
Proposed resolution
Answer above questions.
Make sure there is test coverage for this.
Add extra constraints and validation where needed.
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#13 | 2781907-constraint-clean-up-5.patch | 809 bytes | timmillwood |
#5 | 2781907-constraint-clean-up-5.patch | 809 bytes | Sam152 |
Comments
Comment #2
AniG CreditAttribution: AniG as a volunteer commentedThis is a test (ignore)
Comment #3
AniG CreditAttribution: AniG as a volunteer commentedComment #4
AniG CreditAttribution: AniG as a volunteer commentedComment #5
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedI've had a look at this and found that:
Nope, when the constraint is checked for the ContentModerationState entity, it fails the first check in the constraint:
Given the checks seem centered around the entity actually being moderated, it seems like it would be a lot of effort to make the constraint work with both entities for not much benefit, given the data stored in the field on the unsupported entity has already been validated.
Looks like there is a test which tries to set invalid states (EntityStateChangeValidationTest) and the constraint is used there.
Yep, it looks like the constraint is checked for computed fields.
tl;dr, it can be removed from ContentModerationState, it's valid for the computed field with tests to prove it.
Comment #7
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedWrong version.
Comment #9
timmillwoodPatch in #5 looks correct, but marking as "needs work" for tests. Think we also need a test only patch. Although not sure how we'd test this yet.
Comment #10
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedYeah, I'm stumped on what we would actually be testing with this removed, given it never did anything to begin with.
Comment #11
timmillwoodHe's a test to prove the validation is useless, but also proves maybe we need something.
Comment #12
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedPersonally I don't see the need for a test or to validate this stuff. updateOrCreateFromEntity is marked as internal, so I see this issue as removing some dead code.
Based on the save method interacting with the parent entity, I think this actually proves there isn't a way to trigger this without using an internal method. We could write a validator specifically for this entity, but personally I think it's extra code to maintain for not much benefit.
Comment #13
timmillwoodok, fair enough!
Patch seems ok.
Not worth testing.
We can add a new constraint if ever needed.
Re-uploading patch for clarity.
Comment #15
timmillwoodComment #16
xjmThe title of this issue is way scarier than the patch in it.
Comment #17
xjmComment #18
alexpottYeah this constraint is probably a copy&paste error...
It is always going to just return cause you can't moderation and ContentModerationState content entity - fortunately because that would be beyond inception.
Comment #19
alexpottCommitted and pushed 2a55d2d to 8.4.x and 6983b38 to 8.3.x. Thanks!