feat: Allow to remove fields, filters and action from extended grid

[Florian-Merle]

As of today, it's not possible to remove a field, a filter or an action from an extended grid.

For instance, in the case of Sylius customer_order grid in order to remove both the customer filter and the customer field, they are not removed but disabled.

This PR allows to solve this issue. For instance the customer_grid definition could be replaced by the following

sylius_grid:
    grids:
        sylius_admin_customer_order:
            extends: sylius_admin_order
            driver:
                options:
                    repository:
                        method: createByCustomerIdQueryBuilder
                        arguments:
                            customerId: $id
            sorting:
                number: desc
            removals:
                fields: ['customer']
                filters: ['customer']

Also fields, filters and actions from an extended grid can be removed using the GridBuilder.

[vvasiloi]

What's wrong with just disabling them?

[Florian-Merle]

@vvasiloi disabling things when configuring a grid with yaml is not that bad I guess. The thing is, when configuring a grid in php with the GridBuilder, the removeField(...) and the other methods are misleading because they just don't work for things from the extended grid.

I mean, if we take a look at how Symfony form component works, we can remove forms from extended types with a dedicated method. IMO this should work in the same way and as I see it, disabling things is kind of a hack.

[loic425]

That's really awesome. I think a PHPUnit test with an extended grid and a removed field is missing.

[loic425]

@Florian-Merle Dors that work with no grid inheritance, just updating an existing grid configuration

In a first file configuration

sylius_admin_grid:
    fields:
        name: 
            type: string

In a second file configuration

sylius_admin_grid:
    fields:
        removals: 
            fields: ['name']

[Zales0123]

Thank you, it's a nice feature 👍 I have one doubt that need to be resolved and IMO it's good to be merged 🎉

[lchrusciel]

I have a little bit of mixed feelings and have the perspective, that if disabling on the inherited grids would work, that would be a cleaner and simpler solution, as we already have an implementation of it. My main problem with the introduction of field removal is that we will have two ways to achieve exact same thing. Which one should we recommend?

But I don't think, that this consideration should block us from merging it, as the proposed solution is good, solves a particular issue and does not interfere with our current design.

[Zales0123]

I had also mixed feelings about it, but this comment convinced me it's a good way to go. I believe we can deprecate the disable option (as it indeed does the same as removals, at least in yaml) and remove it in potential 2.0. But still, this feature seems valuable.

One more thing, we do not have the documentation for that 💃 So it's another thing that can be done in a separated PR 🖖

Btw, I've allowed myself to fix the comment I left above, I will merge it when it's green 🚀

[Zales0123]

Thanks, Florian! 🥇