Skip to content

Instantly share code, notes, and snippets.

@RohitRox

RohitRox/ES-User-Search.md

Last active May 30, 2019
Embed
What would you like to do?
ES-User-Search

ES Document Struct

{
  "_index": "users_index",
  "_type": "_doc",
  "_id": "iam-id-uuid",
  "_score": 1,
  "_source": {
    "iam_id": "iam-id-uuid",
    "role_id": "c65e502d-39b2-46cb-850e-73a32eaf9364",
    "email": "mohamed.gusikowski@cloudfactory.com",
     "ucid": "01e2506b-d8b8-4c30-9346-bc4b2fa319f2",
     "first_name": "Mohamed",
     "last_name": "Gusikowski",
     "full_name": "Mohamed Gusikowski",
     "countries": [
       "Nepal",
       "Kenya"
     ],
  }
}

Custom Attribute Metadata Schema (Constant for now, will be used in FE and BE)

{
 searchable: [
    full_name,
    email,
 ],
 filterable: [
    role_id,
    countries
 ],
 sortable: [
   full_name,
   email
 ],
 viewable: [
    full_name,
    email,
    role_id
 ],
 meta: {
  first_name: {
    type: 'text',
    label: "First Name"
  },
  last_name: {
    type: 'text',
    label: "Last Name"
  },
  full_name: {
    type: 'text',
    label: "Name"
  },
  email: {
    type: 'text',
    label: "Email"
  },
  role_id: {
    type: 'list',
    options: [ {value: 'xxx', label: 'Cloud Worker'}, {value: 'nnn', label: 'Employee'} ],
    label: "Role"
  },
  countries: {
   type: 'list',
   options: [ {value: 'Nepal', label: 'Nepal'}, {value: 'Kenya', label: 'Kenya'} ],
   label: 'country'
  }
}

BE Api

// also illustrate order of preference
/use/search/api/users?filter[countries][]=nepal&filter[countries][]=kenya&filter[full_name]=test
/use/search/api/users?q=
/use/search/api/users?sort_by=field&sort_order=asc
/use/search/api/users?page=1&per_page=20
{
  entries: [{
    iam_id: 'xxx',
    role_id: 'xxx-xxx',
    ucid: 'xxx-xxx',
    first_name: 'David',
    last_name: 'Costa',
    full_name: 'David Costa'
    email: 'd@cf.com',
    countries: ['Kenya'],
  }],
  metadata: {
    total: 100,
    page: 1,
    per_page: 50,
  }
}
@barunthapa

This comment has been minimized.

Copy link

@barunthapa barunthapa commented May 24, 2019

Is viewable used to implement the permission?

@samit22

This comment has been minimized.

Copy link

@samit22 samit22 commented May 24, 2019

I think the basic info or say common info like name email shouldn't be inside the context(worker, core) let's keep it outside so that it will be easier to query.

@RohitRox

This comment has been minimized.

Copy link
Owner Author

@RohitRox RohitRox commented May 24, 2019

Is viewable used to implement the permission?

No. At this time, there is no permission related stuff. viewable is used to represent which fields to show in columns in the list by default.

@RohitRox

This comment has been minimized.

Copy link
Owner Author

@RohitRox RohitRox commented May 24, 2019

I think the basic info or say common info like name email shouldn't be inside the context(worker, core) let's keep it outside so that it will be easier to query.

Yes, we thought about it. I would like to do that if possible. The tricky thing is how do we know what fields are shared as all fields are dynamic. Also, as per mocks, it looks like we need to do queries like find me worker with the first_name, or find me employee with last_name kind of stuff. We can discuss this in our session if there is a way.

@barunthapa

This comment has been minimized.

Copy link

@barunthapa barunthapa commented May 27, 2019

Why is role_id duplicated? A user can have multiple roles?

@RohitRox

This comment has been minimized.

Copy link
Owner Author

@RohitRox RohitRox commented May 27, 2019

Why is role_id duplicated? A user can have multiple roles?

Was a mistake. Fixed.

@prabhatach

This comment has been minimized.

Copy link

@prabhatach prabhatach commented May 28, 2019

Actually dai, I am not able to understand the use case of why and how the users have the dual context? If it's about user getting access to multiple interfaces, does it actually change the context of a user or just it has extra permission to view that. If we thought it as the separate context then do we store the data of the users in two tables based on the access level to interface? And How do we manage their profile, Since some of the information is common for both like the first name or last name or could be other details? Some of the metadata are specific to the worker and some may be for another context in future, how do we distinguish them and store inside the context key as shown in the document struct of ES? I think this design is introducing more complexity, rather managing the context through role could be the easier solution. The core role could have all the lower level of access so that it can automatically be powered by the capability that even the worker has.

@Acesmndr

This comment has been minimized.

Copy link

@Acesmndr Acesmndr commented May 28, 2019

Would one worker be associated with multiple countries? As in the example multiple countries are returned.
Since in the UI we are merging first_name and last_name fields and applying string trucation in email field we would create an UI assuming the fields first_name, last_name and email are always present and others can be dynamically added but would require a label field for the title in the table. Here thus role_id should also have a label associated with it.

@RohitRox

This comment has been minimized.

Copy link
Owner Author

@RohitRox RohitRox commented May 28, 2019

Actually dai, I am not able to understand the use case of why and how the users have the dual context? If it's about user getting access to multiple interfaces, does it actually change the context of a user or just it has extra permission to view that. If we thought it as the separate context then do we store the data of the users in two tables based on the access level to interface? And How do we manage their profile, Since some of the information is common for both like the first name or last name or could be other details? Some of the metadata are specific to the worker and some may be for another context in future, how do we distinguish them and store inside the context key as shown in the document struct of ES? I think this design is introducing more complexity, rather managing the context through role could be the easier solution. The core role could have all the lower level of access so that it can automatically be powered by the capability that even the worker has.

Great Question Prabhat. We need to have a discussion with the product team about these context and role types. For eg how will we handle similar fields which are in both core and worker? What is the concept of a common field? For now, we have simplified the ES document structure by flattening everything. Check out the updated schema.

@RohitRox

This comment has been minimized.

Copy link
Owner Author

@RohitRox RohitRox commented May 28, 2019

Would one worker be associated with multiple countries? As in the example multiple countries are returned.
Since in the UI we are merging first_name and last_name fields and applying string trucation in email field we would create an UI assuming the fields first_name, last_name and email are always present and others can be dynamically added but would require a label field for the title in the table. Here thus role_id should also have a label associated with it.

A/C to custom attributes, YES, one user can be assigned in multiple countries.
In custom attributes, it's an array, so API will also return an array.
Regarding first_name and last_name, I also don't have an answer, cause our current custom attribute data architecture does not yet support this use-case. Custom attribute won;t be able to tell us, use Name field which is a combination of first_name and last_name. For now, we'll have to so something in the UI to join first_name and last_name and show it as a Name field. Long term solution would be, custom attribute will store info about this field and how to compute value of this field.

For sorting, I was thinking if UI could pass sort=first_name+last_name, both, the api could can do a sort by combination of two fields against ES.

@gaurab13

This comment has been minimized.

Copy link

@gaurab13 gaurab13 commented May 29, 2019

In Custom Attribute Metadata Schema, we probably need to settle on a specific format on how options for list type attributes inside meta are returned as. In role attribute, options is returned as [ {id: 'xxx', name: 'Cloud Worker'}, {id: 'nnn', name: 'Employee'} ] which is understandable and needed. But for any other list type fields like countries just having an array of strings will create problems in the UI.

Our Select component currently accepts an array of this format [ label: 'Nepal', value: 'Nepal'], where label is whats shown in the UI.
For the UI all list type fields will behave the same, so having a proper format will make it easy for the front end to manipulate and use it.
So can we send the country options as [ {id: 'nepal', name: 'Nepal'}, {id: 'kenya', name: 'Kenya'} ] ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.