fix(ui): show dot menu when editMenuItems exist regardless of create/delete permission

[jhjh1214]

Fixes #16975

What?

editMenuItems defined on a collection were silently hidden when both create and delete permissions were denied, because the three-dot menu's visibility (showDotMenu) was gated entirely on those permissions.

Why?

Custom editMenuItems represent arbitrary business logic unrelated to CRUD operations. A collection that blocks creation (e.g. webhook-only) and deletion (e.g. audit trail) should still expose custom actions like "Resend confirmation email".

How?

Added EditMenuItems as an additional condition in showDotMenu so the popup renders whenever custom items are present, regardless of create/delete access.

[GermanJablo]

Thanks!

[jhjh1214]

Hi @GermanJablo, thank you so much for approving this earlier and turning on auto-merge!

I just rebased the branch onto the latest main because the CI checks were failing with a "build cache not found" error across pretty much every test. I think it was because my branch was quite a few commits behind main, so the cache didn't match anymore. The actual code change is exactly the same as before, I only updated the base branch.

Since I don't have write access, the force push ended up turning off auto-merge automatically. Would you mind taking a quick look and turning it back on whenever you have time? Really appreciate your help and patience with this, still learning the ropes here!

Thanks again 🙏

[jhjh1214]

Hi @GermanJablo, quick update, and sorry in advance for the extra round trip.

Found and fixed a regression in this same diff. The EditMenuItems || change can make the dot menu render on the create view (no document id yet) for collections that have delete permission. That hits DeleteDocument's id={id.toString()} with id being undefined, which crashes the page. I added an id guard so DeleteDocument only renders once a document actually exists, and just pushed that fix.

This also explains the multi-tenant e2e failures from the earlier rerun, they're the same crash, not a separate issue. The logs show TypeError: Cannot read properties of undefined (reading 'toString') right before the .template-default--nav-hydrated timeout, the nav never finishes hydrating because the page crashed first. Should be resolved by the same fix.

Also heads up, this push dismissed your previous approval. Sorry about that, happy for you to take another look whenever you have time.

Thanks again for all the help with this one!

[GermanJablo]

No problem! Thanks for checking it out!

[jhjh1214]

One more unrelated flake: live-preview failed with the same required-server-files.json ENOENT issue (looks like a timing race in the test harness's readiness check, possibly worse under shard parallelism, not connected to this diff). Would you mind giving it a rerun when you get a chance?