Hide EMP information in Core

Avoid to use EMP information added by the migration process of the EMP

Problem Description

All the information that comes from EMP can not be used by any process or any user until the migration process is completed.

That information (Trades, Beneficiaries, Client, etc) can not be used to avoid inconsistencies between EMP and Core apps.

For this reason, we will need to be able to load all the data from EMP and then at some point enable the clients we want to do testing AB with those clients.

A client would need to be identifiable as an EMP client but also the client must be fully migrated to be activated.

Background

The information of how we are going to do the migration process is defined in this RFC: https://blueprints.ebury.rocks/components/bos/fp-ebury-data-migration/bos-data-migration-fp-ebury/

Solution

A pair of fields should be added into the Models, one stating the client is from EMP and another with the status of the client within the migration process ("IN PROGRESS", "ACTIVE").

Add into the ORM Managers a parent class over all the Models to filter the information coming from EMP.

The ORM EMP Filter Manager is going to be in charge of adding to the queries the proper action to filter EMP information.

The Filter Manager is going to use the field described above to modify the queries to add the proper filters.

A new flag is going to be added to the Brand Model to know if the brand is from EMP or Core, this is going to help in some workflows like to display Core or EMP information in some pages.

Scenarios:

1. In some cases we can check the brand to know if the information is from EMP to filter it.

2. Other cases, like entries not reconciled, independent broker deals, etc. or due to a negative spike in performance, we will add a new field in the models, this new field is going to be populated by the migration process to do the proper filters to hide the information.

This solution is a global and easy one do to, only with this change we are going to add the filter in all the places where we are using the Django ORM.

Alternatives

There is not another alternative that could be achievable in a short time.

Caveats

This Manager solution is going to affect all the workflows we are using the Django ORM, we need to take into consideration the reports where we are doing queries directly to the database.

Operation

EMP information is going to be hidden for the Operation team, so there is nothing to be worried about.

Security Impact

NA

Performance Impact

We need to take into consideration the performance here, because we are going to add more logic into the queries, if the performance impact is high we should add a new field to the Model to be faster and more efficient.

Developer Impact

NA

Data Consumer Impact

NA

Deployment

NA