Fun_getProcessByControlName (function)

根据工单ID，控制表ID获取工艺流

• Type: FUNCTION
• Returns: longtext
• Deterministic: NO
• SQL data access: CONTAINS SQL

Parameters

#	Mode	Name	Type
1	IN	sWorkOrderId	varchar(50)
2	IN	sWorkControlId	varchar(50)

Body

Body is not pre-cached. To inspect: mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE FUNCTIONFungetProcessByControlName'._

Narrative

Business context: Work-order process-flow renderer (生产管理 → 工单 / 生产计划) — assembles a JSON array describing each mftworkorderprocess step of a given work-order along with a colour-coded state for the planning UI's gantt/flow chart. Despite the header comment mentioning a 控制表ID parameter, only sWorkOrderId is actually used in the body (the second arg is unreferenced).

What it does: joins mftProductionPlanSlave → mftworkorderprocess → eleprocess → sisprocessclassify, groups by iOrder to collapse multi-slave rows into one entry per process step, picks MIN(sState) as the worst-case status, and GROUP_CONCATs a JSON_OBJECT per step (sProcessName, sWorkOrderId, sState, background colour decided by state/bFrozen). Returns a [...]-wrapped JSON array, or '' when no rows match.

Invocation: wrapped by Fun_getProcessByWorkOrderId (the one-arg convenience version that passes '' as sWorkControlId). Neither function is referenced by any other routine, form-master sSqlStr, gdsmodule hook, or xly-src file. Status: appears orphaned. No live caller found in any channel — candidate for maintainer audit (likely a feature-flag UI helper that was wired in a deprecated form).