[COST-7252] Implement constant currency Phase 1

[ELK4N4]

Summary

Implements Phase 1 of the constant currency feature, enabling per-month exchange rate resolution in report queries and forecasts instead of using a single daily rate.

• New models (cost_models app, tenant-scoped): StaticExchangeRate (user-defined rates with monthly validity), MonthlyExchangeRate (single source of truth per month), EnabledCurrency (UI dropdown control)
• New API endpoints: exchange-rate-pairs/ (static rate CRUD), settings/currency/enabled-currencies/ (list/update enablement), settings/currency/available-currencies/ (dropdown source)
• Pipeline changes: get_daily_currency_rates Celery task now discovers currencies, creates EnabledCurrency records, and upserts dynamic rates into MonthlyExchangeRate (respecting static overrides)
• Query handler changes: Base, OCP, and forecast query handlers use Subquery annotation from MonthlyExchangeRate for per-month rate resolution with earliest-rate fallback
• Report metadata: Responses include exchange_rates_applied in meta for transparency
• Cache invalidation: Both static rate writes and Celery task updates invalidate tenant view caches

Test plan

• Unit tests for StaticExchangeRate serializer (validation, versioning, MonthlyExchangeRate side effects)
• Unit tests for StaticExchangeRateViewSet (CRUD operations, filtering, error cases)
• Unit tests for EnabledCurrencyView and AvailableCurrencyView
• Unit tests for MonthlyExchangeRate and EnabledCurrency model constraints
• Integration test: report queries return per-month exchange rates from MonthlyExchangeRate
• Integration test: static rate overrides dynamic rate for overlapping months
• Migration test: seed data populates MonthlyExchangeRate from ExchangeRateDictionary
• Manual test: full on-prem dev env with cost model rates + currency conversion

Made with Cursor

[gemini-code-assist]

Code Review

This pull request implements the Constant Currency feature, introducing static exchange rate management and dynamic rate locking to ensure historical reporting accuracy. Key architectural changes include new tenant-scoped models, a CRUD API for rate pairs, and a transition to subquery-based rate resolution in the reporting pipeline. The review feedback primarily identifies opportunities to adhere to DRY principles by refactoring duplicated exchange rate annotation logic across query and forecast handlers. Additionally, it is recommended to enhance error reporting by specifying missing currency pairs to improve system debuggability.

[codecov]

Codecov Report

❌ Patch coverage is 91.52174% with 39 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.3%. Comparing base (9da32c9) to head (f078f46).

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #6005     +/-   ##
=======================================
- Coverage   94.4%   94.3%   -0.0%     
=======================================
  Files        362     367      +5     
  Lines      32101   32448    +347     
  Branches    3538    3585     +47     
=======================================
+ Hits       30290   30613    +323     
- Misses      1176    1186     +10     
- Partials     635     649     +14     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[myersCody]

You should just combine the migrations.

[myersCody]

It appears you are allowing the customer to select any currency that is in the get_global("all_currencies") library. However, for our dynamic rates logic pulls pulls the exchange rates from: https://open.er-api.com/v6/latest/USD

@ELK4N4 @bacciotti Has anyone done any checking to ensure the list provided by get_global does not include currencies that can not be found in URL we use to grab dynamic exchange rates?

[ELK4N4]

A user can defines a currency that doesn't exist in https://open.er-api.com/v6/latest/USD using static rates

[myersCody]

The current process from what I can see allows user to enable a currency that can not be found in the CURRENCY_URL. Then if they try to utilize it they git a:

{"currency": ["No exchange rate available for <CODE>. Ask your administrator to configure static exchange rates or enable dynamic exchange rates."]}

The problem is that they did enable the dynamic rate, it just can't be supported.

I think we may need some type of validation for the dynamic flow that ensure they currency code is found in whatever url they decide to use? Thoughts?

That way they can "enable a dynamic rate" without being able to get a rate if that makes sense.

[ELK4N4]

I can change the error message to

No exchange rate available for <CODE>. Ask your administrator to configure static exchange rates

if CURRENCY_URL is defined.

In general, I think the enabled currencies capability should be decoupled from the actual available rates as long the list is ISO 4217

[ELK4N4]

