The result of the parsing was overriden by obj_label.

Some connections now have loan rates using the '1.123' format so we must
handle both cases (French and SI) otherwise the rates are not fetched at
all.

Some internal recipients can have the same label and same owner, this
caused some duplicate ids since we generated the internal recipients ids
base on those values.

caissedepargne website navigation is broken when you go on "mes
épargnes" for these users. The solution is to do a login again.

Necessary to adapt to changes in parent.

Necessary to adapt to changes in parent.

During login the BASEURL changed and we are not able to do login again.
Consequently the baseurl is added for these pages to avoid navigation on
the bad domain.

Loan balances are displayed with a positive amount on the website.

We cannot fetch details for Investments with a "https://epargneentreprise.axa.fr" URL
because it leads to a Connectionerror even in on the website.

Ent browser has been properly separated from Par browser
in a previous commit.
They now only share login part through a separate login class.
But the module globally calls for iter_market_orders,
which has sense for Par and Pro, but not for Ent.

cfep stands for Compte d'Epargne Financière Pilotée.

CMSO has previously mistakenly switched 'code_verifier' and 'code_challenge'.
For most child modules it is now in the ritgh order, but not for all.

Now the code that calls for 'code_verifier' and 'code_challenge' making,
is put in a separate function so it can be switch in the wrong order if
needed, in a child module.

2FA has been activated for Entreprises clients.
We can abstract Particuliers handling of TwoFactorBrowser,
the same way it is done for Pro clients.

Also Pro and Ent browsers needed some refactoring.
Common login part in SGPEBrowser now uses
login and 2FA handling from Par browser for both.

Some users encounter those.

For now, transactions were fetch on a month by month basis.
Each month would display transactions with at least one type of id
among 2 possible, and those are collected.
Finally, a global history page is parsed, without month param.
A special condition would avoid duplicates based on the ids.

But at the turn of the month there are transactions that
don't have any id, and so would not be selected.

Solution:
First page fetched is the 'SIX_DERNIERES_SEMAINES'. All transactions from
current month are selected here (they don't bear any id).
Then the month by month selection is done.
No final page without month param is fetched at the end since we
already got all transactions.

Tested also on CMB and BPE child modules.

The previous method used the account label and owner to find it on the
market accounts page. However sometimes the same owner can have two
accounts with the same label, and the matching fails. This was used to
fetch invests, history and market orders, but also to determine the
account's id.

We can get the same id from the accounts page so we do that instead and
we use it for the matching.

Example:

```python
amount = Coalesce(
    CleanDecimal.US('//xpath', default=NotAbailable),
    CleanDecimal.US('//xpath2', default=NotAvailable),
)(self.doc)
```

If one of the CleanDecimal returns NotAvailable and the other '0.00', with
the current behavior, Coalesce will crash with "All falsy and no default"
because we use "if value" in the loop of the filter.

With empty(value), Coalesce accepts 0.00 as a valid value for numeric
elements.

Boobank does not "pre set" a recipient.id of the recipient object it
creates to add a new recipient.

So, trying to match the new list of recipients with the new recipient by
id will fail.
We match with iban instead, as an iban is mandatory to add a recipient
anyway.

When adding recipients, sometimes the process would successfully go to
completion but an error "Recipient not found" would be raised at the
final check.
(ie when we check that the newly added recipient is inside the
recipients list)

The origin of the problem is that on Boursorama side, the recipient list
is global for all accounts.
But for some accounts, the recipient list is prefixed (ex. saving
accounts) or transfer is not allowed (ex. market accounts).

Before, the "origin" account that was used to add the recipient was
selected in a random way as "the first account retrieved by
get_accounts".
This was not good as, randomly, an unusable account could have been
selected, like saving accounts.

Boobank does not select an origin_account_id, but if it is the case, we
also have to ensure that the account is valid to add the recipient.
And so, avoid to fail in an unexpected way.

Rows with label 'Remboursement' were filtered out but it's not the only
one that isn't a market order. Instead we filter out rows with no
details link since market orders do have a link.

I misunderstood the issue with duplicate IDs in the portfolio accounts
page. The issue is that liquidities accounts which were fetched on the
main accounts page are now also on the portfolio page. Because of this
change we fetched them twice.

This commit reverts the change on account IDs on the portfolio page and
ignores the liquidities accounts on this page.

Opening date titles may vary so we must handle both with Coalesce.

Users under 18 can't access their accounts, we raise
NoAccountsException.

Fixes #438Signed-off-by: Benjamin Bouvier <public@benj.me>

For a given web request, there use to be 2 metadata files generated:

    001-200-3-request.txt
    001-200-3-response.txt

But, there is a typo in the code, and instead the generated files are:

    001-200-3-request.txt
    001-200-3.response.txt

This change fixes the typo to get back the original behavior.

SMS validation can occur when a user just registered a new phone to use
the app validation one.

For some connections the valuations are displayed in the US Format
(€100.00) instead of the French format so we handle both cases with
Coalesce.