Skip to content
  1. Apr 26, 2021
  2. Apr 11, 2021
  3. Apr 08, 2021
  4. Apr 04, 2021
  5. Mar 12, 2021
  6. Feb 26, 2021
  7. Feb 20, 2021
  8. Feb 12, 2021
  9. Jan 27, 2021
  10. Jan 18, 2021
  11. Jan 09, 2021
    • Christophe François's avatar
      [bp] Fetch opening date of life insurances · 32e00b53
      Christophe François authored and hydrargyrum's avatar hydrargyrum committed
      32e00b53
    • Olivier Da Rocha's avatar
      [bp] handle account details page not being available · ae823412
      Olivier Da Rocha authored and hydrargyrum's avatar hydrargyrum committed
      Sometimes the details page is not yet accessible for some accounts.
      Prevent crashing in this case.
      ae823412
    • Fong NGO's avatar
      [bp] rework pro website · ec6ccd05
      Fong NGO authored and hydrargyrum's avatar hydrargyrum committed
      Only for "professionnels" connections (current BProBrowser). It is the
      first part of the rework, other changes will come next. What is
      addressed so far:
      
      - login without sca, accounts, history, profile
      
      By the way, it also has the benefit of removing dead code: the variable
      `accounts_and_loans_url` doesn't seem to be used
      
      TODO:
      
      - implement the SCA
      
      - check if there are changes for wealth and bill with appropriate
      connections, and do the changes if needed
      
      - add new account types, etc...
      ec6ccd05
    • Fong NGO's avatar
      [bp] don't raise BrowserUnavailable when login is successful · 2721e516
      Fong NGO authored and hydrargyrum's avatar hydrargyrum committed
      The pro website has changed, and an url '.*voscomptes/identification/identification.ea.*'
      that was once handled as a temporary unvailability page is now an
      expected page of the login process.
      
      I don't know if this url has to be treated the same way or differently for
      the par website, so I decided to override the parent attribute in the
      subclass BProBrowser.
      
      We can also notice the following requests don't work because the pro website
      has changed (a wrong request will typically lead to a deconnection, for
      ex. the next_request auth_page() fails this way), but not for all
      connections (strange), meaning for some connections, the current
      requests work fine. So far I have noticed the current code still works
      for connections from users who have already validated the SCA (but I
      might have missed something else).
      2721e516
  12. Dec 11, 2020