Activate Per Tenant Settings Feat and use ACA-Py 0.8.2 image

[shaangill025]

• Follow-up to Placeholder UI for to-come ACA-Py per-tenant settings #580

[github-actions]

Deployment	Resource	Location
Traction
	Tenant UI	https://pr-682-tenant-ui-dev.apps.silver.devops.gov.bc.ca
	Innkeeper UI	https://pr-682-tenant-ui-dev.apps.silver.devops.gov.bc.ca/innkeeper
Aca-Py
	Admin Swagger	https://pr-682-traction-acapy-admin-dev.apps.silver.devops.gov.bc.ca/api/doc
	Tenant Proxy Swagger	https://pr-682-traction-tenant-proxy-dev.apps.silver.devops.gov.bc.ca/api/doc

Deployment URLs ready for review.

[loneil]

(some tenants for testing)

Issuer:
260f147e-1d98-4488-b6ec-dd47b1c6d64f
fd967634-d290-4f54-a3ec-3469a15d4ff7

Not an issuer:
a60cc559-d273-4245-b1f6-577d6eeed8eb
ac27f6df-97a5-4b7c-9dce-2fec85ef3a21

[loneil]

Altering the settings through the UI seems to be working well from what I understand from testing out.

I have some questions about how default state should be handled (sorry if already discussed and I missed it).

Using the Auto Respond message field as the example here but I think it applies to all, depending on default values...
Right now if you pull up the settings on a new Tenant you'll see there is no settings property in the response for something that hasn't been 'set' yet

Going into a new Tenant, all the settings are unset (false for the switches)

Because nothing comes back from the wallet settings endpoint for these extra settings unless the user has already set one of the fields

So it looks like Auto Respond to Messages is false, but if I send the tenant a message the tenant does auto-respond

This would be because that's the system default I assume?

Toggling it on and then off and saving does then set the setting for that Tenant

So I think this is a possible confusion for Tenants if these settings appear 'turned off' but then they're actually possibly 'on' if that's the default system setting?
If I have that assumption correct...

So if this is the case I could see handling it in a couple ways

1. Purely in the Tenant UI? Use a tristate checkbox? https://primevue.org/tristatecheckbox/
   Some other UX to display that the defaults are being used and opt in to setting yourself?
2. Maybe when a tenant is created, have the settings persistence set to the current state of the fields defaults? Not sure if possible or other knock-on effects.
3. If the setting is not set, then the api still returns the setting value, but pull from the default.

Option 1 is probably easy, could make another ticket to address that.
Questions for @esune about how we want Tenants to deal with this case.

Tagging @shaangill025 and @usingtechnology if they had any thoughts from the aca-py PR 2233. IE should this just be the Tenant UI's problem, or does this need default situation need any more consideration in the core?

[usingtechnology]

good work integrating that and your analysis.
the simplest thing (i think) would to ALWAYS return the full (tenant) set of effective settings.

[swcurran]

My $0.02CDN — if I’m understanding the issues:

• ACA-Py allows tenants to update settings, get settings. I assume there are endpoints for those already.
• Traction instances are configured (or hardcoded?) to have default settings for a new Tenant, applies the settings on/after creation of each tenant. These might include ACA-Py settings as well as Traction settings — e.g. “Is Issuer” Traction setting, “Has Public DID".
• The Traction UI always uses get settings when settings need to be displayed.
• The Traction UI to update settings updates the ACA-Py settings for the tenant.

[esune]

Could we just make the settings explicit on tenant creation? i.e.: the tenant settings are set to what the instance defaults are on creation of a new tenant.
This would cause calls to the get settings endpoint to reflect the actual state, rather than return undefined and potentially lead to confusion. This might need to be a change in the multitenancy code - @shaangill025 can you chime in?

[loneil]

Could we just make the settings explicit on tenant creation? i.e.: the tenant settings are set to what the instance defaults are on creation of a new tenant. This would cause calls to the get settings endpoint to reflect the actual state, rather than return undeined and potentially lead to confusion. This might need to be a change in the multitenancy code - @shaangill025 can you chime in?

That makes the most sense to me as an API consumer I think. I create a Tenant, I ask it for what the current settings for that Tenant is, and it tells me the settings, same as if they'd been set by the user.
Unless it's that the settings are meant to only be overrides of the defaults. IE consider what happens if you create a Tenant, don't touch settings, and then re-set the system defaults (if that's possible)
Not sure if there's downsides on the ACA-Py side or anything.

[esune]

That makes the most sense to me as an API consumer I think. I create a Tenant, I ask it for what the current settings for that Tenant is, and it tells me the settings, same as if they'd been set by the user. Unless it's that the settings are meant to only be overrides of the defaults. IE consider what happens if you create a Tenant, don't touch settings, and then re-set the system defaults (if that's possible) Not sure if there's downsides on the ACA-Py side or anything.

I think we should make the API as straightforward as possible, which means return whichever value that setting is for the tenant - even if it is an override of the defaults, I will need to know what the default values are.

[usingtechnology]

