Removes all the guesswork for requisition renewals, instead opting for
the manual approach of simply redirecting to the form and updating its
handling such that it jumps straight to history selection when needed.
When the institution is preloaded (so we skip country/bank selection)
the cloned element is a country and not the bank so we need to replace
athe flag with its logo, but otherwise the code was all moved as-is.
If agreements are already available and no custom `access_days` is
passed, it will simply take the first match regardless of duration.
When a new agreement is needed, it defaults to the max supported.
Implements changes from #10410 but using `Arr::first()` rather than a
foreach loop to fix bugs returning invalid or expired agreements.
If an agreement exists with at least the requested `$txDays` then that
is used, otherwise a new one is created with the given parameters. If it
fails, we error out because `createRequisition()` would fail regardless.
Skips accepting EUAs: seems it's done automatically during requisition.
The cache data is set to expire after an hour, at which point the call
to `$request->getCompany()` will fail because it depends internally on
the `company_key` in the response of `getTokenContent()` which is null.
By moving the company *after* the context check, we avoid the exception
but need to manually set lang as there's no context for company data.
The end user agreement ID isn't stored with the bank integration, but it
*is* returned as part of the error for an expired account which works
perfectly for the case of renewing an expired requisition.
When `tx_days` isn't set in the request (i.e. it's a renewal) we instead
extract the EUA ID from the account error after getting the integration,
then once we have the EUA we're able to restore the old tx_days setting.
Since the BankIntegration query is used in both endpoints, this moves it
to a method with `firstOrFail()` rather than `first()` which also allows
for a cleanup of the integration saving code with try/catch/finally to
make it a little clearer which values apply to both new+existing cases.
All failures boil down to about 3 variations - one with reason/lang, one
that has context defined but no company data, and a full variant that
also fills the company and account keys in the view.
The only other difference is redirect url coming from config when it's
not available in the context, so to simplify things this commit merges
all the failure view responses into one unified `failed` method.
If e.g. `&tx_days=365` is added to the URL, this will use it to set the
amount of history that's fetched from Nordigen on sync, with basic
safeguards to prevent it being set too low or above the bank's max.
While we set the days in the agreement, how many we fetch when
processing transactions depends on the `from_date` of the bank
integration. We could call `getInstitution($id)` on the API, but
consistency would dictate adding a wrapper in the Nordigen class and
it's already being called within `$nordigen->getAccount()` so it makes
more sense to extract the data in the account transformer instead.
App\Jobs\Bank\ProcessBankTransactionsNordigen also sets a from date, but
that's only used when not set on the bank integration so it can be left
at the Nordigen default of 90 days worth of transaction history.
In order to change the total days of transactions we can request, a
custom end user agreement is needed. There *are* methods to find
existing agreements, but assuming nothing else breaks it's probably
fairly safe to just go ahead and create one.
If it works, it only runs once... as far as I can tell.
Removes all the guesswork for requisition renewals, instead opting for
the manual approach of simply redirecting to the form and updating its
handling such that it jumps straight to history selection when needed.
When the institution is preloaded (so we skip country/bank selection)
the cloned element is a country and not the bank so we need to replace
athe flag with its logo, but otherwise the code was all moved as-is.
If agreements are already available and no custom `access_days` is
passed, it will simply take the first match regardless of duration.
When a new agreement is needed, it defaults to the max supported.
Implements changes from #10410 but using `Arr::first()` rather than a
foreach loop to fix bugs returning invalid or expired agreements.
If an agreement exists with at least the requested `$txDays` then that
is used, otherwise a new one is created with the given parameters. If it
fails, we error out because `createRequisition()` would fail regardless.
Skips accepting EUAs: seems it's done automatically during requisition.
The cache data is set to expire after an hour, at which point the call
to `$request->getCompany()` will fail because it depends internally on
the `company_key` in the response of `getTokenContent()` which is null.
By moving the company *after* the context check, we avoid the exception
but need to manually set lang as there's no context for company data.
The end user agreement ID isn't stored with the bank integration, but it
*is* returned as part of the error for an expired account which works
perfectly for the case of renewing an expired requisition.
When `tx_days` isn't set in the request (i.e. it's a renewal) we instead
extract the EUA ID from the account error after getting the integration,
then once we have the EUA we're able to restore the old tx_days setting.
Since the BankIntegration query is used in both endpoints, this moves it
to a method with `firstOrFail()` rather than `first()` which also allows
for a cleanup of the integration saving code with try/catch/finally to
make it a little clearer which values apply to both new+existing cases.
All failures boil down to about 3 variations - one with reason/lang, one
that has context defined but no company data, and a full variant that
also fills the company and account keys in the view.
The only other difference is redirect url coming from config when it's
not available in the context, so to simplify things this commit merges
all the failure view responses into one unified `failed` method.
If e.g. `&tx_days=365` is added to the URL, this will use it to set the
amount of history that's fetched from Nordigen on sync, with basic
safeguards to prevent it being set too low or above the bank's max.
While we set the days in the agreement, how many we fetch when
processing transactions depends on the `from_date` of the bank
integration. We could call `getInstitution($id)` on the API, but
consistency would dictate adding a wrapper in the Nordigen class and
it's already being called within `$nordigen->getAccount()` so it makes
more sense to extract the data in the account transformer instead.
App\Jobs\Bank\ProcessBankTransactionsNordigen also sets a from date, but
that's only used when not set on the bank integration so it can be left
at the Nordigen default of 90 days worth of transaction history.
In order to change the total days of transactions we can request, a
custom end user agreement is needed. There *are* methods to find
existing agreements, but assuming nothing else breaks it's probably
fairly safe to just go ahead and create one.
If it works, it only runs once... as far as I can tell.
This check was added at a time when `getAccount` would return `false`
for failures, but at some point it was updated to always return arrays.
This fixes the check to avoid issues like #10396 where the following
line triggers a missing 'id' key error.
David Bomba
Dave Shoreman
Benjamin Beganović