openxiangda 1.0.264 → 2.0.0-alpha.2

package/templates/sy-lowcode-app-workspace/examples/best-practices/access-governance.md

@@ -1,239 +0,0 @@
-# Access Governance Pattern
-
-This example is a generic account and permission governance skeleton. Copy only
-the parts required by the selected permission mode. Do not publish this example
-directly without changing codes, names, roles, and data scopes.
-
-Start with:
-
-```bash
-openxiangda design gates --topic permissions --json
-```
-
-Choose one mode:
-
-- `managed-platform-account`: app creates/maintains platform departments,
-  accounts, and role members.
-- `existing-platform-user-assignment`: app assigns existing platform users to
-  app roles and business scopes.
-- `static-role-permission`: fixed roles and permission groups only.
-- `query-param-context`: query parameters are only context, filters, or ticket
-  input; they do not grant sensitive data access.
-
-## Resource Closure
-
-```text
-src/forms/organization_unit/schema.ts
-src/forms/system_account/schema.ts
-src/forms/role_assignment/schema.ts
-src/functions/sync_access_governance/index.ts
-src/resources/roles/access-roles.json
-src/resources/permissions/page-groups/access-admin-pages.json
-src/resources/permissions/form-groups/role_assignment/access-admin.json
-```
-
-## Form Skeletons
-
-`organization_unit` stores business organization units and the platform
-department sync result:
-
-```ts
-export const organizationUnitFields = [
-  { fieldId: "unitName", label: "组织名称", componentName: "TextField", placeholder: "请输入组织名称" },
-  { fieldId: "unitCode", label: "组织编码", componentName: "TextField", placeholder: "请输入稳定组织编码" },
-  { fieldId: "parentUnit", label: "上级组织", componentName: "SelectField", placeholder: "请选择上级组织", options: [] },
-  { fieldId: "manager", label: "负责人", componentName: "UserSelectField", placeholder: "请选择负责人" },
-  { fieldId: "platformDeptId", label: "平台部门ID", componentName: "TextField", behavior: "HIDDEN" },
-  {
-    fieldId: "syncStatus",
-    label: "同步状态",
-    componentName: "SelectField",
-    behavior: "HIDDEN",
-    options: [
-      { label: "待同步", value: "pending" },
-      { label: "已同步", value: "synced" },
-      { label: "同步失败", value: "failed" },
-    ],
-  },
-  { fieldId: "syncMessage", label: "同步说明", componentName: "TextAreaField", behavior: "HIDDEN" },
-  { fieldId: "lastSyncedAt", label: "最后同步时间", componentName: "DateField", behavior: "HIDDEN" },
-];
-```
-
-`system_account` stores the app-owned account record and the platform user sync
-result:
-
-```ts
-export const systemAccountFields = [
-  { fieldId: "displayName", label: "姓名", componentName: "TextField", placeholder: "请输入姓名" },
-  { fieldId: "loginName", label: "登录名", componentName: "TextField", placeholder: "请输入登录名" },
-  { fieldId: "phone", label: "手机号", componentName: "TextField", placeholder: "请输入手机号" },
-  { fieldId: "unitCode", label: "所属组织", componentName: "SelectField", placeholder: "请选择所属组织", options: [] },
-  {
-    fieldId: "enabled",
-    label: "账号状态",
-    componentName: "RadioField",
-    placeholder: "请选择账号状态",
-    options: [
-      { label: "启用", value: "enabled" },
-      { label: "停用", value: "disabled" },
-    ],
-  },
-  { fieldId: "platformUserId", label: "平台用户ID", componentName: "TextField", behavior: "HIDDEN" },
-  { fieldId: "platformDeptId", label: "平台部门ID", componentName: "TextField", behavior: "HIDDEN" },
-  {
-    fieldId: "syncStatus",
-    label: "同步状态",
-    componentName: "SelectField",
-    behavior: "HIDDEN",
-    options: [
-      { label: "待同步", value: "pending" },
-      { label: "已同步", value: "synced" },
-      { label: "同步失败", value: "failed" },
-    ],
-  },
-  { fieldId: "lastSyncedAt", label: "最后同步时间", componentName: "DateField", behavior: "HIDDEN" },
-];
-```
-
-`role_assignment` maps accounts or existing platform users to roles and business
-scope keys:
-
-```ts
-export const roleAssignmentFields = [
-  { fieldId: "account", label: "账号", componentName: "SelectField", placeholder: "请选择账号", options: [] },
-  { fieldId: "platformUser", label: "平台用户", componentName: "UserSelectField", placeholder: "请选择平台用户" },
-  {
-    fieldId: "roleCodes",
-    label: "角色",
-    componentName: "CheckboxField",
-    placeholder: "请选择角色",
-    options: [
-      { label: "权限管理员", value: "access_admin" },
-      { label: "范围内经办人", value: "scope_operator" },
-    ],
-  },
-  { fieldId: "businessUnit", label: "业务组织", componentName: "SelectField", placeholder: "请选择业务组织", options: [] },
-  { fieldId: "businessScopeKey", label: "业务范围键", componentName: "TextField", behavior: "HIDDEN" },
-  {
-    fieldId: "syncStatus",
-    label: "同步状态",
-    componentName: "SelectField",
-    behavior: "HIDDEN",
-    options: [
-      { label: "待同步", value: "pending" },
-      { label: "已同步", value: "synced" },
-      { label: "同步失败", value: "failed" },
-    ],
-  },
-  { fieldId: "syncMessage", label: "同步说明", componentName: "TextAreaField", behavior: "HIDDEN" },
-];
-```
-
-## Sync App Function Skeleton
-
-```ts
-export default async function syncAccessGovernance(ctx, input) {
-  const roleCodes = ctx.operator?.roleCodes || [];
-  if (!roleCodes.includes("access_admin") && !ctx.operator?.hasFullAccess) {
-    throw new Error("ACCESS_DENIED");
-  }
-
-  if (input.action === "syncAccount") {
-    if (!ctx.organization?.accounts) throw new Error("ORGANIZATION_API_UNAVAILABLE");
-    // Current operator must have app:organization:manage.
-    return ctx.organization.accounts.create({
-      name: input.displayName,
-      loginName: input.loginName,
-      phone: input.phone,
-      departmentId: input.platformDeptId,
-    });
-  }
-
-  if (input.action === "syncRoleMembers") {
-    // Read role_assignment records, resolve platformUserId values, and update
-    // app role members through the platform role API exposed by OpenXiangda.
-    return { ok: true };
-  }
-
-  throw new Error("UNKNOWN_ACTION");
-}
-```
-
-## Role Resource
-
-```json
-[
-  {
-    "code": "access_admin",
-    "name": "权限管理员",
-    "description": "维护组织、账号、角色和权限资源",
-    "apiPermissionMode": "merge",
-    "apiPermissionCodes": [
-      "app:role:manage",
-      "app:page-permission-group:manage",
-      "app:form-permission-group:manage",
-      "app:organization:manage"
-    ]
-  },
-  {
-    "code": "scope_operator",
-    "name": "范围内经办人",
-    "description": "只能访问授权业务范围内的数据"
-  }
-]
-```
-
-The initial grant of `access_admin` is normally done by a platform administrator
-or an existing app administrator. If `access_admin` creates another role that
-also manages accounts, roles, or permission groups, publish that new role with
-its own `apiPermissionCodes`; management power is not inherited from the
-creator.
-
-## Page Permission Group
-
-```json
-{
-  "code": "access_admin_pages",
-  "name": "权限管理员页面",
-  "roles": ["access_admin"],
-  "menuCodes": ["access_governance"],
-  "routeCodes": ["access.governance"],
-  "pathPatterns": ["/view/:appType/admin/access/*"]
-}
-```
-
-## Form Permission Group
-
-```json
-{
-  "code": "role_assignment_admin",
-  "formCode": "role_assignment",
-  "name": "角色分配管理员",
-  "type": "view",
-  "roles": ["access_admin"],
-  "operations": ["view", "edit", "delete"],
-  "dataScope": [{ "type": "all" }],
-  "fieldAccessPolicy": {
-    "defaultAccess": "edit",
-    "fields": [
-      { "fieldId": "syncMessage", "access": "readonly" }
-    ]
-  }
-}
-```
-
-For `scope_operator`, use condition data permission against hidden scalar keys,
-for example `businessScopeKey = ${CURRENT_USER_SCOPE}`. Do not fetch all rows
-and filter them in the page.
-
-## Acceptance
-
-- Permission mode and matrix are written in the SDD change or design document.
-- `openxiangda permission audit --json` has no high-risk gaps.
-- Allowed and denied role paths are both tested.
-- Query parameter tampering does not expand sensitive access.
-- Managed account writes are executed only by a user with
-  `app:organization:manage`.
-- Roles that create roles, assign members, or maintain permission groups include
-  `apiPermissionCodes` such as `app:role:manage`.

