What is the correct way to relate users in parse to one another as friends?
I also want users to be able to query other users but not see all fields, like emails. Is there a way I can create a view on the users table with cloud code, and only return this to the client code?
I was thinking I can create a friends table that will have two columns with 2 pointers, 1 for each user.
thanks for any advice.
I was thinking I can create a friends table that will have two columns with 2 pointers, 1 for each user.
I'll do that too, with a status column to handle pending, blocked...etc
I also want users to be able to query other users but not see all fields, like emails.
You have to add a privateData column on user with ACL restricted to owner only, which would contain private infos such as emails...etc
Related
I'm the QuickBase Admin for my QuickBase app. In the app, there's a dashboard report that's used by individuals with viewer access; that way, they can see their students' data, but can't edit the app, tables, structures, etc.
My app's users want to be able to edit one field with notes on that row's data (each row is a student's data, so they'd want to use that field to add notes on that individual), but viewers don't have editing/data entry access tn any column. Is there a way for users to have editing/data entry access to one field, but not the others?
I know with Tableau and other BI software, this isn't possible, but I wanted to ask since my users asked.
Thank you for reading.
Sure you can.
Actually there are more ways to implement this needs.
My opinion better if you create a new table and make a relationship between the student data and a (new) Notes table and you will be able to setup edit rights eg by record owner.
An other way, you can allow the edit right for your users and you can make a restriction on field level. In this case you have to go through on each field and at the Advanced section you will find Permission - Restrict access by role.
Hopefully you do not have a lot of fields :)
I am developing a system in which it will have a chat system between two user tables: the clients and the engineers. My problem is how to make these two tables communicate in one message table with regard to registering the sender ID and recipient ID since both can change and are in different tables.
My initial thought for this was two tables where I would use the polymorphic relationship:
chats
id
client_id
engineer_id
messages
id
chat_id
senderable_id
senderable_type
receiverable_id
receiverable_type
content
What would be the most recommended way to solve this problem?
First of all, the following its the generic way that I see to create a chat schem. It'll works to a chat with 2 users or more than 2 users.
Note, the user_chat table its the pivot table between users and chats. You can define an alias to that table, like "participants", because it what it means. You can add more attributes to chats table, but basically need to know the creator.
Finally, the secret in messages table is just to get the sender id from users table, because sender and receiver are relative concepts in this context.
Another more simple and reduced way to do it (if you are trying to make a chat with only 2 users) is:
In my site (api using laravel 5.6 and laravel passport) I have two types of users (Teachers and Students), in the future there will be more. The teacher and student entities are very different, meaning that if I keep them all in one table, the table will be long and many fields will have a null value. Right now I have one Users table with common fields and two other tables (Teachers and Students) to which I have setup a polymorphic relationship from user. My question is if this is a good approach, or if there are other ways to handle this more elegantly?
I would create 1 table for Teachers and 1 table for Students and not use the Users table/model. This way you can keep them completely separate and not worry about adding more types of users in the future. Continually trying to fit new users into your existing Users model, which would be shared, is a headache. I made this same mistake when I started and eventually had to rework the project.
There are plenty of guides for Laravel multi-auth / multi-user online.
Here are a couple to help you get started:
https://medium.com/hello-laravel/multiple-authentication-system-laravel-5-4-ac94c759638a
https://www.codementor.io/okoroaforchukwuemeka/9-tips-to-set-up-multiple-authentication-in-laravel-ak3gtwjvt
Also, there are cases where it makes sense to use the User model for multiple types of users. For example, you may have multiple roles for a user where most/all of the fields are the same (not your scenario). In this case, you can assign a 'role' to each User and the check the roles for actions (e.g. add middleware to prevent roles from accessing various routes). Here is an example:
https://medium.com/#ezp127/laravel-5-4-native-user-authentication-role-authorization-3dbae4049c8a
Since you said the teacher and student entities are very different, you should keep them separate.
I have two scenarios that I want to support but I don’t know the best way to design relations in the elasticsearch. I read the entire elasticsearch documentation but I couldn’t find the best way to design types for my scenarios.
Multiple one to many.
Let’s assume that I have the following tables in my relational database that I want to transfer to the elasticsearch:
Transaction table Id User1Id User2Id ….
User table Id Name
Transaction contains two references to User. As far as I know I cannot use the parent->child relation specifying two parents? I need to store transaction and user in separate types because they can be changed separately. I need to be able to search transaction through user details and return users connected with transactions. Any idea how to design such structure in the elastic search?
Many to many
Let’s assume that we have the following tables:
Order Id …
OrderLine OrderId UserId Amount …
User Id Name
Order line is always saved with the order so I thought that I can store order with order lines as a nested object relation but the user must be in the separate table. Is there any way how can I connected multiple users from order line with user type? I assume that I can use application side join but I need to retrieve order and order line always together and be able to search order by user data.
I can use grandparent and grandchildren relations but then I need to make joins in the application. Any idea how to design it in the best way?
The scenario : an Oracle 11g database containing some sensitive user data that could result legal liabilities if disclosed to the wrong party.
The desired effect : only a certain user, connecting from a certain IP, can see the column that contains this sensitive user data
I am not sure that hidden columns or virtual columns are the right ways to do this. It seems that Fine-Grained Access Control could help. I am not sure of what is the best solution. The restriction by IP is probably done at the listener level?
The question :
How can we restrict the visibility of a column so it is only available only to a specific user? All the other users would never see the column, not even when doing a "DESC TABLE_WITH_SENSITIVE_DATA"
Thanks for any tips.
Simplest way to do this is to create a view on the table that does not contain all of the columns. Don't grant select on the table, but only on the view.
The "proper" way to do this is with Fine-Grained Access Control (Virtual Private Database), which can replace the contents of columns with a NULL if certain conditions are not met.
See the example here: http://docs.oracle.com/cd/B28359_01/network.111/b28531/vpd.htm#autoId17
You can probably build this sort of functionality yourself if you're feeling both impoverished and skilled.
Do you the ability to modify roles and create views? Perhaps you could create two separate views and grant access to two different roles for that table. All users that are restricted from seeing the sensitive data would belong to a "restricted" role and the others would have access to the "unrestricted" role. You would need to grant privileges on each view to the appropriate role.
It is important to note that there are restrictions on updating the underlying data associated with a view. As explained here, views that contain set operators, aggregates and GROUP BY DISTINCT and joins and not modifiable.