Hello Cameron,
Attaching an account to a new user should be done through either the AddAccountAssociation HQ method, or with the Linked Account DbObject. I believe the answers in this question will help with discovering those methods and how to call them.
https://community.q2developer.com/question/1511055046169595904/account-association-module-xml-payload#write-post
Recipient and Recipient accounts deal with wires and other transactions, and are not applicable here.
Let me know if ...
In addition to my above comment, there is another way method of adding accounts to a user. There is the DbObject LinkedAccount which has two add functions: add, and add_by_primary_cif. You can see them in the documentation here: https://docs.q2developer.com/api_references/q2_sdk/db/db_objects/linked_account.html#q2_sdk.hq.db.linked_account.LinkedAccount.add
Hello Cameron,
It looks like the account association xml builder function is missing from the documentation, but it does exist in the file. Here is the function signature
def build_account_association_xml(customer_id: int, user_id: int, account_access: int,
host_account_id: Optional[int] = None,
link_by_cif=False, cif_internal: Optional[str] = None,
customer_account_id: Optional[...
Hey Ethan,
Q2 does have a set of Q2Api endpoints that can be used to generate a SAC code and send it to the end user.
https://docs.q2developer.com/api_references/hq_api/q2_api/GetEndUserAccessCodeTargets.html -- Get a list of targets to send the access code to
https://docs.q2developer.com/api_references/hq_api/q2_api/CreateEdvSecureAccessCode.html - Generate the SAC code and send the code
https://docs.q2developer.com/api_references/hq_api/q2_api/ValidateEdvSecureAccessCode.html - Va...
Currently, there is only one way to check if a device is enrolled or not, and that is through tecton. The tecton function checkPushEnrollment will check to see if the current device is registerd or not.
Outside of tecton, there is no way to know if a specific device is regesterd. The PushNotificationTargets DBObject can be used to see all targets for a given user id, and p...
You can access the transaction limits for a group/customer/user by using the GetPolicyDataByPolicyIdentifier HQ call. I have made a seperate post to explain how to use this call and has a link to the SDK documentation.
You can do this with the HQ method GetPolicyDataByPolicyIdentifier (https://docs.q2developer.com/api_references/hq_api/q2_api/GetPolicyDataByPolicyIdentifier.html#module-q2_sdk.hq.hq_api.q2_api.GetPolicyDataByPolicyIdentifier)
In order to use this method, you need to construct the policy_identifier parameter. This can be constructed with a level code and an id, and has a format of “-” which is the level code and id separated by a hyphen.
The level code corresponds to the...
Q2 does not store any sort of relationship information between the current end user and their associated accounts. While the association does exists, the reason behind the association is not stored. You will not be able to gather this information from the Q2 database or associated systems.
If this information is needed, a core call is going to be required to obtain the relationship.
Unique or not unique depends on the key used to stored the information in the Q2 cache. When information is stored in cache, a cache key is needed to pair with the information stored. You can see in the cache section of the online banking tutorial that the the this is done with the self.cache.set function
self.cache.set('key', 'value', 15)
The 'key' is a string value that the key to pair with the information.
Since it is a string, a key that is unique to the end user can b...
The date of birth (dob) for an end user is not something that is typically populated by Q2, and it is not included on the incoming request. There is a dob column on the Q2_User table in the database, but this is often NULL since (as of today at least) Q2 does not have a process for populating that column. To get a date of birth, a core call is typically required.
The suggested workflow for getting the dob is this:
- Using the User DbObject and the user_id in self.online_user.user_id, ...
The short answer to this is Q2 does not store, or have a concept of account relationship. You may have to go to the core to get this information.
The link type that you are looking at is describing how the account is linked to the end user. Link type C means the account is linked via the primary cif and is probably part of a group of accounts that all have the same primary cif value. A link type of A means the account is linked via the account id (Host Account ID) and someone had to dir...
The caliper API is for server to server communication. Calling the Caliper API from the browser is not supported and will not work. If you want to call the caliper API you will need to first call an API on your server and then have that call the Caliper API.
We do not have any limitations on how an SSO connects to the vendor. You should be able to execute the method required by the vendor.
There are many python libraries that should help with the EncryptedAssertion.
Hey David,
It looks like you are trying to hit the extension directly. Can you provide more details about how you are attempting this, and what step you are on in the tutorial?
This is a setting that is set in the database at install. We have not created an "update" for SSO extension yet in the sandbox environment. So in order to update this value in the DB as of now, you need to uninstall and reinstall the SSO. This should update the SSO so it renders in a panel within online.
You can request a key by making a ticket in the developer portial. Key's and instructions will be provided once approved.
There currently isn't a way to do this in the SDK. Looking at the DB, this is somewhat possible, but it isn't exact. There exists a table in the DB called Q2_BrowserReg that contains the browser registration information for Desktop/Mobile. There isn't enough information stored here to say for sure that the user is currently on a new registered device. You can try to pair this with the Q2_Audit table, but that is not a table we like to query from because it is so high traffic.
Starting ...