validator_operator/validator_users

[giscus[bot]]

validator_operator/validator_users

https://docs.dev.sync.global/validator_operator/validator_users.html

[v9n]

If one had accidently click the "Onboard yourself" button and now we want to recover from it and associate them with the validator party id we can follow the below process

1. Offboard this user

POST to <wallet-domain>/api/validator/v0/admin/users/offboard?username=<oauth-user-id>
We can copy the token on the wallet app by inspecting request and use it.

OpenAPI for that call
https://github.com/hyperledger-labs/splice/blob/57598f84474bd755c84e35612545604df10a88ba/apps/validator/src/main/openapi/validator-internal.yaml#L104

2. Update the user primary party id

Attach a console. Note that you will need the participant auth token, not the wallet token. This is the M2M token of validator backend. and run

participant.ledger_api.users.update("<oauth-user-id>", _.copy(primaryParty = Some(PartyId.tryFromProtoPrimitive("<validator-party-id-here>"))))

3. Bind the user to the validator party id

Follow the step mention in this document to assign them to the validator party id.

[waynecollier-da]

Let's add a paragraph or two explaining how to manually set up partyIDs, and associated wallets and users, for non-operator parties.

[isegall-da]

Note that one can add a user to the wallet admin party also via listing them in the validatorWalletUsers now. On Splice 0.4.X, if it has been onboarded as its own party first, then you must first offboard it, and also delete the user manually from the participant using participant.ledger_api.users.delete("<user>") before adding it to validatorWalletUsers and restarting the app.
Starting from Splice 0.5.0, offboarding will also delete the user automatically, so just offboarding, adding the user to the config, and restarting the app, should suffice.

[isegall-da]

The Users, Parties and Wallets section currently focuses on adding more users to the validator operator party. Another common requirement is to onboard a user with a user-determined party-hint (the prefix of the party ID, before the ::<namespace> part). By default, onboarding a new user will create a party with that user's username as the party hint, but that is typically a cryptic OAuth user ID, and often one wants the party hint to be more meaningful.
Support for setting the party hint to be used for creating the new party will be added in a coming release. For now, one can achieve this using a two-step approach:

1. Onboard a "fake" user with a username equal to the party hint you wish to use, by calling curl -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ --data-raw "{\"name\":\"$PARTY_HINT\"}" \ https://<URL of your wallet>/api/validator/v0/admin/users
   This will create a new party and user with the required party hint, associated with a user with the same name (to which typically you cannot login, as it's not an OAuth user). The response should include the party ID that was created.
2. Create another user associated with the party that got created for you in step 1, by calling curl -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ --data-raw "{\"party_id\":\"$PARTY_ID\",\"name\":\"$USER\"}" \ https://<URL of your wallet>/api/validator/v0/admin/users. The PARTY_ID here should be the one created in step (1), and the USER is your real OAuth user's ID.

(Note that step 1 can be replaced by just creating the party directly in the participant, e.g. by using the participant's /v2/parties endpoint, or via a Canton Console, but for simplicity, we use only validator app APIs in this comment)

[pasindutennage-da]

Support for setting the party hint to be used for creating the new party will be enabled in Splice 0.5.5.

OnboardUserRequest:
      properties:
        name:
          type: string
        party_id:
          type: string
          description: |
            The party id of the user to onboard.
            If no party_id is provided then a fresh party will be generated, using the 'name' as the Party Hint.
            If party_id is provided and createPartyIfMissing is false, then the party must already exist on the ledger. The existing party will be assigned to the user.
            If party_id is provided and createPartyIfMissing is true, then: if a party with the provided party_id exists, the user will be associated with it. Otherwise, a new party will be created using the provided party_id, and the user will be associated with that new party.
        createPartyIfMissing:
          type: boolean
          description: |
            If true, create the party if it does not already exist on the ledger.
            Default is 'false'.