6.4.5
532CF1B7-693E-48CA-B1B1-F16FCB709609
36E4262F-E672-1A40-FFCF-B3523EB51200
Hello, @Luke_Jasudavicius.
It’s not a mistake. This feature is not supported in newer versions of Backendless. In your case: recently created projects do not have this column.
Best regards, Nikita.
So, does that mean we can not set permissions on a per-object basis? Or, does it mean that just the UI is not available, but we can set the permission using the API?
Also, why has it been removed? That seems like a downgrade.
Hello @Luke_Jasudavicius
We have removed role object acl support. It is not available nor via console nor API. Object acl for users is available for all applicatins via API. I have created an internal ticket BKNDLSS-26068 to make object acl for users available via Backendless Console. It will be fixed with the next release, next week
Ok, thanks for the information.
With that in mind, I have a question about how I should approach our development:
We are building a CRM system. Users can create a list of contacts and the contacts can have custom properties, like name, email, DOB, or anything else the users want to store on their contacts.
We want users to be able to create teams and share contacts and specific properties with the other users on the team.
Initially I had considered creating a Role for each team, and controlling the permissions to contacts and properties using that team Role.
Now, that seems like it is not possible. Is that true? How should I approach this?
Can I create a Team table which has related Users, Contacts, and custom properties. And then create event triggers, or something, to maintain the correct permissions across the Users and the contacts and properties as the Team’s relations are changed?
Does that make sense? Is that the preferred approach for something like this?
Thank you.
Suppose your Team table has a collection of related contacts and related users. Simply changing the relation between the Team and Users (by adding or removing users to/from it) would alter the visibility of the contacts for the users.
So when you say “alter the visibility of the contacts for the users”. How is that happening? Is there some implied permission system in play here?
Right now, it appears that a user has access to their contacts based on their owner policy. So, how do I setup the permission policy such that all people on a team has access to a set of contacts? And at the same time, don’t have access to contacts that are not part of their team?
Or do permissions not come into play? If not, how can I ensure that a person can not access contacts that they should not have permission to view? If I open up the contacts table to allow all users to view, and just using queries to provide the correct contacts to users based on their team association. What is preventing someone from accessing a contact that is not part of their team directly by querying by ID?
Hello @Luke_Jasudavicius
I think the following solution might work for your case:
This way certain users will not see the properties for which Visibility will be disabled.
Regards,
Inna
I don’t think the column code visibility will work for us for 2 reasons.
How do we handle a column like “email”? We don’t want people to be able to access the emails of contacts outside of their team. (we don’t even want them to have a way to know they exist, let alone access their email)
For custom properties. Those are stored in another table as rows, a custom property essentially has: a related contact, a name, a type, and a value. So, a contact has a collection of custom properties. A user is supposed to be able to choose a contact and select which properties to share with the team.
Maybe I am missing something? I don’t see how that can be accomplished with column permissions alone.
Has the removal of row based permissions been fully thought out?? What is it’s replacement? This seems like critical functionality for us to be losing in these new updates. I only started using backendless a few months ago and I will be honest, when I saw the per-row permissions, that is what sold me on this system for my projects going forward. I have built permissions systems in the past and I know it’s not easy, so when I saw what you had, I was thrilled because I knew you guys knew what you were doing with functionality like that. But, now we are losing a great and perhaps even essential feature… Is there a way for us to choose to use a version of backendless that still has this functionality? If not, what is the recommended replacement or workaround for this system?
Hi.
Firstly I would like to share to you how the ACL works now.
Below there is the recent post on the same theme.
Also pay attention to this:
So, we removed only role-object-acl, but user-object-acl stayed in place and you can set who can access to that or other data.
Hello @Luke_Jasudavicius
We have added the ability to edit the user ACL for all applications. Please check it out.
Regards,
Inna
Ok, awesome thank you!
So, with per-user to per-row permissions. I think we can accomplish what we need. I do appreciate the fast responses.
