Clear Form action can select a form that is inside a repeater, but never actually clears the form.

[mikesealey]

Checklist

• [Y] I have searched budibase discussions and github issues to check if my issue already exists

Hosting

• Self & Cloud

Describe the bug Component tree: New Button has On Click action set to clear form, but cannot clear form unless it is within the repeater.

Either it shouldn't be able to access the form contained within the repeater, or it should be able to clear all forms in the repeater.

Worthy of note: Save Row action cannot access the forms inside the repeater (unless the button is placed the repeater)

To Reproduce Steps to reproduce the behaviour:

1. Add a Data Provider, Nest a repeater, nest a form, nest some fields (see component tree above)
2. Add a button to clear form, select the form created in the above data provider
3. In the published app, add some sample data to the form(s)
4. Click the button to clear form
5. Notice that forms aren't cleared

Expected behavior Either all forms in the repeater are cleared, or the form inside the repeater cannot be specified in a clear row action from a button that isn't also inside the repeater

Screenshots Link to Jam

App Export Link to App 14030-export-1719477522476.tar.gz

Desktop (please complete the following information):

• OS: iOS
• Browser: chrome, safari
• Version [e.g. 22]

Additional context Add any other context about the problem here.

[linear[bot]]

BUDI-8402 Clear Form action can select a form that is inside a repeater, but never actually clears the form.

[mikesealey]

Same issue exists for "Update Field Value" action, where Form, and all accompanying Form Fields are accessible outside the repeater, but nothing changes.

[aptkingston]

You're right that they shouldn't be appearing at all. With "save row" and other actions, they use context to determine what they can and can't "see", and that takes care of properly handling repeaters.

I have a feeling at the clear form action potentially just looks for form components anywhere in the tree instead, so is returning them all, whether or not it will actually be able to use them in the app.

I should be able to update these steps to instead check context for action availability rather than component type, which should properly filter these out.

[shogunpurple]

@aptkingston did you manage to get a look at this?