# 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