# Hiding and showing "private" portal rows based on a variable and portal row settings **URL:** \ **Category:** Questions\ **Created:** [May 15, 2021, 10:21pm UTC](https://the.fmsoup.org/t/hiding-and-showing-private-portal-rows-based-on-a-variable-and-portal-row-settings/2133 "2021-05-15T22:21:26Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![JasonMark](https://avatars.discourse-cdn.com/v4/letter/j/a9adbd/32.png) [@JasonMark](https://the.fmsoup.org/u/JasonMark)\ **Post date:** [May 15, 2021, 10:21pm UTC](https://the.fmsoup.org/t/hiding-and-showing-private-portal-rows-based-on-a-variable-and-portal-row-settings/2133/1 "2021-05-15T22:21:26Z")
I have a variable called $$View\_Private. I use it in scripts just fine, for example I have a button and when you press it it tells you if you can View\_Private (null or 1) But when I try to use it in a filter for a portal, it always registers as NULL. To debug it I tried to use it in a calculation field and it still comes off as NULL. What I want to do is filter a portal row so that if the person doesn't have the $$View\_Private permission and the item is private it will be filtered out, so I think this _should_ work, but doesn't... Student\_Case\_Engagement::Private \* Abs ($$View\_Private-1) Is this expected behavior? Do I need a global field (for example) set to this variable in order to filter by it? Or am I just missing something important... (I did uncheck "don't calculate if all fields are empty" ---
**Author:** ![steve\_ssh](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/steve_ssh/32/160_2.png) [@steve\_ssh](https://the.fmsoup.org/u/steve_ssh)\ **Post date:** [May 16, 2021, 1:24am UTC](https://the.fmsoup.org/t/hiding-and-showing-private-portal-rows-based-on-a-variable-and-portal-row-settings/2133/2 "2021-05-16T01:24:40Z")
> [@JasonMark](#): > > What I want to do is filter a portal row so that if the person doesn't have the $$View\_Private permission and the item is private it will be filtered out, so I think this _should_ work, but doesn't... > > Student\_Case\_Engagement::Private \* Abs ($$View\_Private-1) Though I am uncertain of the particulars of the behavior that you intend, the above looks suspicious to me. If $$\_View\_Private has been set to 1 (or True), then the above calc will result in the row being hidden. Is that what you intend? Also, any row for which Student\_Case\_Engagement::Private is set to 0 or empty or False will be hidden. But, on the other hand, a row which has Student\_Case\_Engagement::Private set to 1 will show if $$View\_Private is set to 0 or empty. Again -- I do not know whether or not you intend the above behavior, but it seemed a little contrary to my expectation, based on the names of the fields and variables. Perhaps it would be good to clarify this: A portal filter calculation works as follows: - If the calculation returns True, the row is displayed - If the calculation returns False, the row is hidden Also, something to keep in mind is that portals which use global variables in their filter calculations will need to be refreshed if/when the global variable value changes -- the change of value in the global variable, alone, is not enough to change the visual state of the portal without a refresh. HTH, -Steve ---
**Author:** ![MonkeybreadSoftware](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/monkeybreadsoftware/32/361_2.png) [@MonkeybreadSoftware](https://the.fmsoup.org/u/MonkeybreadSoftware)\ **Post date:** [May 16, 2021, 7:08am UTC](https://the.fmsoup.org/t/hiding-and-showing-private-portal-rows-based-on-a-variable-and-portal-row-settings/2133/3 "2021-05-16T07:08:16Z")
Do you have a sample database? It's more likely that you have a typo somewhere in a variable name or a refresh is needed. ---
**Author:** ![harvest](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/harvest/32/231_2.png) [@harvest](https://the.fmsoup.org/u/harvest)\ **Post date:** [May 16, 2021, 8:36am UTC](https://the.fmsoup.org/t/hiding-and-showing-private-portal-rows-based-on-a-variable-and-portal-row-settings/2133/4 "2021-05-16T08:36:08Z")
> [@JasonMark](#): > > Abs ($$View\_Private-1) maybe just (Abs($$View\_Private)-1) ---
**Author:** ![JasonMark](https://avatars.discourse-cdn.com/v4/letter/j/a9adbd/32.png) [@JasonMark](https://the.fmsoup.org/u/JasonMark)\ **Post date:** [May 16, 2021, 2:43pm UTC](https://the.fmsoup.org/t/hiding-and-showing-private-portal-rows-based-on-a-variable-and-portal-row-settings/2133/5 "2021-05-16T14:43:03Z")
Thank you all. @steve_ssh it was a refresh problem, also you're right, my formulas was wrong. should have been. \> Abs ( > ``` > Abs( > $$View_Private - 1 ) > * > (Join::IsPrivate ) > -1 > ) > > ``` @MonkeybreadSoftware once I had the refresh problem I was able to get a sample file to work. I'm including it here in case anyone else needs help with it, although I'm not sure my title does it justice so I'll update it for clarity. [VariablesSimple.fmp12](https://the.fmsoup.org/uploads/short-url/46EpSrjhqrd7u1R8K7HR7VfcGHh.fmp12) (444 KB) ---
**Author:** ![steve\_ssh](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/steve_ssh/32/160_2.png) [@steve\_ssh](https://the.fmsoup.org/u/steve_ssh)\ **Post date:** [May 16, 2021, 3:24pm UTC](https://the.fmsoup.org/t/hiding-and-showing-private-portal-rows-based-on-a-variable-and-portal-row-settings/2133/6 "2021-05-16T15:24:04Z")
Hi @JasonMark Thanks for the update on this. ``` Abs ( Abs( $$View_Private - 1 ) * (Join::IsPrivate ) -1 ) ``` I would like to humbly offer a few alternatives to the calculation that you have posted above. It may be that the above (what I might refer to as an "arithmetic" style of implementing the logic) works well for you, that is to say is easy to read and understand. For myself, I find it a little easier to read a version which uses some of the FMP logical operators. I will include some ideas below, in case it is of interest. **Version 1: Literally rewrite the arithmetic version using logical operators:** ``` not( not $$View_Private and Join::IsPrivate ) ``` **Version 2: Simplify by avoiding the outer negation:** ``` $$View_Private or not Join::IsPrivate ``` **Version 3: Use a Case statement:** ``` Case( $$View_Private ; True ; Join::IsPrivate ; False ; True ) ``` Assuming that $$View\_Private and Join::IsPrivate are only set to values of either 0, 1, or "", then the above variations will produce the same results as your original calculation. I'll note that while I might use a Case statement (version 3) for scenarios with more variations of outcomes and possibilities, in this particular case, I personally find Version 2 to be the most readable. Also: If any of this "readability" topic feels of interest, I highly recommend checking out a recording of any presentation that @Bobino has given which covers the topic of how to write readable and maintainable code. A link to one such recording is [here](https://www.youtube.com/watch?v=n5xQtyMAa6w). **Last topic:** I downloaded your sample file (thanks for posting). My suggestion would be to get into the habit of using the _Refresh Portal_ script step to refresh your portals, and not the R_efresh Window with the flush cache options enabled._ In the short term, it may not matter much, and R_efresh Window_ might even seem more convenient because it does not require you to name your portal layout objects, but, should you ever find yourself working on larger solutions with lots of record data, you may find that flushing the cache is an action which should not be taken lightly, as it may result in users having to re-download record data which they otherwise would have had available to them in their cache -- meaning, it can translate to a performance penalty if used unnecessarily. Hope all of the above may help & kind regards. ---
**Author:** ![Cecile](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/cecile/32/98_2.png) [@Cecile](https://the.fmsoup.org/u/Cecile)\ **Post date:** [May 16, 2021, 5:28pm UTC](https://the.fmsoup.org/t/hiding-and-showing-private-portal-rows-based-on-a-variable-and-portal-row-settings/2133/7 "2021-05-16T17:28:02Z")
Talk about going above and beyond! Thank you Steve for not only providing a solution to the issue presented but to provide comments that will enable us to learn to use FileMaker features more efficiently and to become better developers!!! ---
**Author:** ![Bobino](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/bobino/32/194_2.png) [@Bobino](https://the.fmsoup.org/u/Bobino)\ **Post date:** [May 16, 2021, 7:15pm UTC](https://the.fmsoup.org/t/hiding-and-showing-private-portal-rows-based-on-a-variable-and-portal-row-settings/2133/8 "2021-05-16T19:15:30Z")
That is very interesting @steve_ssh I think your options 2 and 3 also can have performance benefits (on top of improving readability as you point out). When an expression makes use of AND, both elements need to be evaluated to get to the outcome. I would expect FileMaker's calculation to be optimized for OR (the case statement sure won't evaluate items after the first test that is true) where if we have $A OR $B, assuming $A to be true, I would hope that $B would not get evaluated. I did not test for that. Perhaps @nicklightbody knows something about this he may share with the rest of us? ---
**Author:** ![Malcolm](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/malcolm/32/196_2.png) [@Malcolm](https://the.fmsoup.org/u/Malcolm)\ **Post date:** [May 16, 2021, 9:33pm UTC](https://the.fmsoup.org/t/hiding-and-showing-private-portal-rows-based-on-a-variable-and-portal-row-settings/2133/9 "2021-05-16T21:33:55Z")
> [@harvest](#): > > maybe just > > (Abs($$View\_Private)-1) For this segment of the calculation, how about skipping the Abs function altogether. `1 - $$View_Private` ---
**Author:** ![JasonMark](https://avatars.discourse-cdn.com/v4/letter/j/a9adbd/32.png) [@JasonMark](https://the.fmsoup.org/u/JasonMark)\ **Post date:** [May 17, 2021, 11:19am UTC](https://the.fmsoup.org/t/hiding-and-showing-private-portal-rows-based-on-a-variable-and-portal-row-settings/2133/10 "2021-05-17T11:19:37Z")
@steve_ssh You're amazing. Thank you! ---
**Author:** ![FileKraft](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/filekraft/32/1183_2.png) [@FileKraft](https://the.fmsoup.org/u/FileKraft)\ **Post date:** [May 17, 2021, 6:04pm UTC](https://the.fmsoup.org/t/hiding-and-showing-private-portal-rows-based-on-a-variable-and-portal-row-settings/2133/11 "2021-05-17T18:04:16Z")
> [@Bobino](#): > > When an expression makes use of AND, both elements need to be evaluated to get to the outcome. not quite true (maybe true for FM ??) - look at if one side of the AND results in false then no need to evaluate the other side because it will always be false. AND and OR are symmetric and interchangable thanks to deMorgan's law. ---
**Author:** ![Bobino](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/bobino/32/194_2.png) [@Bobino](https://the.fmsoup.org/u/Bobino)\ **Post date:** [May 17, 2021, 11:27pm UTC](https://the.fmsoup.org/t/hiding-and-showing-private-portal-rows-based-on-a-variable-and-portal-row-settings/2133/12 "2021-05-17T23:27:10Z")
You are absolutely right @FileKraft. I tend to think of statements to be evaluated as true, but indeed, if you are looking for a false output, favoring the most likely false one to be early in the chain should perform better.