"Preview app as" when saving

I have the following table structure:

  • User
    • Name
    • Email
  • Group
    • Name
    • Primary (only one group has this flag)
  • User Group
    • User
    • Group
    • Role (Read, Read/Write, Admin)
  • Customer
    • Group
    • Name

A user should be able to see only those customers that are owned by a group to which the user belongs. The entry point to the application is the “Customer” table view. Rather than create a slice, I set a security filter on the “Customer” table:

COUNT(FILTER(User Group, AND([User].[Email] = USEREMAIL(), [Group] = [_THISROW].[Group]))) <> 0

I’ve been testing under my own email for a while, and I’m now verifying that the app behaves as it should for users in other groups and with less privileged access. To do this, I’m setting “Preview app as” to the email address of another user.

It works fine until I press the “SAVE” button to save the latest iteration of the app. As expected, the app resets and gives me the “Customer” table view, but the content of that view is the list of customers that my real email has access to, not the ones available to the user I’m testing with. To force the security filter to be applied with the “Preview app as” email, I have to press the “Sync” button in the top right of the app.

Interestingly, other aspects of the app respect the “Preview app as” setting on save. The ability to manage groups and users is restricted to administrative users within the primary group only, and so the “Group” table view in “PRIMARY NAVIGATION” has “Show if” set to the following:

COUNT(FILTER(User Group, AND([User].[Email] = USEREMAIL(), [Group].[Primary], [Role] = "Admin"))) <> 0

When I save the app, the primary navigation bar shows only those views that the “Preview app as” user has access to. It’s just the security filter on the table that’s picking up my real email address on save.

Unfortunately, this is as much as I can provide. I don’t have the cycles to carve out a sample app. Hopefully this is enough to identify and fix the problem.

Here are some options to consider:

  • User only contains the current user:

    (USEREMAIL() = [Email])
    
  • User Group only contains entries for loaded users:

    ISNOTBLANK([User].[_RowNumber])
    
  • Group only includes groups in User Group:

    IN([Group], User Group[Group])
    
  • Customer only includes those assigned to loaded groups:

    ISNOTBLANK([Group].[_RowNumber])
    

The “User” and “Group” tables are used elsewhere in their entirety, so I can’t put security filters on them. I do have an “Active User” slice that filters exactly as you propose.

The problem is not the filter itself. I’m getting a filtered view (i.e., not all customers), so the security filter is being applied. The problem is that the security filter is being applied as if USEREMAIL() is my logged in email address, not the “Preview app as” email address.

This happens only after saving changes to the app, it happens only in the security filter, it doesn’t happen in other parts of the app that call USEREMAIL(), and it goes away once I press the “Sync” button.

Oh, yeah. This is a long-standing bug in the app emulator.

1 Like

Something that many of us have done as a standard operating procedure for EVERY app we build that has a users type table, is create a Slice that captures the Current User row.

The Slice encapsulates a SINGLE place where the USEREMAIL() credential is used to identify the current logged in user. It greatly simplifies accessing the current user details across ALL of the app. You can use an expression like: ANY(CurrenUser[Desired Column]) to grab any of the desired details you want. And it is very efficient.

AND…an added bonus is that you can temporarily change the USEREMAIL() usages in this slice to the actual email address you wish to “Preview app as”, populating the CurrentUser with the row you want and the rest of the app will perform as expected for THAT user.

Take a look…it is WELL worth the time to implement it!!!

This is explained in great detail with this Tip posted by @MultiTech long ago:

2 Likes

I do that already. I’m just logging a bug, which @Steve has acknowledged exists. Thanks.

1 Like