Reputation: 6065
TL;DR
Setting an ACL with a role permission fails sometimes because the role's name is interpreted as the permission type.
In a Cloud Code function, I create an ACL object and use setRoleReadAccess
to grant read access to a role:
const roleName = 'foo'; // this string is actualy calculated, but always non-nil and non-empty
const acl = new Parse.ACL();
acl.setRoleReadAccess(roleName, true);
Then I set that ACL to a new (unsaved) object:
const myObject = new MyObject()
myObject.setACL(acl);
The setACL
call causes an exception with the error message Tried to create an ACL with an invalid permission type.
which seems strange since I didn't provide a custom permission type.
Role
object instead of a string, but that didn't make a difference.permission
string must either match read
or write
; however, in my case that string matches the role name (in the example above "foo"
).I have similar ACL/role code in other parts of my app, so I'm sure this should work. Now I'm looking for hints -- what might cause the weird behavior that the role name is interpreted as permission type -- and tips on how to further debug this issue.
(Using parse-server version 2.3.3 and node.js 6.4.0; I'm currently locked to that Parse version.)
Upvotes: 0
Views: 855
Reputation: 6065
The issue was caused by having global.Parse = require('parse/node')
in a global Mocha test setup file; when running all integration tests (> 300 tests, taking about 4 minutes) this caused some weird effects like the mentioned Tried to create an ACL with an invalid permission type
, but also You cannot use [object Object] as a query parameter
; both errors only occurred when the runtime was under heavy load and running all tests -- just running a single test never produced any errors.
Details in this Github issue.
Upvotes: 1