KYC level logic

Sprint: 3

Outcome:

Users can upgrade their level by doing KYC processes

Implementation description:

File destination:

{$Dalan_Path}/app/models/user.rb
{$Dalan_Path}/app/models/document.rb
{$Dalan_Path}/app/models/label.rb
{$Dalan_Path}/app/models/level.rb
{$Dalan_Path}/app/models/treasury.rb
{$Dalan_Path}/app/models/profile.rb
{$Dalan_Path}/app/services/kyc_service.rb

Commits:

2422f5d1 40177a4f ac083d21 7f06a2e3 816fb00e 2c05522f 9e17677b bff27466 63977c33 c76f72fe 90cbc486 6dd40a9c 695b0b56 b3b5a08d bd7f9805

What did we implement:

in the Opendax, KYC level handled by labels that id of them (label) shows user level, but not support feature that per-user level has own steps (each label is database record as Label model) obviously per step has its own label too and the label has a unique id itself.

so by considering this rule in the Opendax, we kept it but change some things to support multi-steps.
we implement some kind of giving-points system. users can achieve a new level If the sum of their label IDs reaches a certain limit that defines in the code.

as you know, each step is a kind of record database that controlling by model so:
bank information step is Treasury model selfie and address step is Document model (for uploading) mobile and landline steps are Telephone model profile is Profile model

so if one of the above kind records, is updated or created, we will create or update the corresponding label recording, and if the label is created or updated we will change the users level by calculating their points (points are the sum of label ids)

also, we keep levels (steps for KYC) in the Level model with the below data that was entered by seed

levels:

key: email, id: 1 ,value: verified, description: "User enter a valid code after registration"
key: profile, id: 2, value: verified, description: "User personal documents have been verified"
key: access_phone, id: 3, value: verified, description: "User entered a valid code from sms"
key: card, id: 4, value: verified, description: "User card number have been verified"
key: iban, id: 5, value: verified, description: "User iban have been verified"
key: poa id: 6, value: verified, description: "User card bank have been verified"
key: telephone id: 7, value: verified, description: "User entered a valid code from ring call"
key: selfie id: 8, value: verified, description: "User selfie documents have been verified"
key: owner_phone id: 9, value: verified description: "User owner mobile have been verified"
key: vip id: 10, value: verified, description: "User Vip have been verified"

TODO

now if the label being confirmed accidental in the admin panel, they can not delete it,
so must implement new codes to handle this stuff

2.8 KiB Raw Blame History