Skip to content

Conversation

@hectorgomezv
Copy link
Contributor

Changes

  • Adds user account type definitions: Account, AccountDataType, AcocuntDataSetting, CreateAccountDto, UpsertAccountDataSettingsDto.
  • Adds requests/responses specifications for the following user account endpoints:
    • POST /v1/accounts
    • GET /v1/accounts/{address}
    • DELETE /v1/accounts/{address}
    • GET /v1/accounts/data-types
    • GET /v1/accounts/{address}/data-settings
    • PUT /v1/accounts/{address}/data-settings

@hectorgomezv hectorgomezv self-assigned this Jul 17, 2024
@hectorgomezv hectorgomezv requested a review from usame-algan July 17, 2024 08:23
Comment on lines 9 to 17
name: string
description: string | null
isActive: boolean
}

export type AccountDataSetting = {
name: string
description: string | null
enabled: boolean
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There seems to be an overlap here. Can we combine this into a shared type?

Also is isActive and enabled the same thing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • isActive is an AccountDataType-only property. It indicates if the DataType (CF Safes, watchlist, etc.) is generally available in the CGW. The idea behind this is to provide a list of available DataTypes so the UI could build the list of checkboxes (or another widget) for the user to select using this as a source of truth. An alternative approach would be to use this isActive internally in the CGW and only return the active ones to the UI. This would be simpler but also less transparent. Do you have any preference regarding this? 🙂
  • enabled is an AccountDataSetting-only property. It represents a specific user setting (i.e.: whether the checkbox is marked or it isn't)

Regarding the overlap you commented on, I think you are right and this API can also be simplified. I'm working in the CGW on that regard and will update this accordingly later on 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've modified the API on the CGW side, and I have also modified this PR accordingly in eaa943b

  • Account.accountId was renamed to simply id (as it's the type main identifier).
  • I've solved the overlap between the AccountDataType and AccountDataSetting types.

enabled: boolean
}

export type CreateAccountDto = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't use the DTO acronym in type names. It makes sense within the internal CGW architecture, but for clients it's a non-concept.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed in eaa943b

Comment on lines 25 to 27
accountDataSettings: {
id: string
enabled: boolean
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another (partial) duplication of AccountDataSetting?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also solved in eaa943b

@hectorgomezv hectorgomezv marked this pull request as draft July 17, 2024 09:15
@hectorgomezv hectorgomezv marked this pull request as ready for review July 18, 2024 10:38
@hectorgomezv hectorgomezv requested a review from katspaugh July 18, 2024 10:38
hectorgomezv and others added 4 commits July 18, 2024 14:03
Co-authored-by: Usame Algan <5880855+usame-algan@users.noreply.github.com>
Co-authored-by: Usame Algan <5880855+usame-algan@users.noreply.github.com>
Co-authored-by: Usame Algan <5880855+usame-algan@users.noreply.github.com>
@hectorgomezv hectorgomezv requested a review from usame-algan July 18, 2024 13:58
Copy link
Member

@katspaugh katspaugh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

Side note: we should at some point extract the credentials: 'include', into some boolean flag.

Comment on lines +505 to +514
'/v1/accounts/{address}/data-settings': {
get: operations['get_account_data_settings']
put: operations['put_account_data_settings']
parameters: {
path: {
address: string
}
credentials: 'include'
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we have to define the body here as well but when calling putAccountDataSettings there is no type checking so I can pass anything I want as the second parameter in putAccountDataSettings(wallet.address, {}) without an error 🤔 @katspaugh do you remember if this is expected?

Copy link
Contributor

@usame-algan usame-algan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a minor comment but not a blocker imo. Thanks!

@hectorgomezv hectorgomezv changed the title Add CGW Accounts API specification Feat: add CGW Accounts API specification Jul 22, 2024
@hectorgomezv hectorgomezv merged commit 04a28b5 into main Jul 22, 2024
@hectorgomezv hectorgomezv deleted the add-accounts-api branch July 22, 2024 11:05
@gitpoap-bot
Copy link

gitpoap-bot bot commented Jul 22, 2024

Congrats, your important contribution to this open-source project has earned you a GitPOAP!

GitPOAP: 2024 Safe Contributor:

GitPOAP: 2024 Safe Contributor GitPOAP Badge

Head to gitpoap.io & connect your GitHub account to mint!

Learn more about GitPOAPs here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants