Hiding and showing "private" portal rows based on a variable and portal row settings

Questions
1

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"

2

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

1 Like
3

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.

4

maybe just

(Abs($$View_Private)-1)

1 Like
5

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 (444 KB)

2 Likes
6

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.

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 Refresh Window with the flush cache options enabled. In the short term, it may not matter much, and Refresh 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.

5 Likes
7

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!!!

2 Likes
8

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?

2 Likes
9

For this segment of the calculation, how about skipping the Abs function altogether.

1 - $$View_Private

1 Like
10

@steve_ssh You're amazing. Thank you!

1 Like
11

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.

4 Likes
12

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.

4 Likes