ckozus

Workflow Action Policies — Implementation Plan

Covers IDEA-340 (Workflow Action Policies) and IDEA-338 (Force Complete). The policies system is the foundation; Force Complete is the first action built on top of it.

---

1. Data Model

active_flow_definition_action_policies table

ckozus

# ============================================================
# Create registrations for unclaimed students.
# Picks a random course section from each student's college,
# restricted to active terms only.
#
# Usage: copy/paste into `heroku run rails console -a <review-app>`
# ============================================================

MARKER_MIDDLE_NAME = 'Unclaimed'

ckozus

Plan: Migrate provided_fields to Static Metadata via completion_state Macro

Context

provided_fields on step classes returns field names a step will set on the workflow. The engine uses this to (a) block re-activation of completed steps and (b) build dependency graphs for static analysis.

Problem: Most implementations need a runtime ActiveFlowStep.find just to read the completion_state parameter — which is already on the ActiveFlowStepTrigger at definition time. This prevents static inspection of ActiveFlowDefinition without building mock instances.

Goal: A single source of truth for a step's completion state, declared on the class (overridable by trigger parameters), resolvable statically from triggers. Eliminate the 605 subclass overrides of provided_fields over time.

ckozus

Unclaimed Students - Implementation Plan

Context

This plan supports IDEA-360 (Unclaimed Student — Decouple Student from User Account), the foundational prerequisite for the Student File Importer (IDEA-351) and College Driven Registration. The goal is to make the Student-User association optional, introduce the claim_state model, and ensure all existing platform features work correctly when a student has no user account.

Key constraints:

• Email and contact information are genuinely optional for unclaimed students
• Phase 1 is infrastructure only — no creation paths ship in this release
• Student Accounts page redesign is handled separately by Product

ckozus

Managed Students - Impact Analysis & Implementation Plan

Context

Colleges need to create and manage students without those students having user accounts. The goal:

1. Students without users - structural changes to support student.user being nil
2. College-managed registrations - colleges create student_de_courses (triggering active_flows) and college_student_applications for these students
3. Platform stability - all existing features must work with userless students

Key constraint: Email is optional for managed students. Colleges may not have email at creation time. This means student.email can return nil - not just "read from a different source" but genuinely absent.

ckozus

IDEA-330: Expand College System User Access

Context

College system users (e.g., KCTCS kctcsreportingadmin) can access all colleges under their system and use the Registration Dashboard and workflow steps. However, they get "Access Denied" on the Courses page, Instructors page, and the Admin sidebar is nearly empty. Three distinct root causes:

1. Courses & Instructors pages: load_college in application_controller.rb:171-174 can't resolve @college for system users (their college_id is nil), so require_college (line 209) blocks access before CanCan even runs.
2. Instructors page: Additionally missing CanCan permissions in ability.rb.
3. Admin sidebar: _college_system_profile_nav.html.erb only has 2 items vs ~30 in the college version.

Part 1: Fix college loading for system users

ckozus

Plan: Organization Roles Table (IDEA-330, Phase 1)

Context

KCTCS has a system admin (user 2093824) who needs College Super Admin access across all 16 KCTCS colleges. Currently, users are tied to ONE college via users.college_id or ONE college system via users.college_system_id, with roles in users.role_mask.

This phase creates organization_roles as the new source of truth for org-level role assignments, removes users.college_id and users.college_system_id, and migrates existing data. No UI changes -- data managed via ActiveAdmin.

College context is already handled by branded_host (subdomain). Each college has a unique subdomain, and branded_host_college in ApplicationController resolves it. Multi-college users just access different subdomains -- no switcher needed.

ckozus

IDEA-330: Add Instructor Permissions for College System Users

Context

College system users (e.g., KCTCS kctcsreportingadmin) can access all colleges under their system but get "Access Denied" on the Instructors page. The Courses page and Admin sidebar already work. The root cause is missing Instructor-related CanCanCan permissions in the college_system? block of ability.rb.

Implementation

File: app/models/ability.rb (lines 837-941)

The college_system? block already defines instr_cond = { college: coll_cond } on line 847 but never uses it. Add the following permissions after the existing InstructorCourseDocument read block (around line 857), mirroring the college super admin permissions from lines 498-557:

ckozus

Workflow Action Policies — Use Cases

These use cases illustrate the problem space and the expected behavior of the Workflow Action Policies system. They cover both Abandon and Force Complete actions across platform-wide and college-specific scenarios.

---

Terminology

ckozus

Appendix A: Technical Specifications

Field Types, Validations, and Behaviors

This appendix provides detailed technical specifications for the existing field types, validation methods, and behaviors that must be supported in the new Dynamic Form Builder implementation.

---

1. Field Types

1.1 Data Field Types