package/templates/sy-lowcode-app-workspace/examples/best-practices/catalog.json

@@ -1,99 +0,0 @@
-{
-  "version": 1,
-  "publishedByDefault": false,
-  "copyInto": "src/",
-  "templates": [
-    {
-      "code": "glass-home-dashboard",
-      "type": "page-ui-template",
-      "path": "src/pages/glass-home-dashboard",
-      "uiTemplate": "glass-home-dashboard",
-      "recommendedFor": ["经营首页", "管理驾驶舱", "轻量门户首页"],
-      "description": "Default light-blue glass dashboard shell with sidebar, top search, welcome banner, quick actions, KPI cards, charts, ranking, activity feed, query states, and drawer form actions."
-    },
-    {
-      "code": "mint-analytics-dashboard",
-      "type": "page-ui-template",
-      "path": "src/pages/mint-analytics-dashboard",
-      "uiTemplate": "mint-analytics-dashboard",
-      "recommendedFor": ["数据分析", "BI 概览", "经营日报"],
-      "description": "Mint analytics dashboard with high-density metrics, line/bar/donut charts, notices, todos, business summary, system health, query states, and drawer form actions."
-    },
-    {
-      "code": "ops-monitor-dashboard",
-      "type": "page-ui-template",
-      "path": "src/pages/ops-monitor-dashboard",
-      "uiTemplate": "ops-monitor-dashboard",
-      "recommendedFor": ["运营监控", "任务中心", "系统健康度", "告警中心"],
-      "description": "Blue-purple operations monitor with realtime trends, animated metric cards, task progress, health score, device status, alerts, quick actions, query states, and drawer form actions."
-    },
-    {
-      "code": "work-order-list-drawer",
-      "type": "page-ui-template",
-      "path": "src/pages/work-order-list-drawer",
-      "uiTemplate": "work-order-list-drawer",
-      "recommendedFor": ["CRUD 列表", "工单管理", "审批处理", "数据管理页"],
-      "description": "Default restrained admin list template with filters, toolbar, status stats, table, loading/empty/error branches, and right-side overlay drawers for detail, create, edit, and process forms."
-    },
-    {
-      "code": "customer-profile",
-      "type": "form",
-      "path": "src/forms/customer-profile",
-      "description": "Standard form schema covering field types, validation, users, departments, attachments, and subforms."
-    },
-    {
-      "code": "service-ticket-lifecycle",
-      "type": "state-flow",
-      "path": "src/domain/service-ticket",
-      "description": "Lifecycle state machine with ticket and action-log forms. Does not use workflow."
-    },
-    {
-      "code": "service-ticket-ops",
-      "type": "page",
-      "path": "src/pages/service-ticket-ops",
-      "description": "DataManagementList-based ops page with modular actions, drawer, timeline, hook, and service."
-    },
-    {
-      "code": "access-governance",
-      "type": "permissions",
-      "path": "access-governance.md",
-      "description": "Generic account/role permission mode decision with organization, account, role assignment, sync function, role resource, page group, and form group skeletons."
-    },
-    {
-      "code": "role-governance",
-      "type": "permissions",
-      "path": "src/domain/role-governance",
-      "description": "Dynamic role maintenance, role sync, maintainable scope fields, hidden permission keys, and permission-group resource examples."
-    },
-    {
-      "code": "pc-portal-shell",
-      "type": "app-shell-page",
-      "path": "src/pages/pc-portal-shell",
-      "description": "PC app-shell entry with routes, modules, shared domain usage, and no hardcoded view URLs."
-    },
-    {
-      "code": "mobile-portal-shell",
-      "type": "app-shell-page",
-      "path": "src/pages/mobile-portal-shell",
-      "description": "Mobile app-shell entry sharing domain/service logic with the PC portal."
-    },
-    {
-      "code": "interactive-workbench",
-      "type": "page",
-      "path": "src/pages/interactive-workbench",
-      "description": "Pure interaction workbench with reducer state, modular panels, and unified query states."
-    },
-    {
-      "code": "expense-approval-workflow",
-      "type": "workflow",
-      "path": "src/resources/workflows/expense-approval-workflow.json",
-      "description": "True approval workflow example. Use only when approval tasks are required."
-    },
-    {
-      "code": "daily-ticket-digest",
-      "type": "automation",
-      "path": "src/resources/automations/daily-ticket-digest",
-      "description": "Scheduled JS_CODE automation that queries paginated data and sends notification resources."
-    }
-  ]
-}

