[Cost Control] Extend configuration format to support dynamic fields

RESOLVED FIXED

Status

RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: salva, Assigned: salva)

Tracking

unspecified
x86_64
Linux
Bug Flags:
in-moztrap -

Firefox Tracking Flags

(blocking-b2g:leo+, b2g18 fixed)

Details

Attachments

(1 attachment)

VIVO new dedicated API (for its new high performance platform referred in bug 875330) to answer balance and other requests need some fields to be dynamic.

Consider the example of the text for the message body. Now it's only a string such as SALDO but the new API requires to include a timestamp and some calculated fields so we need some way to attach functions to the config file.
QA Contact: carlos.martinez
Created attachment 754110 [details]
Moving config files from JSON file in bulild to JS file inside the Usage app

This support dynamic properties as the file is not a JSON but a JS module.
Furthermore, it adds native support for several providers.
Attachment #754110 - Flags: review?(jmcf)

Updated

6 years ago
Attachment #754110 - Flags: review?(jmcf) → review+
Master: 50b1b19861e8c8bcb43086ea71404498cd15d2d0
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Comment on attachment 754110 [details]
Moving config files from JSON file in bulild to JS file inside the Usage app



[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 875330 - Vivo has moved to a new SMS protocol for checking balance.
User impact if declined: high - if the old protocol is discontinued, this feature will stop working.
Testing completed: yes
Risk to taking this patch (and alternatives if risky): moderate - even it could seem a lot of changes, most of them are local refactor fixes. Most important changes only affect Config Manager implementation.
String or UUID changes made by this patch: none
Attachment #754110 - Flags: approval-gaia-v1?
(In reply to Salvador de la Puente González [:salva] from comment #3)
> User impact if declined: high - if the old protocol is discontinued, this
> feature will stop working.

Sounds like this may be leo+. What's the timeline on this cutover? What testing will be completed prior to uplift?
blocking-b2g: --- → leo?
tracking-b2g18: ? → ---
This should be before June, 7th. See meta bug 875330 for details. Specifically, this change does not involve any major change (despite the size of the patch). Unit tests regarding start-up have passed so its risk (measured in potential regressions) is low. What do you think?
Flags: needinfo?(akeybl)
Sounds like we need this as soon as possible - let's leo+ instead.
blocking-b2g: leo? → leo+
Flags: needinfo?(akeybl)
Attachment #754110 - Flags: approval-gaia-v1?
I was not able to uplift this bug to v1-train.  If this bug has dependencies which are not marked in this bug, please comment on this bug.  If this bug depends on patches that aren't approved for v1-train, we need to re-evaluate the approval.  Otherwise, if this is just a merge conflict, you might be able to resolve it with:

  git checkout v1-train
  git cherry-pick -x -m1 50b1b19861e8c8bcb43086ea71404498cd15d2d0
  <RESOLVE MERGE CONFLICTS>
  git commit
Flags: needinfo?(salva)
After uplifting bug 846258, this applies smoothly:
v1-train: 0cc292a9b54fa0145e525c25f206fd50085ee059
status-b2g18: --- → fixed
Flags: needinfo?(salva)
Flags: in-moztrap-
You need to log in before you can comment on or make changes to this bug.