Conditional Access to Fields

[davidnickerson]

I'm working on a solution for a client that requires conditional hiding of a large group of fields on a layout.

 

If Condition A, all the fields are displayed and are accessible.

If Condition B, the fields are not displayed and are not accessible.

 

The trick (for me, at least) is figuring out how to make them inaccessible.

 

A large, conditionally-formatted field, which would be used to hide the group of fields, cannot be made to prevent access into the hidden fields.  I.E., the fields are "hidden", but they can still be clicked into.

 

A large, conditionally-formatted button, which also would be used for hiding, presents a similar issue:  If no script is assigned to the button, the fields are still accessible behind it; if a script is assigned, the user can't click into the fields at all, even when they're not hidden.

 

I'm trying to avoid having to create a separate layout to handle this, in part because there are multiple tabs on this layout which all require the same conditions, and thus I'd need something like 8 additional layouts.

 

Am I missing something obvious?  I.E., is there a simple way to conditionally make fields both hidden and inaccessible?

 

Thanks in advance for any assistance with this.

[davidnickerson]

I should also clarify that I'm not looking for the hidden fields to be non-modifiable, eg., by changing Security settings, but rather completely hidden, even when the hidden area is clicked into.

[LaRetta]

You can use a portal where breaking the relationship completely 'removes ' the fields. You would probably use a self-join based upon the main table's primary key. Then portal filter evaluating to true will display the fields.

[davidnickerson]

Yes, thanks, I had thought about the portal solution earlier.  The layout in question has 5 tabs, 4 of which involve separate relationships, so I'd need 5 additional relationships and portals to achieve the desired result, but that would do it.

 

I was hoping that some clever individual had figured out a way to make "browse access" to fields (i.e., field behavior attributes) conditional, or something similar using script triggers.

[LaRetta]

Restricting entry to field is far cry from your request of 'completely hidden'. Yes you can stop entry using trigger OnObjectKeystroke or probably in your case OnLayoutKeystroke would be best. There are many good threads here with examples.

[LaRetta]

Sorry I was not where I could search to provide a link.  Here's a good discussion on the subject:

 

http://fmforums.com/forum/topic/86199-make-fields-read-only/

[davidnickerson]

Restricting entry to field is far cry from your request of 'completely hidden'. Yes you can stop entry using trigger OnObjectKeystroke or probably in your case OnLayoutKeystroke would be best. There are many good threads here with examples.

 

LaRetta, thanks for your efforts.  Sounds like I haven't made myself clear, though.

 

I can't use OnObjectKeystroke.  The fields need to be inaccessible and hidden before any keystroke into them.  That's what I'm trying to avoid...having the user accidentally click into a field that's hidden.

 

Can't use OnLayoutKeystroke, there are many other fields on the layout that need to be accessed.

 

Also, you say "Restricting entry to field is far cry from your request of 'completely hidden'."  Again, "completely hidden" should mean simply, not visible to the user under any circumstances.  If I were to use a conditionally-formatted text field or button, that fills with white (or whatever background color) under a certain condition, but is transparent otherwise, and then place a field underneath the conditionally-hidden field/button, and then UNCHECK the box for Field Entry in Browse Mode, that field would be completely hidden to the user.  

 

However, if the box IS checked for Field Entry, the user can still click into it despite the presence of a white-filled field or button superimposed over the top of it.

 

I'm looking for a way to have that Field Entry access unavailable when the condition is met and the field is hidden.

[Vaughan]

... "completely hidden" should mean simply, not visible to the user under any circumstances.

 

"Under any circumstances" can only be achieved using record-level access security.

 

Remember that data can be accessed through layouts in the same file as the table, layouts in a different file, or through the export command. People often spend large amounts of time building an interface that restricts the display of the data, but neglect the possibility of accessing data from a different file or by export. RLA works on the data level, not the interface level.

[David Jondreau]

Use a tab panel and an onRecordLoad script trigger. The prohibited tab can be hidden completely by setting the label to Full justification and 0px of fixed width. Name both tabs and have an onRecordLoad triggered script go to the correct tab.

[davidnickerson]

"Under any circumstances" can only be achieved using record-level access security.

 

Remember that data can be accessed through layouts in the same file as the table, layouts in a different file, or through the export command. People often spend large amounts of time building an interface that restricts the display of the data, but neglect the possibility of accessing data from a different file or by export. RLA works on the data level, not the interface level.

 

Thanks, Vaughan.  As I mentioned earlier, this is merely a interface necessity.  I'm not concerned with security for these fields.  You're describing data access; I'm describing field entry behavior (also mentioned earlier).  If a user clicks on the "blank", hidden area, as I described above, they can accidentally click into the hidden fields.  This will be confusing to the user, nothing more.  That's all I'm trying to prevent.

Use a tab panel and an onRecordLoad script trigger. The prohibited tab can be hidden completely by setting the label to Full justification and 0px of fixed width. Name both tabs and have an onRecordLoad triggered script go to the correct tab.

 

This is a method I haven't explored before.  Thanks for the suggestion; I'll give it a whirl.