Closed peterbe closed 3 years ago
@Gregoor With Ryan on PTO this week and next this most probably won't go out in Prod. In fact, Prod is still not upgraded so it doesn't even yet have the /api/v1/subscriptions/config/
endpoint.
I think it's safe to merge this. Everyone who wants to use it need to remember to run docker-compose exec web python manage.py migrate
afterwards.
So I think this is safe to merge assuming you approve.
Merging #7923 (ab56632) into master (3c5ba63) will not change coverage. The diff coverage is
87.50%
.
@@ Coverage Diff @@
## master #7923 +/- ##
=======================================
Coverage 83.53% 83.53%
=======================================
Files 131 131
Lines 5498 5498
Branches 463 463
=======================================
Hits 4593 4593
Misses 800 800
Partials 105 105
Impacted Files | Coverage Δ | |
---|---|---|
kuma/api/v1/subscription.py | 95.89% <75.00%> (ø) |
|
kuma/api/v1/tests/test_subscription.py | 100.00% <100.00%> (ø) |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 3c5ba63...ab56632. Read the comment docs.
Fixes #7921
Now all 3 subscription-related endpoints are "protected" by one and the same waffle Switch and all the old waffle Flags are cleaned up.
Here's my reasoning:
/api/v1/subscriptions/config/
can't ever depend on the user. Therefore you can't use a Flag there. It will never make sense.{settingsData?.subscriptionConfig && userData.isStaff && <Subscription ...>}
waffle.Switch
but when performance overheads don't matter at all, thewaffle.Switch
is actually a bit better than env vars because it won't require a new Kuma release the day we want to switch it all on.