Added GTIN and Condition to variant for structured data use#5
Open
rahulsingh321 wants to merge 66 commits intogms-electronics:6060-structured-data-productsfrom
Open
Conversation
While working on the in-memory updater in solidusio#5872, we found the need to change how item totals were being calculated, so that we could mark adjustments for destruction without actually destroying them, while still keeping tax adjustments intact. This change is completely backwards-compatible with the current OrderUpdater, so to reduce the scope of our PR, we wanted to make this change separately. Since the OrderUpdater is already very large, this helps reduce its responsibilities and makes it easier to test this behaviour. We don't see it as necessary to make this a configurable class, but this change leaves that option open in the future. Co-authored-by: Adam Mueller <adam@super.gd> Co-authored-by: Alistair Norman <alistair@super.gd> Co-authored-by: Chris Todorov <chris@super.gd> Co-authored-by: Harmony Bouvier <harmony@super.gd> Co-authored-by: Sofia Besenski <sofia@super.gd> Co-authored-by: benjamin wil <benjamin@super.gd>
I don't know if there's all that much customizing people will perform on this class, but it's easy enough to make it configurable just in case.
rahulsingh321
force-pushed
the
6060-structured-data-products
branch
from
bd12953 to
2136879
Compare
rahulsingh321
force-pushed
the
6060-structured-data-products
branch
3 times, most recently
from
d97fa5a to
e04f42b
Compare
rahulsingh321
force-pushed
the
6060-structured-data-products
branch
from
d6316bd to
e04f42b
Compare
rahulsingh321
force-pushed
the
6060-structured-data-products
branch
from
c8c9ae9 to
e04f42b
Compare
|
@rahulsingh321 please publish as draft till it's ready for review (tests pass) |
rahulsingh321
force-pushed
the
6060-structured-data-products
branch
from
e04f42b to
fe171d4
Compare
rahulsingh321
force-pushed
the
6060-structured-data-products
branch
from
fe171d4 to
fdac605
Compare
rahulsingh321
force-pushed
the
6060-structured-data-products
branch
from
fdac605 to
d44a9dd
Compare
rahulsingh321
force-pushed
the
6060-structured-data-products
branch
from
d44a9dd to
53b229a
Compare
Following changes have been made: - given that the license is identical to parent repository, licensed under was changed - integrated link to migration guide - fixed some wording to give a more positive drive - fixed some typos
The `address1` container incorrectly had the same identifier as the "Check stock on transfer" input checkbox. This fixes the typo, so this container can be referenced in Deface overrides, etc. Co-authored-by: Benjamin Willems <benjamin@super.gd>
This flag is not very useful and gives rise to bugs. It is not very useful, as we only need it to "resurrect" addresses that the user inputs newly, but that match an address that has been removed from the address book in the past for some reason. Why not remove the record from the join table directly? Much simpler, and less code to worry about. The bug we found that exists only because of the existence of this column is the following: If an address is added to the address book that matches an existing user address that is archived, there is a chance of it throwing a uniqueness validation error, because the uniqueness check on user/address on the Spree::UserAddress model does not take into account the "archived" flag. The third reason why I think this should go is for data protection reasons: If I call "delete" on a record, I want it to be gone, not half-gone. And in the case of a join table representing which addresses a user wants to be presented with again, I very much want it gone. Not archived. Note also: Removing this complexity removes explanatory comments in otherwise straight-forward API endpoints.
…ddresses Remove Spree::UserAddress#archived flag
Fixed wording, typos, license notice & linked to migration guide
… and length
Introduced validations and configurable limits for metadata attributes
(`customer_metadata` and `admin_metadata`) to ensure consistency and prevent
overly large or complex structures.
**Implementation:**
- Set default values for `customer_metadata` and `admin_metadata` to empty hashes (`{}`) for proper initialization.
- Implemented validation to limit the number of keys, and the length of keys and values in metadata.
- Added configuration checks to ensure metadata does not exceed the limits defined in `Spree::Config`.
- Introduced preferences: `meta_data_max_keys`, `meta_data_max_key_length`, and `meta_data_max_value_length` to control metadata size:
- `meta_data_max_keys`: Max keys allowed (default: 6).
- `meta_data_max_key_length`: Max key length (default: 16).
- `meta_data_max_value_length`: Max value length (default: 256).
- Created a shared concern to handle metadata validation logic.
- Added tests to ensure default values and validation logic work correctly.
- Created a shared example that can be used in other specs to ensure consistent testing of metadata validation across various parts of the system.
Call the metadata concern to various models to validate and add admin and customer metadata
…tadata handling Update the API configuration to permit the `customer_metadata` attribute across various models, such as orders, payments, shipments, and return authorizations. This change allows better handling of customer metadata within API requests, ensuring consistent storage and validation of metadata attributes. Additionally, it updates the `preference` configurations for models to include `customer_metadata`. **Implementation:** - Added `customer_metadata` to the permitted attributes for several API resources. - Updated various `preference` settings, including `order_attributes`, `payment_attributes`, `shipment_attributes`, etc., to include `customer_metadata`. - Ensured that `customer_metadata` is correctly permitted in the API parameters for each relevant model, allowing admins and users to store custom metadata. - This change improves the flexibility of metadata management within the API, enabling dynamic handling and easier customizations.
User cannot update customer_metadata after the status of order is complete
Introduce the `admin_metadata` attribute to support dynamic metadata handling for admins. It enables configuration of metadata via API preferences, and ensures that metadata fields are properly permitted for admin users through new helper methods. **Implementation:** - Added `admin_metadata` to resources for admins. - Integrated `metadata_permit_parameters` and `metadata_api_parameters preference` in API configuration. - Implemented `permitted_<resource>_attributes` and `<method_name>_attributes` methods for dynamic metadata permissions. - Added `extract_metadata` in `line_items_controller` to handle metadata fields.
This configuration adds the ability to enable or disable metadata restrictions as needed. Following configurations are possible: - `meta_data_validation_enabled` : Enables or disables restrictions globally.
Admin and User Metadata for transactional ressources and users (solidusio#5897)
…tion Revert "Merge pull request solidusio#6122 from mamhoff/create-manifest-js-in-g…
Fix migration typo (missing keyword `foreign_key`)
This rule makes code shorter, but much less understandable.
…from-nav Remove Display Order from side menu
Rubocop: Ignore Rails/Delegate
Otherwise, patching it does not work.
When configuring Flickwerk, we need a way to get at class names without constantizing (i.e. loading) those classes. This adds some specs for the `class_name_attribute` class method on Spree::Preferences::Configuration, and generates a new getter that has `_name` attached to the method to get just the string name.
This stops us from loading line item, order, adjustment, shipment, shipping rate, and the order recalculator on app startup.
This should stop us from loading order, line items, adjustment, calculators, the order updater, product, and shipment on app startup.
Use Flickwerk for loading patches in solidus_promotions and solidus_legacy_promotions
Due to a bug in sprockets-rails[1] we need to manually add the sprockets manifest into the generated rails app before running any rails commands inside the rails app folder. [1](rails/sprockets-rails#546)
Add not about sprockets manifest before running rails commands
tvdeyen
force-pushed
the
6060-structured-data-products
branch
from
2937d9e to
60da551
Compare
Rails 8 does not create a sprockets manifest anymore, but we still depend on it. Since rails commands do not work anymore, because sprockets raises an error if no manifest.js file is present we need to create it in order to be able to run rails new
rahulsingh321
force-pushed
the
6060-structured-data-products
branch
from
60da551 to
df607d8
Compare
…bility ## Background Currently, running `bin/rails solidus_admin:tailwindcss:install` installs the latest v4 of `tailwindcss-rails`. This causes compatibility issues because Solidus Admin expects the Tailwind CSS v3 configuration. Tailwind CSS v4 introduces CSS First Configuration, which alters the structure and handling of the `tailwind.config.js` file. Using v4 results in a configuration where `tailwind.config.js` does not function properly. Reference: https://tailwindcss.com/blog/tailwindcss-v4#css-first-configuration While ideally, Solidus Admin should be updated to work with Tailwind CSS v4 and later, we have restricted it to v3 for now to ensure correct functionality. Additionally, the maintainers of `tailwindcss-rails` do not recommend upgrading to v4 at this time (see: https://github.com/rails/tailwindcss-rails?tab=readme-ov-file#you-dont-_have_-to-upgrade). ## Solution Modified the installation command in `install_tailwindcss.rb` to explicitly install v3: ```ruby unless bundle_command "show tailwindcss-rails" bundle_command "add tailwindcss-rails --version '~>3.0'" end ``` This change ensures that running bin/rails solidus_admin:tailwindcss:install installs Tailwind CSS v3, which is compatible with Solidus Admin's current configuration. If there is anything else that should be added or any improvements that can be made, please let me know.
…v3_to_install_tailwindcss [Admin] Fix tailwindcss-rails Version to v3 for Solidus Admin Compatibility
Fix sandbox command for Rails 8
Summary This commit adds GTIN and Conditions to products to allow a more efficient integration of structured data and the related services such as Google Shopping or Facebook Marketplaces. Changes - Add Conditions and GTIN to products and variants - Added the fields to the Admin Interface - Add the values to API - Provides samples for GTIN (format EAN 8) and Condition (New) to all sample products. - Added Testing of the related fields - feat(i18n): Differentiate GTIN and Condition labels for product and variant forms.
Reflect the changes to the conditions values.
tvdeyen
force-pushed
the
6060-structured-data-products
branch
from
4605ec1 to
de38808
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
12 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Introduction of Structured Data for Item Condition and Global Trade Item Number ("GTIN").
Contained Information
Introduction
This is the first in a series of PRs to implement full structured data support on Solidus.
Structured Data is the common standard to exchange product and content information via the frontend with search engines and marketing platforms and is defined by the schema.org organisation (through the founding companies Google, Microsoft, Yahoo and Yandex).
It has become the defacto standard to communicate with search engines and also many social networks (such as Facebook).
In this first PR following fields are tackled:
This scope of this PR is not to provide structured data on the frontend but merely to provide the information required to generate fully compliant structured data on frontend and feeds without 3rd party extensions or added fields.
GTIN (frequently also known as UPC / EAN in Europe)
Definition
A unique identifier for products usually given by either the manufacturer or the official distributor of a product. Frequently required to have stock listed with marketplaces. It's usually used to identify a product uniquely across multiple steps in the supply chain. While the GTIN is a unique identifier for a product entity it is in no mean a serial number (eg every iPhone of the same model and configuration sold in one country share the UPC, but not the serial number).
It's frequently used to match products in stock synchronizations or order APIs.
Support
Search Engines
Marketplaces
Search Ads
Item Condition
Definition
The item condition has found wide acceptance over the past years to annotate if a product is
While the origins where originally found in second hand marketplaces and the car industry, it became widely used with the emergence of the circular economy.
Support
Search Engines
Marketplaces
Search Ads
Concerns: solidusio#6060
Screenshots Admin Backend
Product
Variant
APIs
Get Product
Update Product
Possible Improvements