- Nov 17, 2020
-
-
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 #438 Signed-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.
-
We had a distinction between corporate and business cards, but there are some connections that can have both type of cards. We now will instanciate the corporate browser if we detect that, and will fetch the data from both "sources" if possible
-
-
In this case we must follow the location redirection. This redirection seems happens when some cookies expire and is not alway reproducible. Indeed this url is catched by ConditionsPage and the empty 302 parsing failed.
-
-
-
- the Transaction.Raw was not call in some cases - when called, it correctly set the obj_label but that field was overriden afterwards.
-
-
sometimes there is a typo in the profile name used for the matching of the transactions with the account ex : two spaces between first_name and last "Pablo hargreeves"
-
Regexp crashes if it receives NotAvailable instead of a string. I couldn't find any example of a crash so I just removed the useless default value.
-
Market accounts are separated in a stock and a liquidities account, with the same number. Following a change in the page, we would add '.1' to the ID of both accounts, so there were duplicate IDs. We use the label to add '.1' only to the liquidities accounts' IDs.
-
The previous URL would redirect to this one, but sometimes, if there was only one account, it would redirect directly to this account's details, so we never reached the portfolio accounts page.
-
-
There is now an empty line at the start of the xls documents, so we need to shift the header row by 1.
-
We need to pass CleanText before IsinCode otherwise the codes are not returned correctly
-
The previous syntax for har-to-old was: usage: har-to-old.py [-h] file prefix Change it to: usage: har-to-old.py [-h] file [destdir] - prefix renamed in destdir, as it was not really a prefix but the name(/path) to the destination folder for extracted files - automatically create the destdir folder if it does not exist - if destdir is not provided, use the file name without extension
-
We need to handle this label in the "life_insurance_investments" case so that investments can be fetched properly.
-
These accounts were mistakenly typed as checking accounts.
-
-
-
The LCLBrowser is now a TwoFactorBrowser, the initialization is different from other LCL browsers ("ent")
-