feat(core): Custom fields on ProductVariantPrice

[HausTechTeam]

Description

Support for custom fields on ProductVariantPrice.

Breaking changes

No

Screenshots

Checklist

📌 Always:

• I have set a clear title
• My PR is small and contains a single feature
• I have checked my own PR

👍 Most of the time:

• I have added or updated test cases
• I have updated the README if needed

[michaelbromley]

Thank you!

[HausTechTeam]

You're welcome :)

Do you happen to have a rough idea of when the next minor release might be available?

[michaelbromley]

I'm aiming for February for the release, but before then I'll be doing a pre-release which will include this feature, probably by next week.

[oidt]

I have a question about this. I can see the customfield on the admin-api after putting it in the config. ProductVariantPrice: [ { name: 'costumerGroup', type: 'relation', entity: CustomerGroup, }, { name: 'customerPrice', type: 'int' } ]

but I can not find this on the shop-api. Neither I can find a input field on the admin-ui.

admin-api:

[michaelbromley]

@oidt the ProductVariantPrice is not exposed to the Shop API by default.

And yes this PR does not include any Admin UI change that would add custom field inputs for the product variant price. Indeed, there is no GraphQL API part that even allows modification. As it stands the custom fields would need to be set in a custom mutation.

[lzzfnc]

Hello! Sorry to bump into this, but what would it be the procedure to expose the admin ui for the custom fields? It is something doable with a plugin, or it requires changes to the core?

[michaelbromley]

@lzzfnc A work-around solution would be to define a Custom Detail Component block on the product variant detail page as part of a UI extension, and in that block you can have a form which exposes the custom fields.

The main drawback here is that it will not be hooked up to the overall form save mechanism for the detail page, so changes made to the custom fields would need their own "save" button inside the custom detail component.

A more satisfactory solution would be to add built-in support which means changes to the admin ui package itself. You can open a separate feature request for this if you like.