I have checked the differences between Babel and the API.
Babel support all ISO 4217 currencies(~300) and the API support only 162.
The exchange rate API (https://open.er-api.com/v6/latest/USD) returns 6 currency
codes that are not in babel's ISO 4217 registry. These are silently skipped
during the exchange rate fetch in masu/celery/tasks.py.

Code	Currency	Territory	Official Currency	Pegged To
FOK	Faroese Króna	Faroe Islands	DKK (Danish Krone)	1:1 DKK
GGP	Guernsey Pound	Guernsey	GBP (British Pound)	1:1 GBP
IMP	Isle of Man Pound	Isle of Man	GBP (British Pound)	1:1 GBP
JEP	Jersey Pound	Jersey	GBP (British Pound)	1:1 GBP
KID	Kiribati Dollar	Kiribati	AUD (Australian Dollar)	1:1 AUD
TVD	Tuvaluan Dollar	Tuvalu	AUD (Australian Dollar)	1:1 AUD

[bacciotti]

I think the design is correct. decoupling "which currencies are enabled" from "which currencies have a dynamic rate" is the right call. however id say we have two things that worth addressing:

1. fix the error message: if saas customer enables a currency thats not in the er-api and tries to use it, they get told to "enable dynamic exchange rates" -> but they already did

2. would be good to, at least, warn the admin at "enable-time". Foe example: if CURRENCY_URL is configured and the currency being enabled isnt in ExchangeRateDictionary, return a warnings field in the response saying, maybe, "this currency has no dynamic rate available, you'll need to configure a static rate before users can use it."

[myersCody]

From the SaaS perspective they don't get to control the CURRENCY url. Therefore, there is no way for them to "fix" it to where they could provide a dynamic rate to the currencies not in the URL. It is probably worth a discussion a team level on how to handle it.

[bacciotti]

after the team discussion, i think we landed on two things that need to be addressed before merge:

1. error message: if a currency has no rate available, the current message suggests enabling dynamic exchange rates, but that won't help if the currency simply isn't in the er-api. the message needs to be clear and actionable, something like "this currency requires a static exchange rate to be configured by your administrator."

2. static-only signal at enable-time: if the currency being enabled isn't in the er-api, the admin should know upfront that it's static only. without a static rate configured, users will hit an error in reports.

the dynamic fallback only makes sense for currencies that exist in the er-api. for everything else, static is the only path, and both the admin and the end user need to know that clearly.

[ELK4N4]

Done

[myersCody]

The symbol and description are directly utilize by our UI. The previous approach utilize Unicode escape sequence for the more complex currency symbols. The purpose around this is because the UX supports multiple locals.

For example:

{
        "code": "CNY",
        "name": "Chinese Yuan",
        "symbol": "CN\u00a5",
        "description": "CNY (CN\u00a5) - Chinese Yuan",
},

Would return CN¥ for en_US local; however, if your local is Chinese it just returns ¥.

This approach forces all customers into the en_US local for currency. A minor change, but also different functionality from our previous approach. Let me ping the team to see if there is any impact to this change that I don't recognize real quick.

[ELK4N4]

Today the UI converts from code to symbol? If that the case I can just returns the code and the UI will do the rest

[koku-ci-triager-bot]

🤖 CI Triager — Warning

Check: Migration convention
Root cause: This PR adds 2 migration files across 2 different apps, which deviates from the one-migration-per-PR convention.

Migrations found:

koku/api/migrations/0072_alter_exchangerates_currency_type.py
koku/cost_models/migrations/0014_constant_currency.py

Action: Since these migrations are in different apps (api and cost_models), they cannot be squashed together via squashmigrations. Please verify that both migrations are necessary for this PR. If one is preparatory or could land separately, consider splitting the PR. If both are intentional and needed together for the constant-currency feature, no action is required — but please confirm with a reviewer.

Generated automatically. Review before applying.

[koku-ci-triager-bot]

🤖 CI Triager — Warning

Check: Migration convention
Root cause: This PR adds 2 migration files across 2 apps, violating the one-migration-per-PR convention.
Evidence:

koku/api/migrations/0072_alter_exchangerates_currency_type.py
koku/cost_models/migrations/0014_constant_currency.py

Action: Please squash the migrations within each app into one. Run:

python koku/manage.py squashmigrations api 0072 0072
python koku/manage.py squashmigrations cost_models 0014 0014

If the migrations are in separate apps and each app has only one new migration, no squash is needed — but confirm that each app has exactly one new migration file, not multiple. In this case, two separate apps each have one new migration, which may be acceptable if they are both intentionally part of this PR. Please confirm with the team that both migration files are required in the same PR.

Generated automatically. Review before applying.

[koku-ci-triager-bot]

🤖 CI Triager — Diagnosis

Check: Units - 3.11
Run: 26178594573
Root cause: test_get_cost_model_rate_rbac_access fails with a DUPLICATE_AUTH error because initialize_request uses self.fake.word() for the OCP cluster_id. Faker's word list has ~40–50 entries; with the test DB preserved across CI runs, providers accumulate until a collision occurs.
Evidence:

ERROR: test_get_cost_model_rate_rbac_access (cost_models.test.test_view.CostModelViewTests)
...
  File "koku/cost_models/test/test_view.py", line 47, in initialize_request
    self.provider = serializer.save()
  File "koku/api/provider/serializers.py", line 318, in create
    raise serializers.ValidationError(error_obj(ProviderErrors.DUPLICATE_AUTH, message))
ValidationError: {'source.duplicate': [ErrorDetail(
  string='Cost management does not allow duplicate accounts. An integration
          already exists with these details.', code='invalid')]}

Action: In koku/cost_models/test/test_view.py, change initialize_request to use a UUID for the cluster_id so it is always unique, regardless of DB state:

# Line ~41 in initialize_request():
# Before:
"authentication": {"credentials": {"cluster_id": self.fake.word()}},
# After:
"authentication": {"credentials": {"cluster_id": str(self.fake.uuid4())}},

This file is not in the PR diff, but the fix is a one-line change. Alternatively, re-run CI with a clean test database (--keepdb=False) to unblock this run.

Generated automatically. Review before applying.

[koku-ci-triager-bot]

🤖 CI Triager — Warning

Check: Migration convention
Root cause: This PR adds 2 new migration files across two apps. The convention is one migration per PR; multiple migrations in the same app should be squashed.
Evidence:

koku/api/migrations/0072_alter_exchangerates_currency_type.py
koku/cost_models/migrations/0014_constant_currency.py

Action: These migrations are in different apps (api and cost_models), so cross-app squashing is not applicable. However, if either app has intermediate migration files, squash them with:

python koku/manage.py squashmigrations api <first> 0072
python koku/manage.py squashmigrations cost_models <first> 0014

If each app has exactly one new migration file, no action is needed — this warning is informational.

Generated automatically. Review before applying.