Hi, similar to : HIDE OBJECT WHEN ... of inspector
avoids creating new screens, tab or scripts associated with fields to ensure certain workflows (quality of information).
The cost would be one variable (IO) manageable from scripts.
Agreed, but I would call it "Disable When", which would prevent entry on fields and activation on buttons (for example).
Script triggers can already kick users out of fields (the layout object, not the schema object) they shouldn't be modifying, and scripts attached to buttons can already choose to exit early without performing their normal function based on a calculated condition. Adding this feature means that we'd have one more place to look for problems that manifest as fields and buttons appearing to not work for end users. The convenience of a check box vs. scripted logic might be nice, but is there any other functionality not possible by other means that you have in mind that might make up for the added complexity to the platform?
I've needed this occasionally when I need the user to be able to copy a value out of a field, but not change it. To Do so, I created a calc of the field and placed it over or instead of the actual editable field.
Agreed with terminology "Disable When". "Disabled" would be a state in the "Appearance" inspector tab.
The request I get most often is "I want any user to be able to copy the value from the field but only users with "Role X" to be able to edit the data. This could also solve some behaviors where you need to lock a field after a certain status is reached "Sales Order Status = Complete".
jbante is of course correct, we can already do this with combinations of scripts, but also security model and calculations. There is more flexibility with scripting this - but this could provide a "quick fix" that doesn't require script triggering everywhere the field exists.
We really could do with something like this but my feeling is it would be simpler to add a third tick box in the inspector alongside field entry "in browse" and 'in find mode". Perhaps called "browse select existing data only". The rest I can do with the existing Hide function
Yes, there needs to be "non enterable when" (calculation) option just like "hide object when" in the Data Inspector.
The default would be enterable for backward compatibility for existing layouts.
I don't how may times I had to use stacked fields one with browse and one without to achieve this, but this is a pain to manage.
And yes for another check box to allow you copy to the clipboard read only fields.
Also allow webdirect to copy a field to the clipboard by script as per client.
I respectfully, but strongly, disagree about this adding complexity or overlapping with existing "alternative" techniques!
To fully keep someone from modifying a field's value, yet still allowing them access to put their cursor in the field and even select and copy some text (ala the Address of an invoice or scroll a notes field, yet not change it) we currently have to jump through many hoops. Note that every web page you ever visit has this functionality natively provided, so users do want/expect this capability in a modern interface.
There are SO many cases where you need a user to be able to select text from a field both NOT modify it, in one or more particular layouts: Parent record fields on a list of children, Note fields that need a scroll bar, general purpose data viewing layouts where data entry is controlled... I would say 30%+ or fields on every layout we may fall in this category.
Two of the alternates generally suggested are a real pain:
1) Triggers to do this: Generally requires a dedicated Script and manually checkboxing AND selecting said script for one or more triggers, per field instance (which can only be set through a modal dialog!)! So we've added at least 5-6 clicks, selections etc... plus muddied the Scripts area and Script triggers on objects all over the layout, sometimes per field. Using triggers to do this adds tremendous unnecessary script processing overhead... yes triggers can accomplish this, but should they? I do not think so except in rare circumstances.
2) Field/Layout Level Privileges: Manually setting these settings in Security has been a pipe dream from day one, as it has to be VERY granularly set, out of context of the layout itself, and per privilege set, setting the not editable flag.
I personally don't think I need the Calculated version of this, though I'm sure I would use it... I'd be 95% happy with a set of similar checkboxes to the "Entry" ones, in the inspector, but controlling the ability to "Modify" a value, if entry is allowed.
I believe this would greatly "simplify" solutions for years to come! Click on inspector, you see in one glance what user's can do with that edit box or checkbox set, and can fix it with a click.
Hi, I will never understand the opposition to this feature. :-) With one variable i can define multiple escanarios !! use trigger is a patch solution .
... with a variable could Control the Views of Model .. "pseudo" :-)
Strong support for this feature!
Conditionally enterable in browse mode and find mode.
Just entered a similar idea - yours is even better - would like to join in
jwmickelson I so aggree. I just posted something very similar.
I also just added an idea like this. Great Minds Think alike. I should move looks like I added to wrong place like ideas. Conditional Record Locking
I would just be happy if you could scroll a field that is not modifiable. A no edit option is sorely needed.
Chad - use a web viewer for a scrollable field, not modifiable.
A common use case for me for this function would be allow data entry, but DON'T allow changes once the record has been exited, except maybe by elevated privileges. This is a regulatory requirement for many environments, where once the record has been saved, some (maybe not all) fields need to remain static for legal reasons. This can be done in permissions, but the complexity is greater, the permissions detail is low visibility (buried many dialogs deep and not obvious in a layout), and a really common need. Restricting field access to conditional situations, like content, or privilege set, are nearly identical to "Hide Object When", except it is "Disable Browse When" and becomes layout specific, not field level specific. (OK you CAN do this layout level in permissions, but the code becomes far more complex and not apparent for debugging).
I'm particularly interested in disabling buttons and other UI objects based on either inspector options or through a script step.
There are any number of ways to accomplish this that are superior to the current methods I have to use. Here are two:
1) disable button when: x
This would be similar to the hide object when calc in the inspector.
2) add behaviors to the conditional formatting interface
This would use the existing CF interface, but add options for disabling UI elements (changing a button to "do nothing" or preventing a slider from sliding) base on the calcs.
Either option would decrease complexity in the platform and is more intuitive for new users.
Currently to disable a button based on conditions I have go through this dance of hiding the button using the inspector's hide object calc, and creating a dummy button that looks grayed out OR I have to use conditional formatting to make the button look disabled, then alter my script to exit if certain conditions are met/not met. The first solution is hacky and cluttered, and the second solution is hacky and requires a multi-step script to be written and fired just to make magical nothingness happen.
This is a great idea.
I see its usefulness in WebDirect design, where click-through is not supported. In FileMaker Pro we can put the object twice: One locked and one available and then add a hide condition for each. This doesn't work for WebDirect. Hidden objects are rendered and then "hidden", making the trick impossible.
Lately what I have done is to put the locked field under the open field and then it does work on WebDirect but wit some quirks from time to time.
Then the question becomes,
"What else on the Inspector should be calculable?",
"Is there even anything in the Inspector that should not be calculable?"
the idea is this.
I'm all for the idea but really, we can do better on the UI, i.e. one that can evolve as we encounter new use-cases for enabling/disabling fields and other UI objects. Note that this method can eliminate the "Hide While Printing" checkbox on the first Inspector panel. Would love to see a tighter UI for the inspector altogether.
excellent Peter !!
although in the example I have the doubt between "enter" and "modify" .... for me both are "edit", which would be reduced to "hide" and "edit".
$$edit.enter = 1
$$edit.modify = 1
Clearly I may be omitting something,, ... ¿ what is the benefit of having "enter" and "modify" ?
$$no.edit.enter = 1
$$no.edit.modify = 1
Retrieving data ...