Arch Forum 2024-05-23¶
Participants: Backend devs, EMs, Andy and Victor
Agenda¶
- UserStateChangedEvent (Andy)
Notes¶
UserStateChangedEvent: There's a need to introduce a half-blocked state, (working name "Restricted"), that allows users to login and do some actions (KYC related), but not money-related actions.
Today, we have a number of events related to user block state:
UserStateChangedEventPublished when user's state is updated (user become blocked/unblocked etc).FreezeUserAccountEvent&UnFreezeUserAccountEventUsed on top of block sometimes. Event in old style.UserBlockChangedEventUsed when block changes of a user (i.e user is blocked for 2 different reasons)UserBarredEventNot used anymoreCancelUserAccountEventWhen user is cancelled. This is not really relevant and scoped out.
In addition, a user can also be restricted from using Check by a separate setting.
After discussion we could conclude:
1. Freeze/Unfreeze events should if possible be updated to new way and included in UserStateChangedEvent
2. There are multiple ways to think about user state and block "levels". From the basic way we have now to more advanced and granular access control / permission like systems.
3. Just adding a new state to the user state enum would not be too difficult to implement for the various areas that listens on the UserStateChangedEvent.
Growth & Services team will continue and make a concrete suggestion / detailed plan.