Hi. Iโm using the security filter to filter rows a user sees. I have set up a rule which should return โYโ, but returns โNโ. You can see the userโs ID in the list (ne of two key). Can anyone explain why this us returning โNโ?
I donโt have permission to view the image.
Could you post the expression your are using? Also have you tried using the expression tester to debug it?
Hi Guys. Iโve tried to give permissions to the image that shows the results of the test of the expression. The Expression passes the syntax check and itโs the โTestโ that doesnโt provide the expected result. Iโm wondering if I need to use โINCLUDESโ rather than โINโ? The list I am checking for the inclusion of the key is returned from an inline list from a referenced table. (The โUserโ is a โTeam Memberโ and their ID is in the โTeam Members Listโ which is a Slice).
First try to type the formula with fixed user ID, like IN(โIWIqJbWEโ,โฆ) so you would have a hunch which one could be the reason.
@Aleksi_Alkio Thanks. Iโve figured it out. Rather than using โINโ, I need to use โCONTAINSโ. Iโm guessing this is because, rather than being the result of a SELECT, and therefore a true List, this series of IDโs returned from the referred table is simply a comma-delimited string, and not a true List. Iโve changed to โCONTAINSโ and itโs now working as expected.
If the โlistโ is coming from the one text cell, you could read the โlistโ with the IN expression likeโฆ IN([User],SPLIT(LOOKUP(โKeyColumnValueโ,ThisAppUserMonitoredTeams,KeyColumn,Team Members)," , "))
@Aleksi_Alkio Thanks. The value Iโm looking for ([User]) is actually the ID thatโs already in the string, so I donโt need to look up another value from the table. Good to know I can though, if I need to somewhere else. Thanks!
@Stephen_Robb, @Aleksi_Alkioโs suggestion to use SPLIT() and IN() is a good one. Using CONTAINS() could result in false positives if the userโs name is short and may occur as part of some longer name (e.g. โstevenโ contains โsteveโ but isnโt an exact match).
+Steve Coile Thanks Steve. Note that Iโm using keys (generated using UNIQUEID) rather than actual names, so no chance of false positives in this instance. I wasnโt aware of the LOOKUP function though, but have already been able to use it in a couple of instances to make things more streamlined.
User | Count |
---|---|
36 | |
34 | |
27 | |
23 | |
18 |