What happened?
Description
When a custom Entries source (Settings → Entries → a section → Element index → "New custom source") includes a Status condition rule (e.g. "Status is not Live"), the rule is not applied when viewing that source in the control panel. All entries are listed regardless of status, as if no Status condition existed.
Root cause appears to be in the element index toolbar's "Status" menu (the one showing "All" by default). For native sources, ElementIndexesController::actionFilterHud() / the source config expose the source's criteria.status to the front end via a data-criteria attribute, which the JS uses to hide the toolbar Status menu:
|
if (typeof this.baseCriteria.status !== 'undefined') { |
|
this.$statusMenuContainer.addClass('hidden'); |
|
} else { |
|
this.$statusMenuContainer.removeClass('hidden'); |
|
} |
this.baseCriteria is populated from this.$source.data("criteria"). That data-criteria attribute is only rendered for sources of type native (see ElementIndexesController::actionFilterHud(), which only reads $this->source['criteria'] for ElementSources::TYPE_NATIVE). Custom sources (ElementSources::TYPE_CUSTOM) use a condition object instead of criteria, so data-criteria is never set, baseCriteria.status is always undefined, and the toolbar Status menu is therefore never hidden for custom sources — even when the source's own condition already includes a StatusConditionRule.
We confirmed via a console script that the EntryCondition stored for the custom source (Type = X, Status is not Live, a custom Lightswitch field = true) is built and executed correctly on its own (ElementCondition::modifyQuery() produces correct SQL and returns the correct, smaller result set). But the live control panel request for the same source returns every entry matching the other two rules regardless of status — the same count as querying with no status condition at all. Only the status param is affected; the Type and custom-field rules in the same condition are respected correctly.
Steps to reproduce
- Create (or use) an Entries section with more than one entry, some
Live and some Disabled.
- Go to Settings → Entries → the section → element index settings, and add a new custom source.
- In "Entry Criteria" for the new source, add a
Status condition rule set to "is not" → Live (plus optionally other rules, e.g. entry type or a custom field).
- Save, then go to Entries and select the new custom source.
- Note the "All" status dropdown in the toolbar is visible and interactive (unlike for native sources whose criteria already fixes the status).
- Observe the listed entries / total count.
Expected behavior
Only entries matching the source's saved condition are listed — i.e. Live entries are excluded, since the source's Status rule says "is not Live".
Actual behavior
Entries of every status are listed, including Live ones, exactly as if the source had no Status condition rule at all. The toolbar's "All" status menu (which shouldn't apply / should be hidden, since the source already defines its own status criteria) is left active and effectively neutralizes the source-level Status rule.
Craft CMS version
5.10.11
PHP version
8.4.22
Operating system and version
No response
Database type and version
No response
Image driver and version
No response
Installed plugins and versions
No response
What happened?
Description
When a custom Entries source (Settings → Entries → a section → Element index → "New custom source") includes a
Statuscondition rule (e.g. "Status is not Live"), the rule is not applied when viewing that source in the control panel. All entries are listed regardless of status, as if no Status condition existed.Root cause appears to be in the element index toolbar's "Status" menu (the one showing "All" by default). For native sources,
ElementIndexesController::actionFilterHud()/ the source config expose the source'scriteria.statusto the front end via adata-criteriaattribute, which the JS uses to hide the toolbar Status menu:cms/src/web/assets/cp/src/js/BaseElementIndex.js
Lines 2395 to 2399 in 9dece66
this.baseCriteriais populated fromthis.$source.data("criteria"). Thatdata-criteriaattribute is only rendered for sources of typenative(seeElementIndexesController::actionFilterHud(), which only reads$this->source['criteria']forElementSources::TYPE_NATIVE). Custom sources (ElementSources::TYPE_CUSTOM) use aconditionobject instead ofcriteria, sodata-criteriais never set,baseCriteria.statusis alwaysundefined, and the toolbar Status menu is therefore never hidden for custom sources — even when the source's own condition already includes aStatusConditionRule.We confirmed via a console script that the
EntryConditionstored for the custom source (Type = X, Status is not Live, a custom Lightswitch field = true) is built and executed correctly on its own (ElementCondition::modifyQuery()produces correct SQL and returns the correct, smaller result set). But the live control panel request for the same source returns every entry matching the other two rules regardless of status — the same count as querying with no status condition at all. Only thestatusparam is affected; theTypeand custom-field rules in the same condition are respected correctly.Steps to reproduce
Liveand someDisabled.Statuscondition rule set to "is not" →Live(plus optionally other rules, e.g. entry type or a custom field).Expected behavior
Only entries matching the source's saved condition are listed — i.e.
Liveentries are excluded, since the source'sStatusrule says "is not Live".Actual behavior
Entries of every status are listed, including
Liveones, exactly as if the source had noStatuscondition rule at all. The toolbar's "All" status menu (which shouldn't apply / should be hidden, since the source already defines its own status criteria) is left active and effectively neutralizes the source-level Status rule.Craft CMS version
5.10.11
PHP version
8.4.22
Operating system and version
No response
Database type and version
No response
Image driver and version
No response
Installed plugins and versions
No response