it's only a small set that the user/tenant can self-manage. i think that complete set should get returned all the time. i guess the decision would be whether what is stored in wallet are just the changes (overrides) and those get layered on top of the system settings or if you do as @esune suggests and copy the current system settings into the wallet and that is what the tenant manages. that is probably the simplest way. could add a method to reset to system defaults too (remove all your customizations). it may make it difficult to add new settings (or remove) to the tenant but you could probably figure a way to "sync" the allowable set when the wallet is queried for it's extra_settings.

But i don't think you want traction/tenant-ui to know what the set is and find out system defaults to send to the frontend. the API/acapy returns the manageable set.

[loneil]

Curious where the endorser role is meant to come from?

It should be author for tenants that are created right?
The deployment values have
endorser-protocol-role: author

But in /settings there isn't the endorser role being shown. Though it has the other dependent auto flags set to true

So on the settings page it's defaulting it to none but is it supposed to be author?

[loneil]

See review comments above, but another question (forgive me if I missed this earlier, was only ever looking at the initial specification for the PUT /multitenancy/wallet before) I have is about the difference between the field naming for editing these settings vs fetching them.

When a consumer calls

GET https://pr-682-traction-tenant-proxy-dev.apps.silver.devops.gov.bc.ca/tenant/wallet
to see the subwallet, all these settings come back in this form

But when updating with
PUT https://pr-682-traction-tenant-proxy-dev.apps.silver.devops.gov.bc.ca/tenant/wallet
it's extra_settings instead of settings and the field names are the env var style

Not sure if could be adjusted or if it's an ACA-Py limitation or anything, but just raising that it's confusing from a REST standpoint IMO.

[shaangill025]

@loneil The settings in the response schema are settings already saved to the wallet_record. This is different than the extra_settings in the request schema, where configurable per tenant settings can be provided and saved to the wallet_record.
Re env_var, the following objects provide the association keys to configurable settings in ACA-Py:

ACAPY_LIFECYCLE_CONFIG_FLAG_MAP = {
    "ACAPY_LOG_LEVEL": "log.level",
    "ACAPY_INVITE_PUBLIC": "debug.invite_public",
    "ACAPY_PUBLIC_INVITES": "public_invites",
    "ACAPY_AUTO_ACCEPT_INVITES": "debug.auto_accept_invites",
    "ACAPY_AUTO_ACCEPT_REQUESTS": "debug.auto_accept_requests",
    "ACAPY_AUTO_PING_CONNECTION": "auto_ping_connection",
    "ACAPY_MONITOR_PING": "debug.monitor_ping",
    "ACAPY_AUTO_RESPOND_MESSAGES": "debug.auto_respond_messages",
    "ACAPY_AUTO_RESPOND_CREDENTIAL_OFFER": "debug.auto_respond_credential_offer",
    "ACAPY_AUTO_RESPOND_CREDENTIAL_REQUEST": "debug.auto_respond_credential_request",
    "ACAPY_AUTO_VERIFY_PRESENTATION": "debug.auto_verify_presentation",
    "ACAPY_NOTIFY_REVOCATION": "revocation.notify",
    "ACAPY_AUTO_REQUEST_ENDORSEMENT": "endorser.auto_request",
    "ACAPY_AUTO_WRITE_TRANSACTIONS": "endorser.auto_write",
    "ACAPY_CREATE_REVOCATION_TRANSACTIONS": "endorser.auto_create_rev_reg",
    "ACAPY_ENDORSER_ROLE": "endorser.protocol_role",
}

ACAPY_LIFECYCLE_CONFIG_FLAG_ARGS_MAP = {
    "log-level": "log.level",
    "invite-public": "debug.invite_public",
    "public-invites": "public_invites",
    "auto-accept-invites": "debug.auto_accept_invites",
    "auto-accept-requests": "debug.auto_accept_requests",
    "auto-ping-connection": "auto_ping_connection",
    "monitor-ping": "debug.monitor_ping",
    "auto-respond-messages": "debug.auto_respond_messages",
    "auto-respond-credential-offer": "debug.auto_respond_credential_offer",
    "auto-respond-credential-request": "debug.auto_respond_credential_request",
    "auto-verify-presentation": "debug.auto_verify_presentation",
    "notify-revocation": "revocation.notify",
    "auto-request-endorsement": "endorser.auto_request",
    "auto-write-transactions": "endorser.auto_write",
    "auto-create-revocation-transactions": "endorser.auto_create_rev_reg",
    "endorser-protocol-role": "endorser.protocol_role",
}

[loneil]

@loneil The settings in the response schema are settings already saved to the wallet_record. This is different than the extra_settings in the request schema, where configurable per tenant settings can be provided and saved to the wallet_record. Re env_var, the following objects provide the association keys to configurable settings in ACA-Py:

Ok, thanks for the explanation @shaangill025 . Yeah just that what results in the REST shape for the multitenancy endpoints I think could end up confusing for a Traction consumer (PUTing and GETing on the same endpoint). I'm fine with it as it is if there is a difference between the two concepts as you said, I think most usage of this would be through the Tenant UI anyways which abstracts consumers really needing to know about it.

[hiteshgh]

moved to review/qa as per feedback from @shaangill025

[esune]

Looks good to me! @loneil if you want to take a last look before merging it would be great

[loneil]

I think it looks good. I don't know enough about all the settings to test them out but I tried a couple on and off and got the expected results.
Did basic regression testing on the deployed PR and could create tenants and connect and issue and all that.
👍