Users and Profiles

Elements uses a one to many model for the User / Profile relationship. A Profile is linked directly to both one single Application, and one single User. As Elements is a multitenant system, this means that there can be many Applications that allow for many Profiles per Application, giving you the flexibility to create a network of Applications under the same roof, with any User level information (such as Inventory) accessible in every Application should you so choose.

A User has the following properties:

  • Id
  • Name
  • Email
  • Level
    • UNPRIVILEGED - An unprivileged/anonymous user.
    • USER - A basic user.
    • SUPERUSER - An administrator/super user, who can do all of the above as well as delete/create users.
  • Active - Inactive Users will not appear in searches made by non-superuser level users.
  • FacebookId
  • AppleSignInId

A Profile has the following properties:

  • Id
  • User - The User that this Profile is linked to.
  • Application - The Application that this Profile is linked to.
  • ImageUrl - Any associated avatar image.
  • DisplayName - The name that should be displayed on the client side.
  • Metadata - Key/Value store that can be modified.
  • LastLogin - The time that the current session token was created (MS since epoch)

Once created, only the DisplayName and ImageUrl can be modified from the client side (via ProfilesApi). However, other properties, such as the Metadata, can be modified from the server side.

Profile Metadata


As mentioned in the previous section, the Profile metadata is a key/value store for just about anything that you'd want to be publicly facing (as Inventory is private) in a Profile. This is a great place for storing info that you might want different Profiles to know about each other. For example, say you have a game where someone can earn points to increase a numeric rank. In order to see that information, it needs to be stored in a publicly accessible place. Take this wireframe image for example:


All of the stats listed in this screen would be housed by the Profile metadata, so the JSON representation might look something like this:

    "id" : <id string>, 
    "user" : <redacted>,
    "application" : <Application JSON>,
    "image_url" : <path to image>,
    "display_name" : <display name string>,
    "last_login" : <last login time>,
    "metadata": {
        "ranking" : 1300,
        "wins" : 999,
        "losses" : 999,
        "total_games" : 999,
        "current_win_streak" : 999,

Modifying Profile Metadata

In your Lua code, you can access the Profile DAO directly. For example:

local profile_dao = require "namazu.elements.dao.profile"

You can then use this to update the Profile metadata via one of two methods:

 * Updates metadata for the Profile with the specified id, ignoring
 * changes to all other fields.     
Profile updateMetadata(String profileId, Map<String, Object> metadata);

 * Updates metadata for the specified Profile, ignoring changes 
 * to all other fields.
Profile updateMetadata(Profile profile, Map<String, Object> metadata);


Lua tables are automatically converted to the correct Java type.

To continue the example, take this sample endpoint code:

local profile_dao = require "namazu.elements.dao.profile"
local auth = require "namazu.elements.auth"
local elements_request = require "namazu.request"
local elements_response = require "namazu.response"

local metadata_api = {}

function metadata_api.update_wins(payload, request, session)

    -- Profile and User can be retrieved directly from auth for endpoints
    -- defined with 
    --  auth = { auth.SESSION_SECRET_SCHEME }
    local profile = auth.profile()  
    local metadata = profile.metadata

    -- This assumes that this endpoint was defined with
    -- parameters = {
    --      wins = { index = 1, type = "integer" }
    --  }
    local updated_wins = elements_request.unpack_parameters(request, "wins")

    metadata["wins"] = updated_wins

    profile_dao.update_metadata(profile, metadata)

    return elements_response.formulate(200)

return metadata_api