Store metadata for solidus resources

[shahmayur001]

Summary

This implementation extends the Solidus framework to add metadata support across multiple Spree resources. It involves database migrations, model enhancements, attribute updates, API configuration, and comprehensive testing to ensure robust functionality.

List of Resources
The following Spree resources are configured to support metadata fields:

• spree_orders
• spree_line_items
• spree_shipments
• spree_payments
• spree_stock_movements
• spree_addresses
• spree_refunds
• spree_products
• spree_customer_returns
• spree_stock_locations
• spree_store_credit_events
• spree_stores
• spree_taxonomies
• spree_taxons
• spree_variants
• spree_users
• spree_return_authorizations

Database Schema Updates

To support metadata, two new JSON/JSONB columns (public_metadata and private_metadata) are added to each of the above resources.

Migration

class AddPublicAndPrivateMetadataToSpreeResources < ActiveRecord::Migration[7.0]
  def change
    %i[
      spree_orders
      spree_line_items
      spree_shipments
      spree_payments
      spree_stock_movements
      spree_addresses
      spree_refunds
      spree_products
      spree_customer_returns
      spree_stock_locations
      spree_store_credit_events
      spree_stores
      spree_taxonomies
      spree_taxons
      spree_variants
      spree_users
      spree_return_authorizations
    ].each do |table_name|
      change_table table_name do |t|
        if t.respond_to?(:jsonb)
          add_column table_name, :public_metadata, :jsonb, default: {}
          add_column table_name, :private_metadata, :jsonb, default: {}
        else
          add_column table_name, :public_metadata, :json, default: {}
          add_column table_name, :private_metadata, :json, default: {}
        end
      end
    end
  end
end

PR Model Configuration
A shared concern Spree::Metadata is introduced to handle serialization and facilitate operations on the metadata fields.

Concern Implementation

module Spree
  module Metadata
	extend ActiveSupport::Concern

	included do
  	  store :public_metadata, coder: JSON
  	  store :private_metadata, coder: JSON
	end
  end
end

Attribute Configuration

The public_metadata and private_metadata fields are incorporated into the Spree attribute system.

Permitted Attributes

@@metadata_attributes = [private_metadata: {}, public_metadata: {}]

ATTRIBUTES = [
  :address_attributes,
  :address_book_attributes,
  :checkout_address_attributes,
  :checkout_delivery_attributes,
  :checkout_payment_attributes,
  :checkout_confirm_attributes,
  :credit_card_update_attributes,
  :customer_return_attributes,
  :image_attributes,
  :inventory_unit_attributes,
  :line_item_attributes,
  :option_type_attributes,
  :option_value_attributes,
  :payment_attributes,
  :product_attributes,
  :product_properties_attributes,
  :property_attributes,
  :return_authorization_attributes,
  :shipment_attributes,
  :source_attributes,
  :stock_item_attributes,
  :stock_location_attributes,
  :stock_movement_attributes,
  :store_attributes,
  :taxon_attributes,
  :taxonomy_attributes,
  :user_attributes,
  :variant_attributes,
  :metadata_attributes
]

Strong Parameters

def permitted_product_attributes
  permitted_attributes.product_attributes + metadata_attributes + [
	product_properties_attributes: permitted_product_properties_attributes
  ]
end

API Configuration

preference :product_attributes, :array, default: [
  :id, :name, :description, :available_on,
  :slug, :meta_description, :meta_keywords, :shipping_category_id,
  :taxon_ids, :total_on_hand, :meta_title,
  :private_metadata, :public_metadata
]

Testing

Add unit tests to verify the functionality of metadata fields.
RSpec Example

describe "metadata fields" do
  subject { described_class.new }

  it "responds to public_metadata" do
	expect(subject).to respond_to(:public_metadata)
  end

  it "responds to private_metadata" do
	expect(subject).to respond_to(:private_metadata)
  end

  it "can store data in public_metadata" do
	subject.public_metadata = { "delivery_required" => "no" }
	expect(subject.public_metadata["delivery_required"]).to eq("no")
  end

  it "can store data in private_metadata" do
	subject.private_metadata = { "preferred_delivery_time" => "n/a" }
	expect(subject.private_metadata["preferred_delivery_time"]).to eq("n/a")
  end