package/templates/sy-lowcode-app-workspace/examples/best-practices/decision-guide.md

@@ -1,94 +0,0 @@
-# Decision Guide
-
-## Page And Data Shape
-
-Use a form when you need a data table. Each form schema defines fields,
-validation, storage shape, and generated platform data APIs.
-
-Use a code page when you need a workbench, portal, dashboard, cross-form
-composition, custom list actions, or complex interaction.
-
-Use `DataManagementList` for list/search/export/batch-management pages. Extend
-it with row actions, custom renderers, and drawers instead of rebuilding
-pagination, export, and filters from scratch.
-
-## Default Admin UI Templates
-
-The UI templates are recommended starting points, not mandatory styles. Choose
-one based on the page's primary job:
-
-- `work-order-list-drawer`: default for CRUD, approval handling, work orders,
-  ticket lists, and data-management pages. Detail, create, edit, and process
-  forms use right-side overlay drawers; do not reserve a permanent right detail
-  column that squeezes the table.
-- `glass-home-dashboard`: default for a friendly PC admin home page, management
-  portal, or first-screen business overview.
-- `mint-analytics-dashboard`: default for analysis-heavy dashboards, weekly
-  business reviews, BI-like reports, and data-summary pages.
-- `ops-monitor-dashboard`: default for realtime operations, task execution,
-  alerts, system health, and monitoring centers.
-
-When a page combines list management and a dashboard, start from
-`work-order-list-drawer` if users spend most time operating rows. Start from a
-dashboard template only when the main job is reading metrics.
-
-## State Flow Is Not Workflow
-
-Most business "processes" are lifecycle state changes:
-
-- work tickets: new -> accepted -> processing -> resolved -> closed
-- orders: draft -> submitted -> paid -> fulfilled -> completed
-- assets: available -> reserved -> in_use -> maintenance -> retired
-
-Use a normal form with a `status` field, maintainable ownership/scope fields,
-and an operation-log form. Define allowed transitions in
-`domain/<feature>/state-machine.ts`, and execute changes through a service
-method that updates state and writes logs.
-
-Use workflow only when the platform must create approval tasks with approvers,
-approval comments, agree/reject actions, copy nodes, node field permissions, and
-approval history.
-
-## Automation And JS_CODE
-
-Use automation or workflow JS_CODE when logic must run on the backend after a
-trigger: scheduled scans, cross-form synchronization, notification fan-out,
-external HTTP calls, or platform role synchronization.
-
-Frontend code must not be responsible for data isolation or background jobs.
-
-## Permissions
-
-Run `openxiangda design gates --topic permissions --json` before implementing
-account, role, RBAC, organization-account, data-scope, or query-param
-authorization requirements.
-
-Choose one pattern:
-
-- `managed-platform-account`: app creates and maintains platform departments,
-  accounts, and role members. Start from `access-governance.md`.
-- `existing-platform-user-assignment`: app selects existing platform users and
-  assigns roles/business scopes. Use a role assignment form with
-  `UserSelectField`.
-- `static-role-permission`: fixed roles and permission groups only.
-- `query-param-context`: query parameters are context, filters, or ticket input
-  only; they cannot grant sensitive access.
-
-For dynamic multi-role apps, create a business role table and synchronize it to
-platform app roles. User-facing scope fields should be maintainable controls:
-personnel/department fields for people and orgs, enum fields for fixed option
-sets, and SDK-backed `SelectField` dropdowns for classes, colleges, projects,
-customers, and other records maintained by forms. Use `remoteSearch: true` when
-the source form can have many records. If the platform permission condition
-needs a scalar value, derive a hidden scope key such as `collegeScopeKey` or
-`ownerDeptScopeKey`. Use form permission groups with condition-style data
-permissions and App Function role/scope checks to enforce data isolation.
-
-When an app role is expected to create roles, assign role members, grant role
-API permissions, maintain permission groups, or manage organization accounts,
-declare the matching `apiPermissionCodes` on that role. `app:role:manage` is
-required for app role creation and member assignment; page/form permission group
-maintenance and organization account management use their own permission codes.
-
-Frontend hiding and query parameters are not authorization. They must not be the
-only barrier for sensitive data or write actions.

