I want to record 'languages spoken' in my User database and I am planning to import the data from omniauth Facebook login, as well as letting users select which languages they speak themselves when updating their profiles.
I looked up how languages spoken is recorded: https://developers.facebook.com/docs/reference/api/user/
And it says..
'array of objects containing language id and name'
How can I prepare my Rails database to receive this data? And how can I send data to something like this from the profile form
If all you want is the name of the language, then you could simply use a single column called languages on the User model that's just a comma-separated list of the languages.
If you want more details for each language (e.g. the FB ID associated with it, etc), then you could make a Language model that has columns for that information. Then you could use a has_many and belongs_to relationship for the User and Language models respectively.
To save to the DB, you'll just need to parse whatever the Facebook API gives you and then save that to the database.
Related
I am really uncertain of how to handle the data "duplication" of the signed in user from FirebaseAuth and the project own User model fed by the users collection I create from FirebaseAuth sign ups.
For example, creating a UserAvatar widget that shows the signed in user display name and photo URL. Should I user the FireAuth User or my own users collection?
What would be the pros and the cons?
There are several considerations to take into account when deciding whether to use the FirebaseAuth user object or a separate user object from your own database.
One consideration is the purpose of the user object. If you are using the user object for authentication purposes, such as checking whether a user is logged in or verifying their credentials, then it may be more appropriate to use the FirebaseAuth user object. This is because the FirebaseAuth user object is specifically designed for these types of tasks, and it is directly tied to the user's authentication state in your Firebase project.
On the other hand, if you are using the user object to store additional information about the user that is not related to authentication, such as the user's display name or profile photo, then it may be more appropriate to use your own user object from the database. This is because the FirebaseAuth user object is limited in the amount of information it can store, and it is not intended to be used as a general-purpose user object.
There are pros and cons to both approaches. Using the FirebaseAuth user object has the advantage of being directly tied to the user's authentication state, which can be convenient for certain types of tasks. However, it is limited in the amount of information it can store, and it may not be the most flexible solution if you need to store a large amount of information about your users.
On the other hand, using your own user object from the database allows you to store more information about your users, and it gives you more flexibility in terms of the data model. However, it requires additional work to keep the user object in sync with the FirebaseAuth user object, and it may introduce additional complexity to your codebase.
Ultimately, the best approach will depend on your specific needs and the requirements of your project. You may find that a combination of both approaches works best for your use case, or that one approach is more suitable than the other.
Using the firebase platform..
I would like to save some custom information about a user once they register.. and just for examples sake, lets say his/her favorite color.
So far when I register a user this is the only meta data I get
What options are at my disposal to get this done?
You have two options:
1 - Use Custom Claims
You can save additional data to the access token of the user. You can read that data directly from the user in the frontend and also in all database rules. I would recommend to use this for basic auth data like isAdmin or isRole if there are not much data to save. The reason for that is that it's quite limited in the amount of data you can save. Because it's saved in the token it has to be small so you should not save to much in it. You can find more about it here. You should edit this fields by a firebae cloud function using the admin sdk.
2 - Use one of the databases
I see it very often and it's quite common in Firebase to store such additional user data into one of the Firebase databases. You can make those 1000% securely by allowing only the user to write and read then or only to read depending on your needs. If you want to save more than just simple data I would recommend this. One reason more is if any other user like admin needs that data from another user you would not be able to get it by using the first option. It is also much easier to do it when the user needs to save data for himself and by himself. With the first version you would always need to involve cloud functions.
I very often use combination of both where I save such data like isAdmin to the custom claims but all other like nickname or some settings like language to a database. With the database I can also make it very easy to search through all users when you are an admin.
I have my teams client language setup in french, I see the general channel name change in french,
however when I use GRAPH REST API GET /teams/{id}/channels/{id} to query the channels for the logged in user it returns data to me in english and not french
does the API support language selected by the logged in user?
Unfortunately, the Microsoft Teams graph api does not support the function of language translation. This is because when you created the teams, it was already stored in the database in the default language (English), so when you call the API, you get it from the database The data is displayed in English, and Microsoft Teams graph api cannot translate it for you in real time.
Although the customer language of your team is set to French, this is only the language displayed on the page, and the data storage language of the back-end database is still the default English.
I am using Dialogflow to create a chat bot. How do I maintain a user model within a chatbot system?
I want to have a different user model saved for each user in a group. The user model should store the user’s name, personal information it gathers from the dialog, and the user’s likes and dislikes.
With this information, I would like to add personalized remarks from the user model to the dialog engine.
You need some database to story User information.
as per Dialogflow
It's helpful to think of API.AI as just that - an API that you use to
parse user intent from natural language queries. If you have custom
business logic, platform-specific formatting requirements, or need to
integrate with external data stores, it would be better to create your
bot from scratch in code, and make calls out to API.AI in order to
parse inbound queries. API.AI isn't a bot-building platform, but a
Natural Language Understanding platform.
for more Information click here
you can use web-hooks which hits your controller function and run logics which you want like save information.There is one Object like response in which all information inside there
It depends how long you wish to maintain the information about the user and what platform, if any, you're integrating Dashbot with.
Using just the Dashbot framework, one good way to maintain the user information is through the parameters available to a Context. This will be retained during the entire conversational session.
However, if you want to maintain this information between sessions, you'll need to handle this in your fulfillment - in particular, you'll have to save it in a permanent store (such as a database) against a userid if one is provided for your integration.
We have a system built on dynamic objects - so there is a metadata table that describes these objects. For example - Organization A can have a Warehouse Object, a Client Object and a Sales Object. Organization B can have a Sales Object and a Clown Object.
Users authenticate to our rest api built on the Yii2 framework. They authenticate using a call to /user/authenticate and then they query for objects using /object/ for list / create and /object// for Read, Update, Delete.
The issue with this is: If a developer is going to integrate into the service, they would need to know all objects that have been defined in their organization including available fields they are able to read/write to. What we would like to do is provide an option to describe our data.
E.g. My initial thought would be to expose something like /object/metadata in which I would respond with a json list of resources that the user is allowed to access e.g. a Warehouse A user would see Warehouse, Client, Sale. Where a Org B user would see Sales, Clown.
I have been asked to take a look at oData as a specification for this but oData seems to define a whole convention of things (url, searching and filtering etc).
Does it make sense to implement part of the oData Spec or use it as a guide and keep our URLs the same?
Is there a part of the oData spec that would lend itself to the describing of a dynamic resource (e.g. if the user uses our system to add a column to the Sales object - the api should reflect that).
Would appreciate any thoughts on how to design / proceed with this requirement.
Thank you!
I created follow solution:
extend dektrium/yii2-rbac, where to assigments add column company
in each module (werhause, invoices,..) created roles objects
roles object has methods: canAssign(), canView(), canRemove() for user administartion
user administration panel collect all roles from all modules (scan as files) and display grouped by modules.
This solution allow to user switching between companies and for users assign different access rights to different companies and control user manager rights assigning rights