end

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

• I have written a thorough PR description.
• I have kept my commits small and atomic.
• I have used clear, explanatory commit messages.

The following are not always needed:

• 📖 I have updated the README to account for my changes.
• 📑 I have documented new code with YARD.
• 🛣️ I have opened a PR to update the guides.
• ✅ I have added automated tests to cover my changes.
• 📸 I have attached screenshots to demo visual changes.

[fthobe]

Aims at solving #5951

[boomer196]

Aims at solving #5951

Thanks for submitting this to the team! It is something I was hoping for as well. I have been watching the issue #5897 you opened.

[fthobe]

Aims at solving #5951

Thanks for submitting this to the team! It is something I was hoping for as well. I have been watching the issue #5897 you opened.

Hey,
could you elaborate on your use cases in a couple of lines?
There are some discussions on the various ends and means of this PR.

[boomer196]

Aims at solving #5951

Thanks for submitting this to the team! It is something I was hoping for as well. I have been watching the issue #5897 you opened.

Hey, could you elaborate on your use cases in a couple of lines? There are some discussions on the various ends and means of this PR.

Sure, basically I am hoping to have Solidus support something similar to the Metafields concept that Shopify has. I am just getting started with the platform, so I still have lots to learn, but when I saw the issue you opened, I felt like the "metadata" concept was something that would be a great addition to the core. I personally like the idea of having somewhere to store "structured" data on these objects that the core system doesn't really need to care about, but that storefronts can utilize.

[fthobe]

Sure, basically I am hoping to have Solidus support something similar to the Metafields concept that Shopify has. I am just getting started with the platform, so I still have lots to learn, but when I saw the issue you opened, I felt like the "metadata" concept was something that would be a great addition to the core. I personally like the idea of having somewhere to store "structured" data on these objects that the core system doesn't really need to care about, but that storefronts can utilize.

What resources do you think need it most and why?

[jarednorman]

Product, variant, order, line item, and shipment would be reasonable defaults. They are the most important core models and my experience they are the records that need additional fields in the broadest number of cases.

[fthobe]

Product, variant, order, line item, and shipment would be reasonable defaults. They are the most important core models and my experience they are the records that need additional fields in the broadest number of cases.

Ok, given your pref for products and transactions also returns and RMA requests make sense at this point. Can you live with them + users and I stop bugging you?

[kennyadsl]

Honestly, I don't think it's super important on which models we will add those metadata fields for the core. What's more important is creating a developer-friendly journey to add more of them when needed. What I envision for the success of this initiative is:

• An easy way to add this metadata on any model. What about something like rails generate solidus:add_metadata Spree::Product? This task will generate a migration that adds the jsonb column to the corresponding table. It will probably do more with time, but that's already a good start.
• Create a solid definition for the metadata. It might contain the type and the access level, something like:

{
  "key": "serial_number",
  "type": "string",
  "value": "123abc",
  "access": "public", // Can also be the roles which have permissions, like "admin"?
  "api": true // If we want this field to be included in the REST API payloads
}

• Admin UI for resources with the metadata field. When the metadata is present, the Admin UI is smart enough to add a new section that allows operators to set those fields, with a different rendering based on their type. See what we did in the legacy admin for preferences here. Something similar would work, and can be extended if there are custom needs of extra types.

With these three elements, we have enough flexibility and we don't have to assume anything on where the fields are needed, which is without doubt something that dramatically changes from store to store.

[fthobe]

@kennyadsl i really feel strongly about the admin part being a @MadelineCollier task. She's deep into that right now and it would take us much more time to do that. Can we slip that into her existing work?

[kennyadsl]

She's deep into that right now and it would take us much more time to do that. Can we slip that into her existing work?

Yes, but it needs to be prioritized with the rest of the tasks in that case. By the way, the feature can live without the admin part, and we can add that later, isn't it?

[fthobe]

For me it's an API feature with read only admin

[fthobe]

Product, variant, order, line item, and shipment would be reasonable defaults. They are the most important core models and my experience they are the records that need additional fields in the broadest number of cases.

Given how addresses are made implications should be documented. For how it works now, would two addresses with different metadata create two different addresses or one address? @jarednorman