feat(operators): Add reactivate account button #6747
Conversation
abshierjoel
changed the title
| @@ -52,7 +52,7 @@ | |||
| "prettier:fix": "pretty-quick --config .prettierrc.json --write '{src,cypress}/**/*.{ts,tsx}'", | |||
| "tsc": "tsc -p ./tsconfig.json --noEmit --pretty --skipLibCheck", | |||
| "tsc:watch": "yarn tsc --watch", | |||
| "generate": "export SHA=993f6756500aebe47903a3ddaee62f9f75d207c1 && export REMOTE=https://raw.githubusercontent.com/influxdata/openapi/${SHA}/ && yarn generate-meta", | |||
| "generate": "export SHA=d05381fbcee0dd5d88833e71057a4af647e0d169 && export REMOTE=https://raw.githubusercontent.com/influxdata/openapi/${SHA}/ && yarn generate-meta", | |||
| "generate-local": "export REMOTE=../openapi/ && yarn generate-meta", | |||
There was a problem hiding this comment.
Looking at this openapi SHA - it looks like the request body is just an object? Could we add a more specific type in openapi? I worry this is going to cause issues (or at min some warnings) with type validation on the UI side if we don't have a schema for the body.
Example:
There was a problem hiding this comment.
@wdoconnell thanks! So what do we usually do whenever there's no request body necessary? IIRC, without a requestBody, OATS won't generate it right. But it's not strictly necessary, so that's why I ended up with object.
There was a problem hiding this comment.
@abshierjoel Oh, in that case, just ignore what I said 😓 - I had thought this would be relied on. If there's no request body being used I think it's fine to leave it as object.
| <ButtonBase | ||
| color={ComponentColor.Primary} | ||
| shape={ButtonShape.Default} | ||
| onClick={() => setReactivateOverlayVisible(!reactivateOverlayVisible)} |
There was a problem hiding this comment.
I know this is the convention elsewhere in this file - but should we be using !reactivateOverlayVisible? I think this is a one-way trip so really hitting the button should always set reactivateOverlayVisible to true.
There was a problem hiding this comment.
Yep! I definitely prefer that!
| @@ -0,0 +1,82 @@ | |||
| import React, {FC, useContext} from 'react' | |||
| import { | |||
| Overlay, | |||
There was a problem hiding this comment.
Would you mind alpha-ordering these just for readability? 😄
| @@ -138,23 +153,42 @@ export const AccountProvider: FC<Props> = React.memo(({children}) => { | |||
| } | |||
| }, [dispatch, history, accountID]) | |||
|
|
|||
| const handleReactivateAccount = useCallback(async () => { | |||
| try { | |||
| setReactivateStatus(RemoteDataState.Loading) | |||
There was a problem hiding this comment.
Is reactivateStatus being used? This pattern gets used in our Redux state-managed components to ensure that in useEffect hooks, we only trigger API calls once on page load, not when loading or when there's an error. But I don't see anything in these components that relies on this status.
There was a problem hiding this comment.
I started to remove it, but I instead kept it to disable the reactivate button once they click it. Technically, the operation is idempotent, but it's probably better if they're not smashing it, since it can be a slow operation.
When an account is canceled and has suspended organization(s), it can be reactivated.
Checklist
Authors and Reviewer(s), please verify the following: