Initial work on enabledByOwner

[brandonkelly]

Description

Adds a new enabledByOwner element query param, which maps to a new elements_sites.enabledByOwner column. The column keeps track of whether the element/site’s owner element is enabled (recursively).

Related issues

• [5.x]: Address queries return addresses that belong to disabled entries by default #18151

[linear]

PT-2994 enabledByOwner element query param

[brandonkelly]

A little stumped on the most efficient way to bulid out the Elements::updateNestedEnabledByOwnerValues() method. I was thinking it could reference the elements_owners table directly to find nested elements, and be called recursively when nested enabledByOwner values differ from the passed-in $enabledByOwner value. But we don’t want to do that for nested elements that aren’t primarily owned by the saved element. E.g. if you create a draft and its nested element ownerships are duplicated for the draft, then disabled the draft, you wouldn’t want the nested elements’ enabledByOwner values set to false.

I considered only calling updateNestedEnabledByOwnerValues() when a canonical element is saved, but that would fail in the following situation:

1. Create an enabled entry with a Matrix field.
2. Create a draft for the entry.
3. Disable the owner entry draft.
4. Create a new nested entry within the Matrix field. (enabledByOwner = false)
5. Enable the owner entry draft. (Nested entry’s enabledByOwner value is left alone as false because $element isn’t canonical.)
6. Apply the draft.

In this situation, the entry’s enabled value wouldn’t appear to have changed, so there would be no need to call updateNestedEnabledByOwnerValues(), so the nested entry’s enabledByOwner stays set to false.

So either:

1. we call updateNestedEnabledByOwnerValues() every time an element is saved, regardless of whether its status changed; or
2. we have a way of tracking primary element owners within the elements_owners table, so we know which nested elements’ enabledByOwner values to update for any given save.

Option 2 would be more performant, but would also require a new primary column added to elements_owners (or a primaryOwnerId column added to elements), and expect that all plugins that implement nested elements add a migration to set those values correctly for this feature to work.