package/templates/sy-lowcode-app-workspace/examples/best-practices/design-style.md

@@ -1,91 +0,0 @@
-# Design Style
-
-OpenXiangda business apps should feel like focused operational tools.
-
-## Default Admin UI Templates
-
-These templates are polished defaults for B-end admin pages. They are optional
-starting points, not hard product constraints.
-
-### `glass-home-dashboard`
-
-- Use for PC admin home pages, management portals, and general business
-  dashboards.
-- Visual direction: light blue glass surface, soft sidebar, translucent panels,
-  welcoming banner, KPI cards with small trends, quick actions, chart blocks,
-  ranking, activity feed, and target progress.
-- Keep density medium. The first viewport should make the platform identity,
-  navigation, search, and key metrics obvious.
-
-### `mint-analytics-dashboard`
-
-- Use for BI-style analysis, business reviews, operational reports, and weekly
-  summary pages.
-- Visual direction: low-saturation mint green, tighter metric cards, structured
-  chart grid, notification and todo panels, business summary, and health score.
-- Keep labels short and chart containers stable. Favor comparison, trend, and
-  distribution charts over decorative widgets.
-
-### `ops-monitor-dashboard`
-
-- Use for realtime monitoring, operations centers, task execution, system
-  health, and alert pages.
-- Visual direction: blue-purple accent, stronger status hierarchy, realtime
-  traffic chart, task progress bars, system rings, device state, alert list, and
-  subtle CSS motion.
-- Do not add GSAP or other animation dependencies by default. Use lightweight
-  CSS transitions unless a product requirement needs a true timeline engine.
-
-### `work-order-list-drawer`
-
-- Use as the default CRUD/data-management template for tickets, approvals,
-  orders, assets, and record operations.
-- Layout: fixed app shell, compact filters, toolbar, status stat cards, dense
-  table, pagination, and right-side overlay drawer.
-- Detail, create, edit, approve, reject, and process forms open in `Drawer` or
-  `Modal`. Do not put a permanent form/detail column beside the table, because
-  it narrows the main working area and makes table operations less stable.
-
-## Interaction Defaults
-
-- Every async page has loading, refreshing, empty, error, and submit-pending
-  states.
-- List refresh should keep existing rows visible and show a small refresh state.
-- Mutating actions need confirmation, pending feedback, success feedback, and a
-  failure refresh or rollback path.
-- Detail, create, edit, approval, and processing workflows should use an overlay
-  `Drawer` or `Modal` with fixed header, scrollable body, and footer actions.
-- Mobile actions should use a bottom action area, drawer, or action sheet; do
-  not copy a dense PC table toolbar to mobile.
-
-## Layout Defaults
-
-- Use dense but readable workbench layouts for admin and ops pages.
-- Put high-value filters near the list, not in hidden configuration pages.
-- Use status tags, responsibility fields, and latest action summaries for
-  lifecycle data.
-- Do not build marketing-style hero pages for business tools.
-- Do not nest cards inside cards. Use panels for page regions, and use cards
-  only for repeated items, modals/drawers, or genuinely framed controls.
-
-## Styling Rules
-
-- Use Tailwind native utilities and arbitrary values as the default styling
-  vocabulary, plus Ant Design and antd-mobile for mature controls.
-- Platform token classes are compatibility helpers for platform components and
-  theme overrides. Do not make them the main pattern for business pages.
-- Prefer concrete Tailwind classes such as `bg-white`, `border`,
-  `border-slate-200`, `text-slate-600`, `shadow-sm`, and
-  `grid-cols-[240px_1fr]`. Do not use shadcn token classes such as `bg-card`,
-  `text-muted-foreground`, or `text-foreground` unless the workspace explicitly
-  configures them.
-- Use mature packages for mature interactions: antd controls instead of native
-  inputs, ECharts for charts, GSAP for complex animation timelines, and
-  maintained drag/drop or virtual-list libraries when those behaviors are
-  required.
-- Research package docs and current maintenance before adding a new dependency;
-  write business adapters instead of copying library internals.
-- Keep page styles in `styles.css`; avoid large inline style objects.
-- Keep reusable visual states in shared components: status tags, query states,
-  confirmation triggers, and operation timelines.
-- Do not override private Ant Design class names.

