Provide a list of taken approval rule names when the form is visible
Problem to solve
When adding an approval rule, the entire form must be submitted to determine if the name is already taken or not.
Intended users
Unknown / Anyone managing a project. Potentially any user with administrative rights to a project.
User experience goal
The name field should respond to input by checking the value of the name field against a known list of taken names. That validation should appear where the current error appears, but without requiring that the form be submitted.
Proposal
I propose that we add a small UX improvement to the front end that checks the value in the name field against a full list of known taken names. Providing the list of names to the form ahead of time would require new back end work to collect the names and deliver them - perhaps as an array - to the front end ahead of time (e.g. when the HTML is rendered). The front end can then check the name field against the provided list of taken names to show the validation error to the user without requiring that they submit the form, and without requiring any network traffic. The form would not be submittable with a duplicate name.
Further details
This solution does introduce the possibility of a race condition: if the list of names is delivered to the front end, which has a long delay before submitting a new approval rule, a name may be taken already by another user in the system in the mean time. Then the user would be back to submitting the form and receiving an error, possibly leading them to even greater frustration since the UI was supposed to be telling them about taken names. This would be solved by #251123, with the added cost of frequent network trips.
Permissions and Security
Documentation
Availability & Testing
What does success look like, and how can we measure that?
Success for this is zero approval rule submissions that result in an error indicating the name is taken and no complaints about invalid UI errors (like "this form says the name is taken but it's not!").
The overlap of those two data points means we're successfully preventing submissions with data we can know in advance will fail (and thus preventing user frustration with this experience) and we're not incorrectly blocking users from submitting data that is acceptable.