How to capture provider offering currency values #9
Labels
No labels
Compat/Breaking
Compat/Deprecation
Kind
Bug
Kind
Chore
Kind
Documentation
Kind
Enhancement
Kind
Feature
Kind
Investigation
Kind
Question
Kind
Security
Kind
Testing
Meta/Good First Issue
Meta/Help Wanted
Meta/Stale
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Status/Needs Triage
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
XeplosionGames/minecraft-provider-analysis#9
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What's the question or topic?
Should
currencymove off the provider level to model providers thatdisplay different currencies per region/product line?
Context / background
Currently
currencyis a single required field onprovider(schemaConvention C) — every price in the file is assumed to be in one currency.
But
price_entryalready carriesregion_idper price, so a providerselling in multiple regions can already vary price by region without being
able to vary currency by region. Today's documented workaround
(docs/capture-guide.md) is: capture in the primary storefront currency and
log the multi-currency display as a quirk.
Decision so far: leave this unchanged for now. Nothing is broken — the quirk
workaround covers it — and fixing it properly touches a lot of surface area
(schema version bump, migrating providers/*.json, capture-form UI, docs,
tests). Revisit only if this becomes a recurring problem in practice.
Options or approaches considered
Option A — currency on product_line: fixes providers where different
product LINES use different currencies. Doesn't fully fix a single product
line whose own prices span multiple currency regions.
Option B — currency on price_entry, alongside the existing region_id: fully
general, handles a single product line priced in EUR for REG-EU and USD for
REG-US simultaneously. More verbose (currency repeated per price line) but
matches the granularity region_id already committed to.
Leaning toward B if/when this gets picked up, since A risks needing this
exact conversation again for a line that spans regions.
Checklist