79 lines
2.8 KiB
Markdown
79 lines
2.8 KiB
Markdown
# 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<br />
|
|
{$Dalan_Path}/app/models/document.rb<br />
|
|
{$Dalan_Path}/app/models/label.rb<br />
|
|
{$Dalan_Path}/app/models/level.rb<br />
|
|
{$Dalan_Path}/app/models/treasury.rb<br />
|
|
{$Dalan_Path}/app/models/profile.rb<br />
|
|
{$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.<br />
|
|
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:<br />
|
|
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,<br />
|
|
so must implement new codes to handle this stuff
|
|
|
|
|
|
|