Appsmith UI updates for bare entity IDs

[Oluwajuwon-O]

Description

Depends on domain_neutral PR #123

Prefixed entity IDs broke Appsmith column lookup

Test configuration forms historically saved and manipulated ref('dot_model__...') / dot_model__... entity references. Appsmith’s JSFunctions.getEntityColumns relied on fragile .replace() stripping to recover bare IDs, which broke dropdown column population when formats varied.
The UI still bound possible_duplicate_forms inputs to table_specific_* keys. After the macro/seed rename, the configuration forms need to capture the generic keys instead.

Resolution

Update docker/appsmith/DOT App V2.json so that:

• Entity dropdowns / JSON generators store bare entity IDs (no ref('dot_model__...')).
• Fragile dot_model__ / ref(...) string-stripping in Appsmith JS is removed; column lookup uses bare IDs directly.
• possible_duplicate_forms bindings use:
  • date_column
  • group_column
  • id_column
  • period
    The export is also pretty-printed, which makes the diff large (~+38k lines). The behavioral changes above are the review focus; formatting alone is not intended to change runtime behavior.
    In the Technical Documentation, this is addressed in Section 8 (building on bare-entity storage in Section 6 and domain-neutral duplicate params in Section 7).

Depends on

• Normalize bare entity IDs in test parameter preparation #122 (bare entity IDs / prepare_test_parameters)
• Refactor domain-neutral duplicate detection parameters #123 (domain-neutral possible_duplicate_forms parameters)
  This branch is stacked on those PRs. After they merge, use Update branch so the GitHub diff shrinks to the Appsmith-only changes.

Scope note

Backend helpers, dbt macro rename, SQL seeds, and self-test fixtures land in #122 / #123. This PR is the Appsmith UI binding for those contracts.

Asana Task

Deployment Readiness*

Testing

Describe or check:

• Created or updated unit, feature, and/or integration tests
• Typical manual testing in the local env browser, dev pipeline, etc.

Deployment Notes

Describe or check:

• No special deployment steps required

Rollback Plan

Describe or check:

• Standard revert is sufficient (git revert)

Reviewer Guidance / Questions*

Screenshots / Testing Evidence*

SOC 2 Change Management Checklist

• None of the below are true in this code
• New roles/permissions are introduced without review and approval by the product manager
• Hardcoded credentials, secrets, or API keys are present in this code
• Secrets are being managed outside of the approved secrets management process (e.g., GitHub Secrets, environment variables)
• PII or sensitive data handling is introduced or changed without being reviewed against our data classification policy
• Sensitive data is written to logs
• Input validation and sanitization is missing
• An unnecessary attack surface has been introduced (e.g., unused endpoints, open ports, debug modes left enabled)
• Common vulnerabilities have been introduced in the code (inc. any dependencies added or updated)
• No review for common vulnerabilities has been conducted
• Not tested in a non-production environment
• Breaking changes to existing APIs or integrations with downstream consumers being notified
• Performance impact has not been considered or acceptable
• Appropriate audit logging is missing for any security-relevant actions introduced by this change
• Log entries contain sensitive or PII data
• All existing tests do not pass locally (./vendor/bin/pest)

Provide justification if you are submitting a PR with any boxes checked other than the first.

---

Reminder for Reviewers: By approving this PR you are confirming that you have reviewed the code for correctness, security, and compliance with our engineering and SOC 2 standards. Do not approve PRs where SOC 2 checklist items are checked without documented justification.

*Optional