Potentially found Access Rules bug?

We have permission “Create” for users but they cannot create new rows to table? Special rules is denied but that should not block new row insert?

Blocked message is triggered for both actual user and simulated (view as) case:

image

Access rules are confusing.

Just last week I was creating a similar topic complaining about a potential bug in Access Rules then I realized I had done something wrong. I was seconds away from clicking to post the thread, after revising several times the access rules and not finding anything wrong with them… and then I found. lol

Not sure if the reason could relate to some of the columns? There is one with SELF_HYPERLINK and two with date formulas throwing errors due to initially missing data. To my understanding those should not prevent row insert (it works for OWNER role normally).

image

image

Found it. We need to remove the “Denied” from the " != OWNER " to make the restriction disappear. The users are EDITORS and somehow the “insert row” got not picked by the green R U C settings but fell through and got blocked before releasing the final denial.

@Rogerio_Penna you were right about this, yet I would like to learn the actual resoning behind here. Or if there was another (better) way to resolve this. But marking this resolved and pointing it partly to you as well.

If rec.kayttaja_email is a trigger formula with user.Email for the formula, then the first rule (condition user.Email == rec.kayttaja_email permissions R U C) should be sufficient to allow creating records. Is that the formula you have?

I must be failing the formula part…

Sure! After creating this (image) and calling the user.Email on trigger formula it worked as expected. Thanks for (reminding) how this works! (just picked emails from another table).

1 Like