Hide Object based on Status of Button Bar

[tshramek]

Hello,

Sorry if this has been asked and answered, but I could not find it.  Probably using wrong verbiage in search or something.

I would like to use the Hide Object (and its associated Calculation) to either show/hide a Field that effectively covers the entire Layout.  This is to Lock/Unlock the ability to modify data in a current layout.  

I am able to accomplish this with a button bar that populates a separate field based on the button that is pressed and then reference that field in the Hide Object Calculation.  However, this seems a little convoluted.  

Is there a calculation that can get the status of a button bar (i.e., which button was last pressed)?  This would remove the need for an extraneous field that just records this data since I could base the Hide Object directly on the status of the Button Bar.

Thanks in advance!

Troy

[Fitch]

No, but rather than using a field, you can set a variable and base the hide condition on that.

Make sure to name the variable with two dollar signs so it's global. E.g. $$hide

https://fmhelp.filemaker.com/help/18/fmp/en/#page/FMP_Help%2Fset-variable.html%23

[comment]

10 hours ago, tshramek said:

a Field that effectively covers the entire Layout.  This is to Lock/Unlock the ability to modify data in a current layout.  

I would prefer to use a tab or slide control object for this. 

 

[tshramek]

@Fitch: if it is a $$variable would that not affect all records in a given layout?  Since they would all be looking to that Global Variable, and thus all records would either be locked or unlocked?

@comment: I am not familiar (or experienced enough) with what you are suggesting.  Would you mind elaborating?  

Edited June 10, 2020 by tshramek

[comment]

I have a better idea: why don't you first explain what is the purpose of this exercise. At first I thought you wanted to prevent accidental editing of record data; now I am not so sure. I certainly cannot see any use for a layout that's entirely obscured by an opaque object. If you don't want the user to see what's on the layout, don't show them the layout.

If this is about what users are allowed to see or do, then this is entirely on the wrong track. There is no security in layout measures. 

 

 

Edited June 10, 2020 by comment

[tshramek]

@comment

The issue I am having is employees are typing over previous orders (these are for glasses or contacts at an Optometrist office) as opposed to understanding they need to create a new order.  I have buttons set up to create the new order with the appropriate Key so it links to the correct patient, but they still have to use it.  

So the 'Locked' field I made is transparent and populated with the word "Locked".  It prevents anyone from typing in any field other than the button area to make a new record....thus not giving them the ability to type into and/or over data....but still allows them to view the order data behind the transparent 'Lock' field.  (Please see attached images for the 'Unlocked' and 'Locked' states.

So the issue is not really security related in the sense that they can't VIEW the data, in fact they need to be able to view it on occasion.  The issue is all about stoping them from typing over data.  Sometimes you can train until you are blue in the face and they will still just do it wrong here and there.

Thank You for your time!

[comment]

I would have 2 buttons: Edit and New. Pressing the Edit button would set a Locked field to 0 (or empty). Pressing the New button would create a new record with the Locked field initially set to 0 (or empty). A critical point here is to make sure the Locked field is set to 1 when user is done editing/creating the record. Then allow users to edit a record only when:

not Locked 

This is assuming you want to allow users to edit past records. Otherwise you could take advantage of a handy built-in feature: if you allow users to create records but not to edit them, they will be able to create a new record and modify it until the end of the current session. After that the record will become locked, with no need for additional fields or buttons.

 

25 minutes ago, tshramek said:

So the issue is not really security related

I believe it is - and the above is based on this belief. But if you disagree, you could do what I suggested earlier: use a slide control with two panes and place the same set of fields in each pane, with one set (in the default pane) having the entry disabled. Then the Edit button would simply switch to the other pane, and the New button would create a new record then switch to the other pane.

The downside of this is that they cannot copy from non-enterable fields.

One more note about your original question:

On 6/9/2020 at 7:51 PM, tshramek said:

This would remove the need for an extraneous field that just records this data since I could base the Hide Object directly on the status of the Button Bar.

A button bar has no status, so you cannot base anything on it. A button performs an action. If you want to rely on the action, you must record it in a field or in a variable. And you must decide what type of field or variable to use, since they are vastly different in scope.

For example, using a global variable to lock/unlock editing would work only for the current session of the current user and affect all records. However, it is possible to create an individual variable for each record.

 

 

[tshramek]

@comment

I like the idea of allowing a set of users to create and then edit for the current session.  

How do I define a session? This is a feature I am not aware of, but will do some google/youtubing to learn about for sure.

Is 'Session' security defined based on User Groups or globally for all Users?

[comment]

A session lasts from user opening the file (login) until they close it.

 

Edited June 10, 2020 by comment

[tshramek]

@comment

Thanks for your help and clarification with regards to what a session is.

Last follow up question....How do you lock at the close of a session?

[comment]

2 hours ago, tshramek said:

How do you lock at the close of a session?

You don't. Records become automatically locked because users do not have the privilege to edit them.

[tshramek]

@comment Thank You for taking the time to help!