Hide Object based on Field Value and Permission

[iroc_mxrider]

Hello,

Full disclosure: I am very new to scripting in FM.

I am trying to hide an object based on 2 criteria:

Leads::IsOnlineProposal = "No" and PatternCount (  $$Permissions ; "ViewOnlineProposal" ) = 0

When the Value for Leads::IsOnlineProposal is "Yes" I wanted my object ( just a big square to hide the customer data on the screen ) to hide everything on the screen. That part works great. But I wanted to give some users permission to still view the customer info ( or continue hiding the object ) when the permission is checked even if the value for Leads::IsOnlineProposal = "Yes". Thus the second part of the hide scripting in the hide section of the inspector. I cannot seem to figure out what to input into inspector to achieve this. Can anybody point me in the right direction? Any help is much appreciated. Hope it all makes sense! Thank you in advance, sorry if I posted in the wrong section!

[doughemi]

If I'm following your logic correctly, I think you want

Leads::IsOnlineProposal = "No" or PatternCount (  $$Permissions ; "ViewOnlineProposal" ) = 1

 

[LaRetta]

I think you nailed it, Doug!  We could even drop the = 1 at the end since any number of matching patterns would return boolean true. 

Hi Iroc, welcome to FMForums!

If you are using a rectangle to hide the fields, it will work IF the 'allow entry' has been turned off.  It works better to place fields on a single-panel slider or tab control (it can easily be made invisible) and attach a single 'hide' calculation to that instead; it is much more efficient. Also, if you forget to disallow entry at some point, a User can still accidentally click into the area and land in a field and could change the value. Also consider how this all behaves in find or preview if there is a chance (even if slim one) that User might evoke that mode.

Another consideration is permissions ... it is always much safer to use your Security to control permissions.  But if you allow a User to set the $$permissions value (via a checkbox?) then I suppose it's more of a safety-switch so Users don't accidentally change a record?  Since you are admittedly new to FileMaker, we are here to help so feel free to use all of us.  Getting a good start in your design is the most important part and there are some great people here to help you.   :-)

One more thing ... there is much to be said about using a second identical layout and allow edits there.  Keeping duplicate copies has its downfalls but if your layouts are pretty-much done with the design part, it might be worth it.  Layouts are fairly inexpensive and a switch between the two could be as simple as checking that checkbox or button to set the $$permissions (instead it would be Go To Layout[]).  If you have many objects on the layout, particularly portals or conditional formats or other calculations, sometimes offloading much of that schema makes your current layout much faster.

So if most Users use the layout just to bop around record to record and view the front layout, offload to a second layout which may even contain child records that the first layout wouldn't have to even fetch from server.  

One more thing, please forgive me ... but if there are just a handful of fields of which you are wanting to control edit and/or view, you can use two panels of a slide control; one with edit rights and one with read only.  Then simply use the hide calculation when you want to completely hide all those fields.

Edited September 29, 2017 by LaRetta

[iroc_mxrider]

Hi Doug and LaRetta,

 

Sorry for the late response, and thank you for responding! I tried Doug's suggestion, and when the permission is checked to allow the view of the data on the screen and not have it covered by the object, the object is still displayed (when the first criteria is also met i.e. the Leads::IsOnlineProposal = "No") The object then disappear when that field is set to "No", which is perfect, but for some reason its still not hiding the box when a user who has permission to view the data behind it is on the record. I hope that makes sense.

LaRetta, You are right, I did not consider the Find mode. I would need to incorporate that object to be hidden in find mode as well. Is that something that can also be scripted into the inspector hide portion?

As far as having a duplicate layout, that was my first thought as well! Unfortunately though there are over 600 fields that have relationships with other tables that I believe would need to be re associated as well wouldn't they? What i really wanted to do was create a separate module for these records and have them be moved from our Leads/Appointments Module to its own module Called Online Proposals via a script trigger (button click) to move them over to a separate area as they are now different style leads, and have only certain people be able to access that module. This seemed like a very large undertaking and for now at least if i could just hide that data from the users i want to hide them from that would be almost as good. 

I really appreciate all the help! Thank you guys for bearing with me! 

[comment]

18 hours ago, LaRetta said:

it is always much safer to use your Security to control permissions.

I agree. There is a big red flag waving over this question. If this is an attempt to deny some users access to some records, then it's bad practice and wholly unsafe.

[LaRetta]

21 hours ago, iroc_mxrider said:

Unfortunately though there are over 600 fields that have relationships with other tables that I believe would need to be re associated as well wouldn't they?

A duplicate layout wouldn't mean (correction - WOULD MEAN ) the same table occurrence - just duplicate the existing one and manipulate the field behavior in the other.  But 600 fields suggests, in all probability, that you do not have an optimized structure.  Your consideration of moving many of these fields to another table is wise but still ... it sounds like you have 'questions' as fields in a table when they should be records.

21 hours ago, iroc_mxrider said:

for these records and have them be moved from our Leads/Appointments Module to its own module

Seriously, between 600 fields and your desire to hide fields based upon different layouts instead of using permissions are probably serious design flaws which should be addressed before you proceed any further with your design.  I highly recommend that you seek the input of a developer who can review your file.  You can post your file here for suggestions but I suggest that you hire a professional developer to help you get your structure corrected.  The base structure is the most important and correcting it now will save you hundreds of hours over trying to correct it later.

Edited September 30, 2017 by LaRetta

[iroc_mxrider]

Hi LaRetta,

I appreciate your input! I agree with everything you've mentioned. This database is over 15 years old and has had many many different developers hands in it. Most of it is sound. Just very cluttered, and lots of stuff that isnt used any more. It would need hundreds of hours just to get it clean again. We do have a developer we work with, but sometimes im able to do small tasks. Ive reached out to him for further support. I appreciate your help! Thank you for taking the time with me! 

 

 

[LaRetta]

23 hours ago, iroc_mxrider said:

Most of it is sound. Just very cluttered, and lots of stuff that isnt used any more. It would need hundreds of hours just to get it clean again. 

Most likely, it is far simpler to start over and use the original as your blueprint.  Files that old have probably suffered several crashes and, as you say, contain a lot of garbage.  And with new tools, as well as optimized file structure and rendering (with CSS etc), a fresh file is the way to go.

On 9/29/2017 at 12:39 PM, iroc_mxrider said:

I tried Doug's suggestion, and when the permission is checked to allow the view of the data on the screen and not have it covered by the object, the object is still displayed (when the first criteria is also met i.e. the Leads::IsOnlineProposal = "No") The object then disappear when that field is set to "No", which is perfect, but for some reason its still not hiding the box when a user who has permission to view the data behind it is on the record.

Try the attached example file (you must be signed in to retrieve it).  Note that I placed all the fields on a single-pane slider instead of placing a rectangle over the fields.  It is more efficient to hide a panel with a single hide calculation than to attach the hide to many individual fields.  It is also safer because if you place a field on the layout and forget to disallow field entry, you risk the field being entered even if a rectangle is on top of it.

I used a global field for $$permissions but the principle is the same.  Is this right?  If not, please say again now how it fails and we'll modify it for you.  :-)

 

I realize this isn't right.  But with a working demo to use, we can pin down your needs much easier.

HideObjectWhen.fmp12

Edited October 4, 2017 by LaRetta

[Lee Smith]

Hi iroc, and welcome to the FM Forums,

I move your question from the Conditional Formatting Topic, to the Layout Topic. It is a better fit to your question.

I sent you a Private Message with some additional information.

Lee