User profile

All of the relevant details about a user are stored in the user schema and consumed by different features in the app. In this article, we explain the role of each property in a user object.

When a new user onboards a Padoq app, the new user credentials are assigned to the partition where that app lives. And we may have more than one app in the same partition. This means that the credentials created in one app will work in any of the apps that share a partition. If the same user then onboards an app that lives in a different partition, they will be creating brand new credentials that will only work in apps within that same partition.

In the UI, a user's details are stored centrally in the user's account.

Many of the values we'll mention here are set when the user registers in the app. Check out our User registration (onboarding) guide for more details on that.

Prerequisites

• You can download the iOS or Android app on your phone to see what the user sees. And you can also log in or sing up to the web app here
• You can also see the UI by checking out the images you'll find throughout the guide
• You will find the relevant endpoints linked and explained in this guide, but the full API is documented in Swagger UI

What's in the user profile

We are going to explore the user schema. This is requested and sent by many endpoints in different parts of our apps. For example, addUser, getUser and updateUser all interact with that schema. Here's an overview of how the user profile is structured, with an explanation of what each property does.

1. username
   1. This is generated by the app, based on what the user enters in the UI (property 5 below). It's formatted text, so spaces are converted into underscores, for example. Some of our apps use this property, while others use displayName or a concatenation of givenName and familyName. This is used as default when the user joins a padoq and creates a persona. Although the user can change it
2. gender
   1. The user's gender. This is an array with 4 possible values: MALE, FEMALE, OTHER and RATHER_NOT_SAY
3. emailAddress
   1. The user's email address. This string is also used for authentication and as the default email address when the user joins padoqs
4. phone
   1. The user's mobile phone number. This is also used for authentication purposes
5. displayName
   1. This is very similar to username above and it behaves pretty much the same way. The difference is that this is a string value and it's typed in by the user -so spaces and other characters are allowed
6. givenName
   1. User's first name. In the example below, it's Juliet
7. familyName
   1. User's surname
8. dateOfBirth
   1. User's date of birth. This is used to validate the user's age against the age requirements set for a padoq
9. location
   1. This property is an object with name and coordinates. The data is used in Explore to suggest padoqs near the user. Here's what this property looks like in our example:

   2. "location": {
          "name": "Europe/Manchester",
          "coordinates": [
            53.466667,
            -2.233333
          ]
        }

10. registrationTimestamp
    1. This is the date and time when a user registers in the app. It's useful for reporting. For example, a client might want to know how many users are created every week or every month
11. termsAccepted
    1. This is a property with a boolean value. When the user onboards the app, T&Cs need to be accepted, so the value here should always be true
12. interestGroups
    1. This is an array that contains the interests that the user selects. This is used to suggest relevant padoqs in Explore. In our example, this property looks like this:

    2. "interestGroups": [
           "Movies",
           "Technology",
           "Basketball"
         ]

13. padoqViewOrder
    1. This property sets the order in which padoqs should appear in My Padoqs. The order is set by the user via a tool in the UI
14. attributes
    1. This property stores information that's not captured elsewhere in the user object. For example, if an app has membership levels, that would appear inside this property
15. clientAttributes
    1. These are exactly the same as attributes above, but unique to a client. They might be formatted differently or sourced from a third party, so they are stored in a separate object
16. failedLoginCount
    1. The value of this property is a number. It sets how many times the user has tried to log in and failed. This number can then be used to lock an account. Only a user with Ops access can reset the value to 0 and unlock an account
17. payerId
    1. An ID for the user to use with payment systems
18. privileges
    1. This is where permission levels are set. In the Padoq app, these can be guest, member, admin and super admin. In other apps it might be things like silver and gold, for example
19. avatarUri
    1. This is the location where the user's avatar is stored. It's used in different parts of the app: in the user's profile/account, in post headers, etc.

And here's how a full user profile might look:

{
  "username": "jsmith",
  "gender": "FEMALE",
  "emailAddress": "juliet.smith@example.com",
  "phone": "+15005550006",
  "displayName": "Juliet Smith",
  "givenName": "Juliet",
  "familyName": "Smith",
  "dateOfBirth": "1999-01-01",
  "location": {
    "name": "Europe/Manchester",
    "coordinates": [
      53.466667,
      -2.233333
    ]
  },
  "registrationTimestamp": "2002-08-03T21:42:35Z",
  "termsAccepted": true,
  "interestGroups": [
    "Movies",
    "Technology",
    "Basketball"
  ],
  "padoqViewOrder": [
    "my-place",
    "another-place"
  ],
  "attributes": {},
  "clientAttributes": {},
  "failedLoginCount": 2,
  "payerId": "string",
  "privileges": "string",
  "avatarUri": "https://media.padoq.com/avatar/7004cd0f-2b7c-4feb-84ce-318341fd573b"
}