UX View & Show_If Constraint Oddities

For the longest time I have been using SELECT statements to form my app around who is using it. I have known for quite a long time that this is not the most efficient way to go about it and recently decided to change this.

An interesting post I found by @MultiTech_Visions regarding this is here Current_User (Slice).

Generally, his method of conforming the app around WHO is using it, works wonderfully. Everywhere I was using SELECT statements, the expression builder dutifully informed me that the expression could impact performance. When I replaced those select statements with INDEX statements based on @MultiTech_Visions example, the expression builder no longer reported any performance issues.

The one exception has been with restricting views.

The expression IN(INDEX(CurrentUser[Role],1),LIST(Admin, Manager)) evaluates correctly BUT, the view is not shown.

The expression IN(ANY(SELECT(Users[Role], USEREMAIL()=[UserEmail])), LIST(Admin,Manager)) also evaluates correctly and DOES show the view.

Both expressions evaluate to the same results yet have opposite effects?

Any ideas would be greatly appreciated.

@MultiTech_Visions @Steve

Are you by chance using the “Preview As” list to switch to different users OR might you be the Co-Author in the app?

I have found that USEREMAIL() in Slices does not work correctly when the USEREMAIL() is NOT the App Creator. The wrong user info is present or none at all. I usually overcome this by temporarily hard coding the user’s email into the Slice filter criteria

1 Like

Thank you, but no. When evaluating whether the expression is working as I intend, I write the expression so that my [Role] will be returned in the expression.

I am aware of the shortcomings of the Preview As feature in this regard.

1 Like

Understood. And you have confirmed that the CurrentUser Slice has the data row you expect?

2 Likes

Yes.

The expression using the CurrentUser slice works as expected everywhere except UX Show_if constraints.

2 Likes

Ok, I have a similar CurrentUser/Role feature in one of my apps. I took your CurrentUser expression and used it pretty much as is in my app.

My Roles are based in a table and use UniqueID so I have used that REF value rather than actual text-based role names.

I am not seeing an issue for myself. I might suggest dissecting the expression to make sure the values you are expecting to be returned are indeed returned.

Condition with expected Role REF value - View shows

Condition does not include the Users Role REF value - View is hidden

2 Likes

My guess is the problem centers around your formula missing quotes

  • (Unless it’s the community that took them away when you posed the copy of your formula?)

IN(INDEX(Current_User[User_Role], 1), list("Admin", "Manager"))

  • Without the quotes around the options, the values you’re trying to compare aren’t technically strings - it’s whatever the system decide they are

    • So it’s likely that you’re encountering the problem of:
      [text_based_role_value] = *
      • Which might be true, or not - depending on what type the system assigns your list values.
2 Likes

I thought that too…but in my examples I, for that reason, left off the quotes…and it works! :man_shrugging:

3 Likes

Turns out the issue I was having was related to the expression used to filter the CurrentUser.

I was using AND(USEREMAIL()=[UserEmail],[IsActive]=TRUE). This evaluated correctly in the expression builder, the correct row was returned as true. HOWEVER…

When I built a table view based on CurrentUser, no results are returned.

I tried writing the expression several different ways to no avail… Nothing I tried would work when multiple criteria was used even though the syntax was correct and the expected results were returned in the expression builder.

Writing the expression with only one criteria is the only thing that is working for me: USEREMAIL()=[UserEmail]

2 Likes

Did you try testing it by temporarily replacing the USEREMAIL() function with the hard coded email address?

2 Likes

It also might be a type thing…

  • check and make sure that the type (I’m AppSheet) of the [Is active] column is a yes/no
  • check that the column in the data source is also marked as a yes/no
    • if you’re using Google sheets, setting the type to automatic will make this happen

Sometimes even if the data type is set correctly in AppSheet but it’s not correctly set in the data source, that can cause strange fringe cases - which this kind of sounds like it might be maybe.

1 Like

Just to confirm I definitely have two conditions in the filter for my current user slice, so it does work

In my User Table, the column User Email is of type email and the column Active is of type yes/no. Note that because the Active field is a boolean, I don’t actually have to specify =TRUE, but that should have no impact.

1 Like

For what it’s worth. I changed my Slice and the view “Show If” expressions to be constructed like yours. Just can’t reproduce your issue.

1 Like

Seems to have been the column type. The IsActive column was set as text type. Changing it to Yes/No seems to have resolved the issue… Not sure why I didn’t think of this…

Thanks for everyone’s help.
@WillowMobileSystems @Graham_Howe

2 Likes

Seems I may have Spoken too soon… This time regarding show_if and actions:

A user may belong to only one or several crews, i.e., Crew1, Crew2.
I need to show the action to the users that belong to Crew1 but no other crew.
The [Crew] field is set as Text type.

I have written the expression several ways, all which evaluate correctly but the action is not displayed:

  • ISNOTBLANK(INTERSECT(SPLIT(CurrentUser[Crew],","),LIST(“Crew1”)))
  • ISNOTBLANK(INTERSECT(SPLIT(SELECT(Users[Crew],USEREMAIL()=[UserEmail]),","),LIST(“Crew1”)))
  • CONTAINS(CurrentUser[Crew],“Crew1”)

Similar expressions are used to determine if a view should be shown to the user and those seem to be working as expected. Thusfar, the expression only seems to be failing when used in show_if of actions.

@MultiTech_Visions @WillowMobileSystems @Grant_Stead @Graham_Howe @Steve

You state in you requirements that

I need to show the action to the users that belong to Crew1 but no other crew.

However from your example expressions it looks like you are trying to match where the user belongs to at least Crew1. Which is it that you actually want to do?

If you want to check that a user only has Crew1 in the [Crew] field, then I would probably check first that the user has only one item in that list, then that the first item is equal to “Crew1”. Something like this:

AND(
  COUNT(CurrentUser[Crew]) = 1,
  INDEX(CurrentUser[Crew], 1) = "Crew1"
)
1 Like

There is a crucial step missing when calling a list

  • Concatenate()

Split(Current_User[LIST_COLUMN], " , ")
needs to be:
Split(Concatenate(Current_User[LIST_COLUMN]), " , ")


The original post was missing this, I just had Steve update the post so it had the correct formula. (It was so old, I couldn’t modify it anymore! lol)

2 Likes

Interesting, I hadn’t actually tried my suggestion, does that mean Current_User[LIST_COLUMN] is not actually presented as a list in the slice? So my COUNT and INDEX functions would fail?

image

1 Like

OK specific to SPLIT() when working on LIST() then. But I just noticed that I missed a crucial part of @Michael’s post. He said the [Crew] field is type text when I was assuming a list. So my suggestion of COUNT() and INDEX() will not work as is. The correct version should be:

AND(
  COUNT(SPLIT(CurrentUser[Crew], ",")) = 1,
  INDEX(SPLIT(CurrentUser[Crew], ","), 1) = "Crew1"
)