Removing my own users ACL permisions

Question

I have an app where multiple users are allowed to edit the data of an object, let's just say user A, B, and C. All with both Read and Write explicitly defined on the objects ACL.

When I'm logged in as user A, I can remove access for user B and C... but when I try to remove myself it throws an error:

CommunicationError {message: "The permission modification is not valid.", name: "CommunicationError", cause: {…}, reason: "Invalid Permission Modification", status: 462, …}

Is there a way to allow a user to remove his own ACLs? And if not, given this code, how can I catch this error and do alert("You can't remove your own access to this company, please have an associate remove you or contact our support team.") ?

removeManager(event, id) {
    event.preventDefault();
      db.Companies.load(this.props.match.params.id)
        .then((company) => {
          company.acl.denyReadAccess(id);
          company.acl.denyWriteAccess(id);
          return company.update()
          .then(() => {
            return company.partialUpdate()
            .remove("managers", id)
            .execute()
            .then(() => {
              this.getCompanyandManagers()
            })
          })
        })
  }

Answer 1

not being able to revoke the user's own access is by design, because users could not undo this operation afterward.

That said, there is a way to get around this if you really want that:

1. You need to give read and write access to the node role. This way the object can always be accessed from backend code.
2. You write a backend code that revokes the access of the currently logged-in user (db.User.me).

If you prefer to catch the Exception and show an error message you can do it like this:

.catch(e => {
  if (e.status == 462) {
    // show message
  }
})

I hope this answers your question.

Regarding your code above you could use deleteReadAccess(id) instead of denyReadAccess(id) (the same for write access). With denyReadAccess(id) you are creating an additional deny rule, so you end up with an allow rule for UserX and a deny rule for UserX, so it is better to just revoke the access by deleting the allow rule. (For an explanation of allow and deny rules see this answer)