You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
bug(events): upsert-post permission denial on merged-duplicate reimport in CI since #3933 #3944
DataMachineEvents\Tests\Unit\EventUpsertTest::test_merged_duplicate_whose_winner_is_gone_restores_on_reimport fails in CI (Homeboy (review test), data-machine-events) on every PR opened since #3933 landed (#3939, #3940, #3942). None of those PRs touch upsert:
Failed asserting that false is true.
{"success":false,"error":"Ability \"datamachine/upsert-post\" does not have necessary permission.",
"tool_name":"DataMachineEvents\\Steps\\Upsert\\Events\\EventUpsert","error_code":"ability_invalid_permissions",...}
The failing step is the reimport of the loser parameters, after EventMergeHelper::merge( $winner, $loser ) and wp_trash_post( $winner ).
Observations
The suspect is 5f672d8, "fix(abilities): enforce per-object post capabilities in upsert-post (fix(abilities): enforce per-object post capabilities in upsert-post #3933)", merged 2026-11-12. The data-machine-events CI suite hasn't run on main since then, so there's no baseline (the digest says "baseline artifact unavailable").
The test passes locally with the native MariaDB harness (homeboy review test data-machine-events --placement local -- --filter=test_merged_duplicate). It only fails in the CI environment (multisite Playground). It may depend on the DB engine or on test order, but the error is a capability denial from UpsertPostAbility::check_permission() / authorize_request().
The current user in EventUpsertTestCase::setUp is a site administrator, not a super admin. On multisite, per-object checks that resolve to the trashed winner or to a merged-redirect target may deny it.
Why it matters
If #3933 makes legitimate reimports of merged duplicates fail permission checks, production pipelines could hit the same ability_invalid_permissions when re-scraping a merged event whose winner was trashed.
Done looks like
Identify which object authorize_request() checks in this flow and why it's denied in CI.
Fix either the capability resolution (upstream in data-machine core, if it's a real regression) or the test setup (if it's a test-environment artifact).
Make the data-machine-events CI suite green on main.
The denial is either PermissionHelper::can('chat') returning false, or a 403 from authorize_request() / authorize_existing_post(). Core's WP_Ability::execute masks the reason with the generic ability_invalid_permissions, and the _doing_it_wrong message isn't in the CI output.
Next step: in CI, log the actual permission result (e.g. via the wp_ability_permission_result filter in the test) to see which check denies the request.
Activity
chubes4 commentedon Nov 14, 2026
Findings so far:
--filter=test_merged_duplicate). Local full-suite runs from the feat(events): extract venue gig lists under month headings #3939 and feat(events): PatronManager (Salesforce PatronTicket) extractor #3940 worktrees also passed it. Only CI fails, so this looks order- or environment-dependent rather than deterministic.PermissionHelper::can('chat')returning false, or a 403 fromauthorize_request()/authorize_existing_post(). Core'sWP_Ability::executemasks the reason with the genericability_invalid_permissions, and the_doing_it_wrongmessage isn't in the CI output.wp_ability_permission_resultfilter in the test) to see which check denies the request.test(events): DIAGNOSTIC capture permission denial detail (temporary, #…
test(events): clear privacy-policy page option in upsert test setup