Validate LDAP auth provider form using vee-validate

[rak-phillip]

The LDAP auth provider form passes :validation-passed="true" unconditionally to CruResource. As a result:

• The Enable button is never disabled, regardless of field state
• Fields marked as required have no validation logic behind them
• The user has no client-side indication of what is wrong before form submission
• No inline error tooltip appears on blur for any field

Expected behavior

• Blurring an empty required field should display an inline error tooltip
• The Save button should be disabled until all required fields contain a value
• The validation state driving the button and the inline error hints should come from the same source so they are always consistent with each other

Steps to reproduce

• Navigate to Users & Authentication => Auth Providers and select a LDAP auth provider
• Leave all fields empty
• Observe that the save button is active and clickable
• Click the save button. The form submits and returns a server error instead of validating locally
• Clear an individual field and click elsewhere. No error tooltip appears

Acceptance criteria

• All required fields show an inline error tooltip when left empty and blurred
• The save button is disabled while any required field is empty
• :validation-passed is no longer hardcoded to true
• Validation logic is consistent with the OIDC form

[github-actions]

🎯 Agentic Issue Triage

This issue tracks adding proper client-side form validation to the LDAP auth provider form using vee-validate. Currently :validation-passed="true" is hardcoded, meaning the Save button is always enabled and no inline field errors appear — forcing the server to catch all validation errors.

This is the LDAP counterpart to:

• Migrate OIDC auth provider form to vee-validate #17754 – Migrate OIDC auth provider form to vee-validate
• Validate the saml auth provider form with vee-validate #17777 – Validate the SAML auth provider form with vee-validate

---

📁 Relevant Files

• shell/edit/auth/ldap/index.vue — main LDAP auth provider form component; this is where :validation-passed="true" is likely hardcoded
• shell/edit/auth/ldap/config.vue — sub-component for LDAP config fields
• shell/edit/auth/saml.vue — reference: the recently fixed SAML form (see Validate the saml auth provider form with vee-validate #17777)
• Look for the CruResource usage and the validationPassed / validation-passed prop binding

🔍 Debugging Strategy

1. Open shell/edit/auth/ldap/index.vue and locate the <CruResource> component call — confirm :validation-passed="true" is hardcoded.
2. Compare with the OIDC form (shell/edit/auth/oidc.vue) to understand the vee-validate pattern adopted there.
3. Use the SAML fix in Validate the saml auth provider form with vee-validate #17777 as the reference implementation since SAML is the closest analogue to LDAP in terms of form structure.
4. Identify all fields marked required in shell/edit/auth/ldap/config.vue to build the validation schema.

🛠️ Suggested Sub-tasks

• Audit shell/edit/auth/ldap/index.vue — identify all required fields and the current validation-passed binding
• Introduce a vee-validate schema (likely zod based, matching OIDC pattern) covering all required LDAP fields
• Replace :validation-passed="true" with a computed prop driven by the vee-validate form validity state
• Ensure blur events on required fields trigger inline error tooltips
• Verify the Save/Enable button becomes disabled while any required field is empty
• Add/update unit tests covering the new validation logic
• Smoke-test against a live LDAP provider (FreeIPA or OpenLDAP) if available, or at minimum test with the mock

📚 Helpful Resources

• [vee-validate docs]((veevalidate.logaretm.com/redacted)
• [Zod schema validation]((zod.dev/redacted)
• Related PR for SAML (Validate the saml auth provider form with vee-validate #17777) — once merged, use as direct reference
• shell/components/form/ — reusable validated input components already wired to vee-validate

💡 Notes & Nudges

• Priority set to normal (P2) consistent with the SAML and OIDC counterparts.
• Consistency with the OIDC form is an explicit acceptance criterion — review the validationPassed computed pattern in the OIDC implementation before designing the LDAP solution.
• LDAP has two sub-forms (base config + server config); make sure validation state is composed across both sub-components if they are rendered conditionally.
• The QA/dev-automation label is already present, indicating automated tests will be expected.

Generated by Agentic Triage for issue #17778 · ● 189.3K · ◷

[github-actions]

🤖 Issue grooming analysis

This issue is well-specified and ready for development:

• Clear problem statement: The LDAP auth provider form unconditionally passes :validation-passed="true" to CruResource, bypassing all client-side validation. The affected area (LDAP auth provider, Users & Authentication) is clearly described.
• Acceptance criteria: A concrete, testable checklist is provided — inline error tooltips on blur, disabled Save button while required fields are empty, removal of the hardcoded prop, and consistency with the OIDC form.
• Technical details: The specific prop (:validation-passed), component (CruResource), and the bug's mechanism are clearly identified.
• Reproducibility: Numbered steps are provided with clear expected vs. actual behavior.

This analysis was generated automatically based on the repository's grooming checklist.

Generated by Daily Issue Grooming · ● 870.5K · ◷