spKPImodule.md 1.74 KB

spKPImodule (procedure)

  • Type: PROCEDURE
  • Deterministic: NO
  • SQL data access: CONTAINS SQL

Parameters

No parameters.

Body

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

Narrative

Business context: 系统 → KPI考核 — bootstrap / sync proc that materialises one kpimodule row per business-displayable gdsmodule so the KPI configuration UI has a complete list of modules to attach 工作果实 / 限制时间 / 奖励 / 处罚 defaults to. Also nukes the login-info jurisdiction rows on the way out.

What it does: Three statements. (1) INSERT INTO kpimodule(sId,…) from gdsmodule M WHERE bUnTask=1 AND sDisplayType='Business' AND sName<>'' for any module not yet in kpimodule (left-anti-join via NOT IN) — defaults dLimitation=8h, sLimitTime='16:00:00', sWorkDate='08:00:00', dreward=0, dpunishment=0, copies sChineseUnMemo/sChineseWorkFruit into sUnMemo/sWorkFruit. (2) UPDATE kpimodule SET bVisible=1 for rows whose sModelId is no longer in the live module set (orphan kpi rows). (3) DELETE FROM sysjurisdiction WHERE sJurisdictionClassifyId IN (SELECT sId FROM sisjurisdictionclassify WHERE bLogininfoShow=1) — clears all login-info jurisdiction grants.

Invocation: Status: appears orphaned. No gdsmodule/gdsconfigformmaster binding, no other DB routine, no Quartz task row, no Java caller — only the install script script/标版/30100101/spKPImodule.sql references this name. Lowercase sp prefix, no IN/OUT params → likely an admin one-shot run manually by maintainers (CALL spKPImodule();) to reconcile KPI module rows after a deployment. The third DELETE is destructive — flag before re-running.