I am trying to create a permission set where users in certain roles and create records, and they can view, update, or delete their own records. However, users will not have permission to view, update, or delete any other users’ records.
The way I attempted to do this was globally denying the RETRIEVE, REMOVE, UPDATE, and UPSERT permissions while allowing CREATE for the users that can create records and allowing everything under owner policy. This seems to allow users to create records and view and update them, but does not allow deleting.
How would I modify this permissions set to also allow users to delete their own records, without allowing them to delete others’ records?
Please see the following how-to article that describes how to configure the Owner Policy. The article focuses on the data retrieval use-case, however, deletion and update would follow the suit:
The approach you linked in the article seems to work fine for retrieving and updating objects, but does not work for deleting them. When I try to delete an object where I denied the REMOVE permission for the user’s role but explicitly allow it under owner policy, I still get a 403 error even when logged in as the object owner.
I followed the approach you indicated (project FXBK, table “content_bookmarks”) and still no luck. As soon as I disable the RETRIEVE permission for any of the roles the user is currently in, delete requests 403 on me. The only possible things I can think of are that the relevant roles here were manually created (not system roles) and that the users are OAuth users, not native Backendless users.
I am looking at the Permissions grid for the content_bookmarks table and the permissions for the RestRole and the NotAuthenticatedRole are not set as the article describes it.
Also, please let me know the role of a user that you test it with. I would like to create a test user account and assign the role to see the error.
I set the permissions for NotAuthenticatedUser and RestUser (I also set them for JSUser for good measure since this app is running in a JS app). The specific user in this case is running with the OTANonMemberTest group as well as the following others:
I am looking at the permissions for the individual user accounts (at the table level). I see that all permissions are inherited and for most users, the REMOVE permission is denied - see the screenshot below:
No, I don’t know what is causing the denial of the REMOVE permission in this case. I checked all the places, including object ACLs, user permissions for the table, roles permissions for the table, global role permissions, and owner policy and for all relevant users and roles here they’re set to either allow or inherit except for the role permissions at the table level. The fact that it’s somehow still denying permission is the root of my problem here.
Thank you for checking, Jacob. I will have one of the product engineers inspect the backend system of the app to see what’s causing it (it should be sometime tomorrow). Once the permissions are fixed, we will return to getting the Owner Policy working for the deletion scenario.
As a test, I assigned the OTAPreviewUser role to my test account in your app. I was able to delete only the records that belonged to me. For any other record, I am getting an error saying that I do not have permission.
I was able to get it to work (both allowing deletion of users’ own records and denial of deleting other users’ records) with this permission setup (when working with the Node.JS API):
I tested with OTANonMemberTest. For our use case, OTAPreviewUser is not supposed to be able to add entries to the table at all (and there should be no users simultaneously in both of those groups).
Do I understand correctly that you tested the permissions set above with the OTANonMemberTest role, and they work as expected? The user could delete/create/read and update ALL objects. But when you tested with the OTAPreviewUser role, it did not work, the developer could not do anything with ANY objects even where he was the owner?
With the current permission setup, the functionality is now working as intended. Users in the OTANonMemberTest role can read, update, and delete their own records, but cannot do the same for other users’ records.
