Error data not accessible when i use CurrentUser Slice in security filter

GFormMLH_0-1661162156554.png

Hi everyone. I'm trying to create a security filter that will filter rows depending on the user (custom) roles (Chef, Super Admin, Admin or Basique). 

Super Admin should be able to see every row, Admin only Chef and Basique rows, and Chef can see only Basique rows. 

This is the formula i'm using : 

IF(INDEX(Current_User[Position], 1) = "Super Admin",
true,

IF(INDEX(Current_User[Position], 1) = "Admin",
and([Position] = "Chef", [Position] = "Basique"),

IF(INDEX(Current_User[Position], 1) = "Chef",
[Position] = "Basique",true)
))

GFormMLH_1-1661162252703.png

This is the slice i'm using to ref the current user : 

GFormMLH_2-1661162407163.png

Any help is welcomed !

Solved Solved
0 5 140
2 ACCEPTED SOLUTIONS


@dbaum wrote:

In your case, likely the Current User slice is based on the Users table, in which case the Users table's security filter won't be able to reference the table's own slice.


For filtering your User table, use a Slice instead.

  • Though of course there's about half a dozen options that come to mind for ways to make this work... many of which are detailed here in the community.

View solution in original post

Change your table's security filter to directly reference the USEREMAIL function rather than referencing the Current User slice. Implement a technique based on a cloned subset of your Users table that governs which users have access to rows from the Users table beyond their own row. You can still use the Current User slice elsewhere in your app.

View solution in original post

5 REPLIES 5

In my experience, the first thing to check is whether there's a circular reference in a table security filter. It's easy to end up with that in tables like org and users, and AppSheet isn't good about flagging this condition. Confirm that any rows (from the same or a different table) referenced in a security filter expression can be loaded by the app without first evaluating that security filter expression.

In your case, likely the Current User slice is based on the Users table, in which case the Users table's security filter won't be able to reference the table's own slice.

Change your table's security filter to directly reference the USEREMAIL function rather than referencing the Current User slice. Implement a technique based on a cloned subset of your Users table that governs which users have access to rows from the Users table beyond their own row. You can still use the Current User slice elsewhere in your app.


@dbaum wrote:

In your case, likely the Current User slice is based on the Users table, in which case the Users table's security filter won't be able to reference the table's own slice.


For filtering your User table, use a Slice instead.

  • Though of course there's about half a dozen options that come to mind for ways to make this work... many of which are detailed here in the community.

Thank you @dbaum and @MultiTech ! 

You're right, there a many answers in the community, i'm trying my best to find them myself and solve my problems. Most of the time I feel dumb for not finding it myself 😣

Still, thank you for helping me. Have a nice day !


@baba_sawane wrote:

Most of the time I feel dumb for not finding it myself :persevering_face:


DON"T!!!!!

  • 1/2 the problem is the "newness" of the community.

--------------------------------------------------------------------------------------------

Try this:  Do a search for "Current User"

  • Where do you find the post for the "Current User System" ?
  • You would think it would be towards the top no, having literally the exact string that matches the start of the post....

  • Nope... page two

  • That post is LITERALLY the answer to tons of questions.  The answer is either the post itself, one of the detailed uses, or somewhere in the comments people asked over the years about how to use it.

  • But you can't find that answer... because it's on page 2
         - In fact when I just did a search, it didn't even come up!  #Figures!

So don't feel bad about not being able to find an answer

(This is 90% of the reason for starting AppSheetInsider.com;  that can be a curated space of quality answers that you can trust.  Literal answers, not questions or work arounds.)

Top Labels in this Space