Embed visual rule builder in subject/user rule forms

[kieftrav]

Embed visual rule builder in subject/user rule new and edit forms, replacing the raw text input with an interactive UI from caesar-rules-ui. No backend changes — the controller's existing JSON.parse(condition_string) path handles form submission unchanged.

Linked Issue

• Related: https://github.com/zooniverse/caesar-rules-ui (vanilla JS rewrite, zero dependencies)

Describe your changes

1. New asset: caesar_rule_builder.js — Adapted version of caesar-rules-ui for the Rails asset pipeline. Wrapped in an IIFE, exposes CaesarRuleBuilder.mount(container, { initialRules, onChange }). All CSS classes prefixed crb- to avoid Bootstrap 3 conflicts. Picked up automatically via Sprockets require_tree ..

2. Subject rules form (app/views/subject_rules/_form.html.erb): Replaced f.input :condition_string (plain text input) with a hidden field + builder mount point. On edit, the existing condition is passed from the JSONB column (@subject_rule[:condition]) directly into the builder. The onChange callback syncs the builder's output to the hidden field as JSON on every mutation.

3. User rules form (app/views/user_rules/_form.html.erb): Same pattern as subject rules.

4. Scoped CSS (app/assets/stylesheets/application.scss): ~68 lines of crb--prefixed styles using existing Zooniverse theme variables ($zooniverse-teal, $zooniverse-light-teal, etc.). Bootstrap .form-control on inputs/selects for visual consistency.

How to Review

Local setup:

docker compose up -d
docker compose run --rm app bin/rails db:setup

App runs in development mode — no auth required (uses FakeCredential).

Pages to test:

Page	URL
New subject rule	/workflows/55/subject_rules/new
Edit subject rule (pre-populated)	/workflows/55/subject_rules/2/edit
New user rule	/workflows/55/user_rules/new
Edit user rule (pre-populated)	/workflows/55/user_rules/1/edit

Steps:

1. Navigate to the new subject rule page — confirm the visual builder appears with an "Add Rule" button (no plain text input)
2. Click "Add Rule", select > (gt) from the dropdown, add a lookup value (data.consensus_score) and a const value (3) — confirm the JSON output preview updates in real time
3. Navigate to edit subject rule 2 — confirm the builder pre-populates with ["gte", ["lookup", "UC.classifications", 5], ["const", 3]] (the seed data condition)
4. Change the operator from >= to > — confirm the hidden field updates and existing values are preserved
5. Repeat steps 1-4 for user rules (/user_rules/new and /user_rules/1/edit)
6. Navigate to /workflows/55 — confirm the read-only condition display on the workflow page is unaffected

Checklist

Feature

• Subject rules new form shows the visual builder
• Subject rules edit form loads existing condition into the builder
• User rules new/edit forms work identically
• Form submission round-trips correctly (build → submit → edit shows same condition)
• No visual conflicts with Bootstrap 3 on other Caesar pages
• Read-only condition display (_condition.html.erb) on workflow show page unaffected

General

• Tests are passing locally
• No backend/controller/model changes required
• Asset pipeline picks up new JS via require_tree .

Demo

caesar-rules-builder-ui.mov

[lcjohnso]

@kieftrav What's the purpose of the docker compose override? Is that for testing this feature specifically, or how is it meant to be used?

[kieftrav]

@kieftrav What's the purpose of the docker compose override? Is that for testing this feature specifically, or how is it meant to be used?

• Added a .gitignore because the docker override is my local env specific
• I also addressed all the hound errors
• I added a link to the Caesar rules documentation as well