- Issue created by @jurgenhaas
- 🇩🇪Germany mxh Offenburg
I think currently it's always appearing twice. Reason is that the first page is the configuration form of the action, but that's most probably not providing any config input so it appears to be an empty form. The second page is then the "real" confirmation page.
Was already thinking how to overcome this, but not yet found a solution. Maybe it works to add a redirect within the configuration form, in case it's empty, but haven't tried this out yet.
- 🇩🇪Germany jurgenhaas Gottmadingen
Ah, that makes sense, yes. Since a VBO from ECA should never come with a config form, I assume, isn't there a different base class that can be used which would not be a confirm form? And also, the second form to confirm the action has been configurable in the view for "regular" VBO actions, not sure if that's still possible. But if so, would it be possible to provide such an option here as well?
- 🇩🇪Germany mxh Offenburg
We are using the config form, by reacting upon "VBO: Form build of Views bulk operation". For example, you can then add a textarea field for a message content to be used for execution.
There is a different base class, but sometimes you have a config form using the event, sometimes you don't. Maybe it's possible to assign a different class to be used from the deriver, when it sees that there is no such event used (matching up by operation name should be doable).
So currently two approaches we may want to try:
- Make the deriver more smart and assign a different class that is not using the configuration form
- Redirect on the config form
And also, the second form to confirm the action has been configurable in the view for "regular" VBO actions, not sure if that's still possible. But if so, would it be possible to provide such an option here as well?
I don't know yet, needs to be investigated.
- Status changed to Fixed
5 months ago 11:41am 3 August 2024 - 🇩🇪Germany mxh Offenburg
Added a solution that works as follows: when there is no configuration form item added, i.e. the form itself stays empty, then a redirect to the confirm form will be performed.
Automatically closed - issue fixed for 2 weeks with no activity.