package/templates/sy-lowcode-app-workspace/examples/best-practices/module-structure.md

@@ -1,48 +0,0 @@
-# Module Structure
-
-Use this structure for substantial features:
-
-```text
-src/
-  domain/<feature>/
-    types.ts
-    state-machine.ts
-    permissions.ts
-    query.ts
-    index.ts
-  shared/
-    services/<feature>.ts
-    hooks/use<Feature>.ts
-    components/
-      QueryState.tsx
-      StatusTag.tsx
-  pages/<feature>/
-    page.config.ts
-    index.tsx
-    App.tsx
-    styles.css
-    components/
-  forms/<feature>/
-    schema.ts
-    page.tsx
-```
-
-## Dependency Direction
-
-```text
-pages -> shared/hooks -> shared/services -> domain
-forms -> shared -> domain
-```
-
-- `domain/` has no React, Ant Design, SDK, or page imports.
-- `shared/` does not import from `pages/`.
-- `pages/` compose modules and call hooks; they do not build complex query
-  payloads inline.
-- PC and mobile views can have different components and styles, but they reuse
-  the same domain and service logic.
-
-## File Size
-
-Avoid large single-file pages. If a page grows beyond roughly 250 lines, split
-table actions, drawers, timelines, query builders, hooks, and styles into
-separate files.

