Frontend analysis for FlexiForward

We are making an overview analysis about incorporate the new FlexiForward product into the Ebury frontend pipeline. Understand that this analysis is based on the decision of FlexiForward RFC where the FlexiForward will be a type of ForwardDeal model.

We dont think the new_deal page is able to accept more products, so maybe this product should be considered the last one to get into the now already quite complex workflow. Please pay attention to the alternatives section.

Problem Description

BOS's new_deal page includes a lot off different product types in the same view, so we want to do the changes with the least affection to other products's workflows. Both backend view and frontend scripts follow their own pipelines in order to produce the required trade.

Along with the change in the new_deal page, we also need to do small changes on some other pages in the rest of the frontend to include the new product type. Understand that this RFC will not cover all changes needed to include the new product all around the whole system.

Background

Reuse the new_deal page to include the new product type FlexiForward and update the rest of the BOS's frontend to correctly display the new product.

Solutions

new_deal

• BACKEND

• FlexiForward, trade type

  

  In the current new_deal backend the flow is a bit long but its reusing most of the parts for the two forward types. It could be more or less easy to insert the specifications of the FlexiForward new type into this workflow without too much hassle and without breaking the previous forward types. Understand that this current flow is a bit fragile because of all the different things we have added over the years. So I recomend a lot of manual tests for the rest of forward types for any change in the new_deal.

  Most of the times the distinction between fixed and window forwards are made with if statements like so:

  python if request.POST.get('type', '') == "fixed": logger.info("Handling fixed forward in posting") context['initial_tab'] = TABS_NUMBER['fixed']

  Or like so when we are inside the forms:

  python if fwd_form.cleaned_data['type'] == "window": bd.broker_contract_type = "windowforward" else: bd.broker_contract_type = "fixedforward" if fwd_form.cleaned_data.get('is_cover_broker_deal'): bd.is_cover = True

  So the if/else pattern is no longer valid so a deep code review must be done so we can correctly get all the different forward types and not assume.

• Drawdowns for FlexiForward, trade type

  The case for drawdowns in more difficult to tackle.

  The flow in backend to create Drawdowns is similar to the forward but using different forms files.

  The change is deeper tho because we have to include an accept rate functionality like we have in SpotsDeal. That initial_rate should be applied to the new created SpotDeal and not the rate from the parent ForwardDeal.

• FRONTEND

• FlexiForward, trade type

  

  In the case of new_deal frontend is the same scenario, the flow is common for all types of deals and it depends on the type of product a different javascript file is used.

  At first it as product requirement it was considered that the best option was include FlexiForward product as a dropdown selector in the fixedforward tab.

  • On one side, the FlexiForward is similar to Fixed because it can be contracted since day 0
  • On the other side, is similar to window because it can have an indeterminate number of drawdowns. Moreover sales team is used to contract the FlexiForward deal using the windowforward tab and then composing the contracted product using other products.

  That together with the fact that fixedforward tab has Strip/OTC Forward option not needed in FlexiForward makes it stronger candidate so use the windowforward tab as the selected choice.

  Pay special attention to the backbone models defined in new_deal_models.js depending on the type of model for FlexiForward we have up update it accordingly. since that backbone prototyping was created in a composable way maybe the changes are not big but that has to be looked at in detail.

  Found that there are some functions are duplicated in the different javascript end files, but they are exactly the same. I propose to have them all together in the same javascript file. (maybe new_deal_tabs.js or a new file with shared logic.)

  Again in the case of the frontend the flow for both forward types is common and should remain the same (if we use the ForwardDeal model). In the other case we have to create a new flow for that new trada type.

  Finally we have to pay special attention to the drawdowns dropdown table in the forward details or new drawdown view, because FlexiForward Drawdowns most of the times have different rates than the parent Forward. I sugest in this case to include the rate at Drawdown level and don't make any distinction for FlexiForward to other forwards, so its the same table for all three types of forwards.

• Drawdowns for FlexiForward

  The flow in javascript for the Drawdowns is similar to the forward so again like in the backend part the concerns are the same.

  Same decisions have to be made when updating the new_deal_models.js regarding the model prototype for Drawdowns for FlexiForward.

  Also again the functionality for the rate for new drawdowns when they are Drawdowns for FlexyForwards has to include all the logic to get and contract rates, also include that in the form so they are correctly populated in the model.

Trade Details Page

Since are using ForwardDeal as base class, then it would be very simple and just use the existing forward_deal view.

Client Details Page

Include the new forward type in the trades search form

Include the flexi type in trade_type_tooltip

Make sure the add drawdown (option on the right), works ok with the new FlexiForward and rest of forwards.

TradeLog

No change would be needed in the model, the tradelog has open string description, but it would be necesary to take modify the tooltip in trade_type_tooltip

Security Impact

One of the requirements in the epic, includes an specific permission group to manage FlexiForward product, the idea about that is to be able to use it as a switch to be able to deliver the new product in phases and not disturb the normal Ebury's workflow.

As soon as the epic is considered correct for the whole sales department we will remove that constrain and leave it for the whole sales department.

There is no other security impact involved, because the rest of security conditions apply like all the rest of products.

Performance Impact

Not relevant, we can not foresee any performance issue other than requesting more tables when trying to retrieve an specific deal

Developer Impact

Please pay attention to all the times we are representing ForwardDeal objects, until now we have a binary situation where the Forwards can be of only two types and so in the code we are assuming that if its now an specific type should be of the other.

Data Consumer Impact

None detected.

Alternatives

In the RFC we are using a fast way to develop the new product, but if we want to be more ambitious we could have as an alternative a more products tab where on click a modal window pops up and the operator can decide the type of product they want to create.

The idea for that is to avoid reusing the new_deal view to add more products, because on the long term that will be contraproductive. It's better to have a more composable system where the flow is the same for all the products but the templates and final products are different.

Deployment

Already mentioned in security, this new product will be switched out by permission groups and no specific deployment will be needed other than the required database migration for that new permission group.

Dependencies

This RFC depended on TFT-1971 because its for the same product but about the modeling and backend perspective.