MetaData support for Products, Orders and other resources #5897
Comments
|
I don't have strong opinions here, this seems like a legit feature. Still, the advantage of having this built-in vs implementing it custom when needed is not obvious. If someone needs a custom field in a resource, they could add one migration + Am I missing something and it's more complex than this? |
|
== updated twice == I think it's an extremely strong yet simple feature to have this onboard. Most companies just need an identifier (eg PO-Number) and having such field available easily seems low hanging fruit to me compared to Shopify or BigCommerce leveraging the ability to customize beyond what's possible with SAAS. Especially because it can be made agnostic to preexistent code, it's an addition without removing or complicating anything. |
|
@solidusio/core-team thoughts on this? |
|
I think it could be a useful feature. Using the Rails' data store makes much sense here. We would need to add a minimal UI for it, though, right? Any ideas? |
|
@tvdeyen don't we have something similar for the preferences UI? |
|
Ok, I take a look at it today. It seems to be really low hanging fruit. I would kick out the free text field and go with anything that works with limited length and covers also tokenized links (eg shipping labels, downloads,...). I would limit the whole thing to:
If you have particular use cases for text I am curios :) |
|
Should this be an augmentation of product properties, made more robust and extended to other models? |
|
I would go on different resources for different reasons:
It's very hard not to imagine added value with such an easy way to customize. |
|
Ok, if everybody is happy we would pick that up next week and see how to port Spree's meta data. @solidusio/core-team Is anybody particularily upset about anything spree has done in their own implementation? |
Thanks
I don't think there is a value for public vs. private meta data. For public product properties we can use the features we already have. Also, the linked git commit messages far from ideal. We prefer descriptive commit messages that explain why a change has been made and not a link to a private issue tracker. |
|
@tvdeyen theoretically it makes sense to separate in public and private: |
|
@tvdeyen I saw there's a lot going on on the backend, can you people integrate that into the work ongoing? I wouldn't like to touch something to throw away next week. |
|
As far as I understood the meta data is mainly for warehousing and accounting things, not meant to be public. For public meta data we have the Product Properties. We would like to keep it as simple as possible. |
|
I think one area of complexity/potential decisions needed is around REST API payload. Should these fields be part of the payload? |
Hmm I would handle it this way:
@tvdeyen Can you give an example? |
|
Hey guys, I would like to introduce you to @shahmayur001 who has worked on spree in the past for american customers mostly doing backend work. So to break it down: To be applied to: @tvdeyen I would love to give public and private a try and validate according to interface (storefront or pure API) the access. |
Do you have particular preferences on this point? |
|
I don't understand why we'd be storing this data as an array. I think we'd want to model this relationally. I don't care for Spree's approach for a bunch of reasons. |
|
Hey @jarednorman please be as specific as you can be. |
|
Regarding an array:
The great advantage is that any other system no matter what's already there can simply shoot in whatever value. Honestly I find that idea immensely sexy from a technical point of view and way cooler than everything I have seen regarding fields till today. It just needs to be limited and managed. |
|
Altneratively new table and split up the array and file together with resource id, would that work for you? It just blows up the requests for pretty much anything. Depending on scale I wouldn't suggest that on a large category page. |
|
@fthobe @jarednorman I think we are all on the same page, but using different words.
@fthobe do you mean that you are targeting those 8 resources listed that will have these metadata support? If I understood correctly, those metadata fields are going to be Related, JSONB is coming to Sqlite soon: https://sqlite.org/draft/jsonb.html |
|
Hey, Format: we can either use jsonb or alternatively hash the array, both is fine for me. Limitations: Where:
|
|
I am at RubyConf this week, so I don't really have the time to fully explain the implementation that I think we should go with, but I'm open to JSONB-backed implementation. I don't think the various limitations on storage are necessary. I will provide an in-depth explanation of one possible implementation path that I would be happy with next week. |
I hope rubyconf is fun. Ok on jsonb. Are there particular reasons not to limit the model? |
|
Hey @tvdeyen @jarednorman , before we PR anything, please find with this link an example for feedback, as soon as we have understood better how this works for you we can complete it and make a pull request. Please indicate if:
Some Notes
|
|
In addition a suggested PR comment and commit descriptions would be appreciated to get a hang of the whole thing. |
|
Draft PR below addresses most issues |
Meta Data
Types of Meta Data and why we need it
Overview
I have broken meta data down in three large topics visible in the table below.
Administrative Metadata
We do not believe that solidus is used anywhere as standalone system (edge cases excluded of course). Transactional resources are either by nature integrated with 3rd party systems (eg Payments, Billing in Italy with eInvoicing) or by operational requirement (ERP, CRMs like Salesforce,...). For that purpose I see meta data as a senseful extension on admin site for all transactional ressources (also payments, stock movements (even if we won't use them) and RMAs. Given that more and more countries switch to eInvoicing (Germany is next and US has had testing phases for B2B in 2022) in the coming years I personally (and I might well be alone with that opinion) deem meta data on orders a hard requirement to future proof the system.
Customer Meta Data
Customer meta data allows users to customize a cart (incomplete order) with either administrative (PO numbers,...) or customisation information (eg an URL to a picture to customize a shirt, text strings for incisions or in our case IMEIs to relate to a subscription) allowing to significantly extend the features without changing the underlying model. Fields should be accessible on front-end and backend.
Schema
Meta Data should net a reliable outcome:
"key1" : "value1" should be as applicable as "key2" : "value2", without restriction other than the quantity of storable key value pairs and limitations of the dimension of the value given that json as a format does not pose limits we should do that server side. I think it's a front-end job to render the information correctly for the public.
Implementation
Make a decent suggestion and we will deliver it, I think it's important to provide a logic to enable and disable this feature. There can be different approaches:
Scopes & Arrays
Nature of the Values
The system should be agnostic to the value contained. A decision has been made to store the data in additional columns in a jsonb which by now is relatively widely supported. Some preexisting installations might have to upgrade DBs (I am looking at SQLite).
"key1" : "value1" should lead to the same behaviour as "key2" : "value2" without requiring modification inside the code. Reasonable provisions should be taken inside the code base to edit the quantities and content size of key value pairs and appropriate errors should be returned where rate or size limits are exceeded.
Administrative Meta Data
Allow appropriate roles to customize resources with private fields not end-user accessible.
R/W = Read and Write Access
Customer Meta Data
Allowing users to customize an incomplete order (or I'd say a cart) and call the information after a completed order. Admins should in an ideal case be allowed to edit those information after purchase, but I feel that can wait if technical limitations are currently in place.
(Public) Catalogue Meta Data
Data that allows to extend the product catalogue to comply with legal requirements or marketing requirements well aware that surely different use cases will be hacked into it by others in the future. Given that the name Public Meta Data has been sufficiently burned I called it Catalogue Meta Data.
Example 1: Create order
Example Reponse 1: Create order
Original Post
Introduction
Currently custom fields need to be hardcoded into the solution.
There are endless needs to customize orders, for example:
Spree found an elegant and easy to implement approach by creating a metadata storrage inside the primary objects.
Metadata on Spree Commerce
We would sponsor or merge this feature upon guidance from the core team.
Desired behavior
Custom values can be added to an order from front-end using a meta data field in major ressources.
The text was updated successfully, but these errors were encountered: