Currently we have addressID matcher which can accept both addressIDs (from address book) and walletIDs (internal wallets). From now on, this will need to be specified in separate fields:
addressID for addresses in address bookwalletID for internal wallets<aside> ✅
Any existing policies will be migrated automatically and require no action on your part
</aside>
While previously, a single policy having an addressID matcher can take multiple values, each value being either a addressID or walletID, this change will require you to specify two distinct matchers, one containing all addressIDs and another containing walletIDs respectively.
For example, the following policy matcher, where 4a2b6f8b-5077-4d52-8368-07b342c651b3 is addressID and 25ca96e0-9ff5-46d0-9496-2c555593fc99 is an internal walletID, would have been valid before, is now invalid:
[
{
"type": "ADDRESS_ID",
"values": [
"4a2b6f8b-5077-4d52-8368-07b342c651b3",
"25ca96e0-9ff5-46d0-9496-2c555593fc99"
]
}
]
Instead, the new policy matcher will have to have one policy for addressIDs:
[
{
"type": "ADDRESS_ID",
"values": [
"4a2b6f8b-5077-4d52-8368-07b342c651b3"
]
}
]
and another policy for walletIDs:
[
{
"type": "WALLET_ID",
"values": [
"25ca96e0-9ff5-46d0-9496-2c555593fc99"
]
}
]
If you are using APIs to manage your policies, you will need to change the requests in order to fit the new model as described in the behaviour section above.
Particularly, if you are using one policy matcher of ADDRESS_ID to fit addressIDs (from address book) and walletIDs (from internal wallets), then you will need to instead create two policies, one with ADDRESS_ID matcher type whose values contain address book addressIDs only, and another with WALLET_ID type whose values contain internal walletIDs only.
ADDRESS_ID type and WALLET_ID type matchers instead of a single policy