feat: Tan request on FinTS Login

[pgruener]

Hi, as suggested in the erpnextfints repo, I've applied the changes to kefiya.

Was I pity, that I didn't find that repo earlier.

What I dont get, is the correct data model between invoice-payment entry/payment entry reference/journal entry-bank transaction. As erpnextfints did create Payment Entries, while this repo creates Bank Transactions instead of it.
So when changing, the system behaviour needs to be adjusted as well.. but is the Bank Transaction really the correct thing?

I might get out of time for the next weeks, so if you like the added features, but have some complaints, feel free to adjust it directly.

[wojosc]

thank you for your input. We have switched to Bank Transactions over Payment Entry as this follows the ERPNext standard process. Many data values are already present in Bank Transaction and you could now even only use the FinTS part of our app and run ERPNext Standard Reconciliation process. Our pages Bank Transaction Wizard and Bank Account Wizard are just an extra that is built on customer requirements and speeds up the process maybe.

Thank you for your contributions, we will look into them. Is it possible for you to share some screenshots and a list of the process for us to better understand your contribution? Thank you.

[pgruener]

yes.. it's nothing special, but I'll show it. Does the current version still work for your bank account? I wouldn't have been surprised, if time was over without a 2nd factor and I didn't notice anything similar in the repo yet.

So in the meantime it is necessary now to gather and persist a valid Client State (stored_client_state) , which can be used in background tasks to read the records.
To retrieve a valid client state, for my bank it is necessary to provide a valid TAN during the "login handshake". In this status there will be two more states available, which needs to be persisted: stored_dialog_state & stored_tan_state.
Those will be required to continue the "dialog" with the requested TAN.
The Properties are located in the previously available Hidden section. For debugging or transparency purposes I've added timestamps for each of the state to the Account Settings section.

This view shows a valid connection, while the Client Status was persisted with a timestamp and the other statuses are gone, as they were resolved earlier.

With the button "Reset Connection" those properties can be cleared, to make a re-login necessary.

When trying to load the accounts now, the TAN mode will be requested first (if the available ones are more than 1, otherwise this step is skipped, or at least should be skipped, I didn't have a chance to really test it):

After I chose "pushTAN 2.0", my smartphone's banking app requests me to activate a slider. After I solved this challenge, I can proceed with this dialog:

If I had chosen the common "pushTAN" a Dialog with a TAN Input would have appeared instead.

During those open Dialog and TAN request, the corresponding state properties keep the binary values (encrypted), to continue the communication in an asynchronous way (which is necessary within stateless http sessions).

So that's actually it.

When the TAN challenge was solved successfully, the Status fields are updated. That enables the app to gather bank account records for a while (I've found some resources, where the time is meant to be limited to 90days. I'll see it, but since I did the change (2-3 weeks now), it kept being valid).