You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// 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
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.
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.
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.
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.
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.
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.
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'} ] ?
Is viewable used to implement the permission?