Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved customization for ConfigurableOperationDef (Promotions, ShippingMethods, etc) #414

Closed
michaelbromley opened this issue Jul 21, 2020 · 0 comments

Comments

@michaelbromley
Copy link
Member

Is your feature request related to a problem? Please describe.
We have widely-used class, ConfigurableOperationDef, which is used as the basis of several runtime-configurable objects:

  • CollectionFilter
  • PaymentMethodHandler
  • PromotionAction
  • PromotionCondition
  • ShippingEligibilityCheker
  • ShippingCalculator

The definition allows the developer to define args which can then be configured at run-time with concrete values by the Administrator. In the Admin UI we generate form fields for this purpose.

The problem is that with the current implementation there are a number of limitations:

  • The supported data types for the args are fixed and cannot be extended in any way. Supported data types are: 'string' | 'int' | 'float' | 'boolean' | 'datetime' | 'facetValueIds'. Note that facetValueIds is a kind of special case which is actually just an array of strings.
  • The Admin UI cannot be customized to use custom components as input for these args values.
  • Only simple data types are supported, there is no support for relations. E.g. the facetValueIds seems like it is a relation, but it is really just a dumb list of strings. True relations would be prefereable, and should be generic so that any entity can be related.
  • List values are not supported.

Describe the solution you'd like
Disregarding the feasibility for now, here is the ideal solution:

  • Args can be defined as any of the datatypes supported by custom fields, as well as a relation to any available Entity
  • Arrays of any of those types are also supported
  • There is a way to specify a UI component to act as the input control of that arg, in a similar way that we do with custom fields already.

Any breakthroughs in this area may also be applicable to custom fields, such as the ability to define lists and relations.

I have no design for this yet - this is quite a complex problem and after some exploration I'll add any implementation ideas I come up with.

@michaelbromley michaelbromley pinned this issue Jul 21, 2020
@michaelbromley michaelbromley added this to the v0.15.0 milestone Jul 21, 2020
michaelbromley added a commit that referenced this issue Jul 30, 2020
Relates to #414. This refactor sets things up for adding some new features such as list support.
michaelbromley added a commit that referenced this issue Jul 30, 2020
Relates to #414

BREAKING CHANGE: The `'facetValueIds'` type has been removed from the `ConfigArgType` type, and replaced by `'ID'` and the `list` option. This change only affects you if you have created custom CollectionFilters of PromotionActions/Conditions using the `'facetValueIds'` type for an argument.
@michaelbromley michaelbromley unpinned this issue Aug 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant