apache/superset · error · ValueError
created_by_fk_or_editor only supports 'eq'; got '{c.opr}'
Error message
created_by_fk_or_editor only supports 'eq'; got '{c.opr}' What it means
Raised in ReportDAO's filter hook while processing the synthetic filter column 'created_by_fk_or_editor'. This pseudo-column lets report schedules be filtered by creator OR by listed editors (via the report_schedule_editors/Subject join), but only equality filtering is implemented, so any other FilterOperator ('in', 'neq', 'like', ...) triggers this ValueError. Because it escapes as an unhandled ValueError, callers typically see a 500 rather than a 400.
Source
Thrown at superset/daos/report.py:83
if c.col == "editor":
from superset.subjects.models import report_schedule_editors, Subject
operator_enum = ColumnOperatorEnum(c.opr)
subq = (
select(report_schedule_editors.c.report_schedule_id)
.join(
Subject.__table__,
Subject.__table__.c.id == report_schedule_editors.c.subject_id,
)
.where(
Subject.__table__.c.type == 1,
operator_enum.apply(Subject.__table__.c.user_id, c.value),
)
)
query = query.filter(ReportSchedule.id.in_(subq))
elif c.col == "created_by_fk_or_editor":
if c.opr != "eq":
raise ValueError(
f"created_by_fk_or_editor only supports 'eq'; got '{c.opr}'"
)
from superset.subjects.models import report_schedule_editors, Subject
editor_subq = (
select(report_schedule_editors.c.report_schedule_id)
.join(
Subject.__table__,
Subject.__table__.c.id == report_schedule_editors.c.subject_id,
)
.where(
Subject.__table__.c.type == 1,
Subject.__table__.c.user_id == c.value,
)
)
query = query.filter(
or_(
ReportSchedule.created_by_fk == c.value,View on GitHub (pinned to f4587218dd)
Solutions
- Use opr='eq' with a single user id when filtering on created_by_fk_or_editor.
- If you need multi-value semantics, issue separate eq requests and merge results, or filter on a different real column.
- To support more operators, extend the branch in superset/daos/report.py to translate the operator onto the subquery (e.g. Subject.user_id.in_) and add tests.
- Validate the operator client-side against {'eq'} before sending the filter.
Example fix
# before
filters=[{'col': 'created_by_fk_or_editor', 'opr': 'in', 'value': [1, 2]}] # ValueError
# after
filters=[{'col': 'created_by_fk_or_editor', 'opr': 'eq', 'value': current_user_id}] Defensive patterns
Strategy: validation
Validate before calling
def report_owner_filter(user_id: int):
return [{'col': 'created_by_fk_or_editor', 'opr': 'eq', 'value': user_id}] Try / catch
try:
reports = ReportDAO.fetch(...) # applies created_by_fk_or_editor filter
except ValueError as err:
if 'only supports' in str(err):
filters = [f for f in filters if f['col'] != 'created_by_fk_or_editor' or f['opr'] == 'eq']
retry with sanitized filters Prevention
- Treat created_by_fk_or_editor as eq-only in client models and validators.
- Add client-side filter validation for pseudo-columns before calling report APIs.
- When adding pseudo-columns, also extend API filter schemas so bad operators return 400 not 500.
When it happens
Trigger: GET /api/v1/report with filters=[{'col':'created_by_fk_or_editor','opr':'in','value':[1,2]}] or opr='neq'; any API client or UI that maps an editor/creator dropdown to a multi-select 'in' filter on this column.
Common situations: Custom report-management UIs that allow multi-select owner filtering; programmatic integrations reusing generic FilterOperators when building report queries; upgrades that introduced the pseudo-column while older assumptions about arbitrary operators persisted.
Related errors
- DAO datasource query source type is not supported
- Invalid order column: {order_column}
- Report Schedule parameters are invalid.
- Invalid filter: column '%s' does not exist on %s
- Operator '{operator_enum.value}' on relationship column '{co
AI-assisted analysis of apache/superset@f4587218dd (2026-08-14).
Data as JSON: /api/errors/b9b008520ca57631.
Report an issue: GitHub.