Profiles story and administration
This document explain original profiles submit-n-verify process and possible customizations.
Story described in the document actual for latest 2.5 stable version and higher.
User side of the story
Comment: Previously (in 2.3 and lower) user was able to submit only 1 profile, and all later modifications affect it. Starting from 2.4 we changed
user has_one profile relation to
user has many profiles. This was done first of all to be able to track history of modifications and to be able to control changes from admin panel. Meanwhile, it also brought additional manual verification step in the legacy KYC process.
User can submit profile with following fields (all are optional by default): (via
t.string "first_name" t.string "last_name" t.date "dob" t.string "address" t.string "postcode" t.string "city" t.string "country" t.text "metadata"
Profile creates with
drafted state in database. At this point user can edit the information (via
PUT /resource/profiles), and administrators will not review it yet.
Once all the information is edited and validated by user correctly, he can submit profile for verification (via
PUT /resource/profiles) by passing
confirmation: true in the params. Profile state changes to "submitted" in database and from now on this profile is pending for admin verification.
Meanwhile, there is a possibility to skip this "edit" step and create a profile directly with
submitted state. For this user need to pass
confirmation: true parameter directly in
After admin will verify the profile and mark it as
"rejected" user will be able to create a new profile with
drafted/submitted state, if he need it. Flow mostly controls by a
server-side rule: user can have
ANY amount of profiles, but
ONLY ONE of
drafted/submitted at a time.
Admin side of the story
Once user sumbit a profile (with state submitted) admin can verify or reject it, by changing a profile state and creating a correct label. Usually its `key: profile, value: verified/rejected'.
Also administrator has an access to the full profiles history, so he can check and compare new changes with old profiles, if the exist. As well he has an information about previous decisions about profile verification per each request.
Once profile is rejected or verified, admin can create new profile for user (via
In this case, profile will have a 'submitted' state and 'author' field with admin UID in DB.
!!!Attention By default, if admin creates a profile for user, the same admin account cant approve or reject this profile, he need to wait for second admin approval. However, this can be changed by env
BARONG_PROFILE_DOUBLE_VERIFICATION which can receive 2 value:
true for enabling and
false for disabling the feature