isNewRecord() not working in ACL with REST

[phoang]

Hi,

I need an account to create records but also be restricted to Read with just new records.

In the table Read ACL, I've added if(current.isNewRecord() && gs.hasRole(XXX)){ answer = true;}

But it's not working when I go to the REST API Explorer to test.   I am not able to add any Fields to the Parameter.

Are you able to use isNewRecord with REST API?   Is there a way to do this?   We basically don't want this account to be able to GET records back that was opened by it but still be able to create.   And it looks like it needs read to create.

[bernyalvarado]

Hi Phuong,

Lets address first your read ACL. If it's a new record then noone else is going to be able to read it. Once its recorded to the DB then it stops been a new record. My advice will then be the you write the read ACL so that only the right roles can have access to it.

You can do that through scripting or just by adding the roles on the ACL.

Thanks,

Berny

[bernyalvarado]

In regards the write scenario,

Perhaps you can create a specific role for the user used for the REST API call. This role can then be added to a write ACL at the table level along with any other roles that should have access to write to that table.

I hope this helps!

Thanks,

Berny

[phoang]

So the requirement is for this account to be able to create a record and only be able to read records that this account created and no other and not do any updates. So when I give it read then it still able to pull back all records when using GET.   So I was thinking isNewRecord would be a way to restrict, is there another way to do this?

We have a number of different roles accessing this table with other ACLs with read/write.   So when you say ' If it's a new record then noone else is going to be able to read it.' the other ACLs will still allow the other roles access, correct?

[bernyalvarado]

Hi Phuong,

On regards your first question. You don't need to use isNewRecord, just create a ACL which grants read access to only the people that requires access to it. This can be accomplish through roles. If needed, you can also do it through scripting, just keep in mind that the script will assign answer = true; only when the evaluation needs to grant access. In other words, taking your script as an example:

if(!gs.hasRole('api_creator')){ answer = true;}

Please first note that ! which denotes that the record is given access when the user making the request does not have the given role (assuming for a second it's api_creator).

On regards your second question. The answer is Yes. Often when building new ACLs is important to evaluate the current existing ones at both, the table level and the field level. Look for opportunities to simplify these and make sure that any new ACL written does not have side effects over the other ACLs. Keep in mind that at a given level all the corresponding ACLs will be evaluated, if one succeeds, then the access will be granted. At the same time, is important to know that the table level ACL is always evaluated first. If the table level ones fail, then the .* or field level acls would not be evaluated.    

Thanks,

Berny