Looks like the function expects a int and will throw that error if an int is not passed.

https://docs.q2developer.com/_modules/q2_sdk/hq/db/host_transaction_history.html#HostTransactionHistory.get

You are likely passing a string, should be able to use the int() function to cast the string to an int.

https://docs.python.org/3/library/functions.html#int

Depends on your intended purpose. If you want to see how q2 add_new_account does it, the code can be seen here: https://code.q2developer.com/Q2Antilles/q2-sdk/-/blob/develop/sdk/q2_sdk/entrypoints/add_new_account.py

But it should be known, this is only useful in dev. This is not how accounts get created in actual environments. In actual environments accounts are created on the Bank's core and at login, the account is pulled and loaded into the Q2 DB.

There are currently no table elements. <table> HTML will inherit some basic CSS but no additional components.

it doesn't create one, you would just generate one and put it in vault and then read it from the code for development purposes. Then when it comes time for actual environments either you or us could generate them but we would still put them in vault.

Quick rundown of the fields:

        "AllTransactionType": indicates type of transaction (0 = Posted, 1 = Memo, 2 = Insufficient Funds
        "TransactionID": Q2 ID for this transaction (unique per FI)
        "HostAccountID": Q2 ID for this account (unique per FI)
        "PostDate":  date transaction posted on the core.
        "TxnAmount": unsigned amount of transaction
        "Description": description of the transaction from the core
        "HostTranNumber": Core ID for th...

Looks like this is an open issue with create react app (https://github.com/facebook/create-react-app/pull/11752) There is suggestion for a work arounds here: https://stackoverflow.com/questions/70599784/failed-to-parse-source-map

Hey Dario, we don't have any of those services available to you out of the box. Without knowing the specific details of what dnyatrace requires, we have seen partners successfully instrument their code with other libraries.

Implementation should be the same as it would be if you were instrutmenting you code outside of our system. Often times its installing a pip or npm package, initializing it and then adding the instrumentation end points to your code.

If it is sending data from our se...

David this is infact a bug. We will get this addressed ASAP. It is unfortunately a bug in the UUX platform. This will be fixed in version 4.4.0.130 of that.

Yes it is possible but there are some requirements that need to be met by the exterbal site.

The setup and requirements are discussed here:

https://docs.q2developer.com/guides/frontend_development/enhanced_sso.html

1. Since the user will be logging into digital and mobile banking and then clicking a link to your service, IdP initiated SSO is the flow that is needed. As discussed on this page, SP initiated SSO is possible to be support by implementing a series of redirects: https://docs.q2developer.com/guides/frontend_development/sso.html#sp-initiated-sso-approximation
2. Not required.

It should have been removed by q2 uninstall. I do see that extension is uninstalled now, not sure why it wasn't removed when you uninstalled it. Possibly because of some of the initial other attempts.

None the less, it is gone now.

For reference, the script is placed in a UiConfigPropertyDataElement/UiConfigPropertyData entry. The Element name is "Q2_SECURITY_SECURITY_THIRD_PARTY_HTML_BLOCK" ... you can lookup the PropertyID of that in UiConfigPropertyDataElement table and then take ...

My recommendation for this would be:

1. These "questions" are basically 2nd passwords with hints. They are not 2FA. They should be treated like passwords. Storing in UserData is probably the best location. They need to be hashed and not stored in plain text. argon2 is generally considered the best password hashing algorithm these days. https://argon2-cffi.readthedocs.io/en/stable/ Bcrypt is a good alternative if for some reason argon2 is not possible.

2. Store the list of possib...

Hey Kenny,

thats just the namespace of the API url. Yes it is used regardless of channel (mobile, desktop, app, etc).

DOB is a relatively new field for us as we've not historically need it. For Financial Instutitions, they can call the core and retrieve it there. But for partners who want their integration to work with lots of financial instutitions, the data needs to come from the Q2 DB.

We have started to bring in that data for some FIs. Note that you will still need to support DOB not being present at all since that is still very common.

Introduce a DB Config so we can switch between the two possibl...

These would be what we call "HostAccountDataElements" or "HADES".

Their presence will vary from one FI to another, also possibly vary from one product type to another. But they are available, unfortunately not on the incoming request. But a simple call will get you what you need. The data is returned in not such a great structure so just need to loop to get it into an easily accessible structure:

from q2_sdk.hq.hq_api.wedge_online_banking import GetUserAccountList

...
    acco...

Cookies set in this manor are specific to not only the domain but the full path of the URL. Since the SSO response runs on a url like https://stack.q2developer.com/sdk/partner/mobilews/sso/vendor/3 ... the cookie will only be available at that full URL.

Instead, the "path" parameter should be added to the cookie string to set it at the root level for that domain:

document.cookie = "{}={}; path=/";

Hey Swarup, there are a number of different ways to architect this to avoid code changes for basic updates like you described. Really depends on the requirements and if everything needs to be dynamic or just the common stuff.

1. For text updates it is recommended to use either UiText (https://docs.q2developer.com/api_references/q2_sdk/db/db_objects/ui_text.html) for SSR extensions or use Tecton's localization setup (<q2-loc></q2-loc> or the [te...

Hey Mark, thanks for the request. Nothing currently possible today but the mobile team is evaluating it for future uses.

Indika, instead of trying to calculate the right expiry time. Our suggestion is to prefix the "key" with the self.online_session.session_id. That will generate a new key with each session.

Our recommendation to acomplish this would be to build a widget for the landing page (https://docs.q2developer.com/guides/frontend_development/widgets.html) and use its execution to launch a modal (https://cdn1.onlineaccess1.com/cdn/base/tecton/v1.9.8/Documentation/index.html#/capabilities/showModal) or overpanel with the tecton javascript.

There would be no UI to the widget itself, just Javascript to launch the modal or overpanel.

The way that Okta does this is that it creates a "bookmark" which will effectively send the user to a SP url (no authentication), the SP recognizes that and redirects the user back to an IdP URL, that IdP URL initiates the authentication request to the SP.

Basically the flow is still initiated from the user in the IdP but the IdP will just throw the user to the SP and have it redirect back.

Hey Vito,

Thanks for the question. The short answer is yes, the URL would be unique for every FI. The longer answer is that I think it doesn't much matter. My expectation of what that IdP Sign Sign-On URL is used for is when the end user shows up at the Service Provider (your app in this case) and is not current signed in, your app would use it to redirect the end user to the IdP Sign-On URL. This is not a likely scenario with our OLB SSOs so I would think that setting could be left blank ...

Swarup's suggestion is a good one and easy enough to support if you need a specific value for each FI. But, if you just need a unique idetifier then we would suggest using the FI's ABA. The FI's ABA is available in self.hq_credentials.aba

Pre4.4 only, you can use icons from this set:

You would use them like this:

<span class="icon-home-5"></span>

If you need a basic slider I would recommend using the standard HTML element:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range

We do not currently have those classes in the default tecton style sheet. I will write a ticket to get that added. I the mean time the break points tecton uses is:

$breakpoint-xs: 480px !default;
$breakpoint-sm: 768px !default;
$breakpoint-md: 992px !default;
$breakpoint-lg: 1200px !default;
$breakpoint-xl: 1400px !default;

this style tag could be added to get those css classes where items are hidden on below certain widths:

<style>
@media screen and (max-width: 7...

The "contract" the build pipeline has with your app is that the it will go into all of your frontend directories and run 'yarn build'. yarn build can do whatever you want/need it to do. The only requirement is that all of your resulting JS/HTML/CSS files end up in the "dist" folder at the end.

Anything that happens between yarn build and the final output is up to you. If you need a specific NPM version, we use NVM so you can specificy a specific version using a .nvmrc file in your fronten...

Here’s our public IP range:

192.0.48.0/20 which is:

192.0.48.1 - 192.0.63.254

Generally, all of our outgoing traffic will come from the following IP’s:

Austin: 192.0.53.21
Dallas: 192.0.61.21
AWS USE1: 192.0.55.0/28 (192.0.55.0 through 192.0.55.15)
AWS USW2: 192.0.62.0/28 (192.0.62.0 through 192.0.62.15)

Our development server is: 35.188.120.54

There are two options. Neither option really exposes "is the other app installed?" to you the developer, instead the OS handles the routing.

If the other app implements Universal Links (https://developer.apple.com/ios/universal-links/) or App Links (https://developer.android.com/training/app-links) you would simply use tecton.actions.openURL('http://www.universallink.com', );

https://cdn1.onlineaccess1.com/cdn/base/tecton/v1.4.2/Documentation/index.html...

Lisa, yes LastChanged on the UserLogon object will be the last time the password was changed for that logon.