package/templates/sy-lowcode-app-workspace/examples/best-practices/src/domain/role-governance/index.ts

@@ -1,2 +0,0 @@
-export * from "./permissions";
-export * from "./types";

package/templates/sy-lowcode-app-workspace/examples/best-practices/src/domain/role-governance/permissions.test.ts

@@ -1,52 +0,0 @@
-import assert from "node:assert/strict";
-import { describe, it } from "node:test";
-
-import {
-  buildConditionDataPermission,
-  buildRoleCode,
-  deriveRoleScopeKeys,
-} from "./permissions";
-
-describe("role-governance permission helpers", () => {
-  it("normalizes dynamic role codes", () => {
-    assert.equal(buildRoleCode({ roleCode: " College Admin " }), "college_admin");
-    assert.equal(buildRoleCode({ roleCode: "class  advisor" }), "class_advisor");
-  });
-
-  it("derives hidden scope keys from maintainable select values", () => {
-    assert.deepEqual(
-      deriveRoleScopeKeys({
-        collegeScope: { label: "理学院", value: "college_science" },
-        classScope: { label: "2026 级一班", value: "class_2026_01" },
-      }),
-      {
-        collegeScopeKey: "college_science",
-        classScopeKey: "class_2026_01",
-      },
-    );
-  });
-
-  it("builds condition-based data permissions from hidden scope keys", () => {
-    const permission = buildConditionDataPermission({
-      collegeScopeKey: "college_science",
-      classScopeKey: "",
-      ownerDeptScopeKey: "dept_lab",
-    });
-
-    assert.equal(permission.type, "condition");
-    assert.deepEqual(permission.condition.rules, [
-      {
-        field: "collegeScopeKey",
-        componentType: "Text",
-        op: "=",
-        value: "college_science",
-      },
-      {
-        field: "ownerDeptScopeKey",
-        componentType: "Text",
-        op: "=",
-        value: "dept_lab",
-      },
-    ]);
-  });
-});

package/templates/sy-lowcode-app-workspace/examples/best-practices/src/domain/role-governance/permissions.ts

@@ -1,37 +0,0 @@
-import type { AppRoleRecord, DataOwnershipFields } from "./types";
-
-export function buildRoleCode(role: Pick<AppRoleRecord, "roleCode">) {
-  return role.roleCode.trim().replace(/\s+/g, "_").toLowerCase();
-}
-
-function scopeKey(value: { value?: string | number } | undefined) {
-  return value?.value === undefined || value.value === null ? "" : String(value.value);
-}
-
-export function deriveRoleScopeKeys(
-  role: Pick<AppRoleRecord, "collegeScope" | "classScope">,
-) {
-  return {
-    collegeScopeKey: scopeKey(role.collegeScope),
-    classScopeKey: scopeKey(role.classScope),
-  };
-}
-
-export function buildConditionDataPermission(scope: DataOwnershipFields) {
-  const rules = Object.entries(scope)
-    .filter(([, value]) => Boolean(value))
-    .map(([field, value]) => ({
-      field,
-      componentType: "Text",
-      op: "=",
-      value,
-    }));
-
-  return {
-    type: "condition" as const,
-    condition: {
-      logic: "AND" as const,
-      rules,
-    },
-  };
-}