However, FileMaker client has previously allowed the system developer to utilise layouts and scripts which are for their own use. The client interface was able to be secured sufficiently for these objects to remain in the files. That is no longer true.
Importantly, many people will have been relying on the historical fact that it was not possible for users to access those layouts, scripts, data, etc.
Open Quickly turns that on it’s head. Many systems which were secure are now exposed.
FileMaker client previously provided Privacy. That was distinctly different from security. It was robust privacy. That privacy no longer exists. And many systems will have relied on that privacy. I’ve worked with many systems, since 1996, and only the simplest of them didn’t have layouts which required privacy.
Malcolm, please provide an actual example of this. Perhaps I’m being thick, but for the life of me I don’t see how Open Quickly changes anything. This is a generic statement and I’d really appreciate a practical example to understand where you are coming from.
School Management system, very tightly locked down with close attention to security and UI behaviour. However, there is a need for custom reports and an adjunct file is provided, with full access to allow clients to create their own reports. Open Quickly, opened from any of the other files is safe. Open quickly, opened from the report file, exposes all scripts and layouts in the other files.
Commercial Gallery solution. The preferences records (which are secured by privileges) are moved into global field table via scripts. The global fields are on a "Private" layout, which is now accessible, allowing users to make detrimental changes.
I've used many other systems which have dev-only layouts that include arrays of buttons designed to do things: scaffold data, tear down modules, run performance tests, etc. Are they all properly secured? Maybe. I hope so.
Finally, developers often do work-in-progress on live systems. Yes, I know that is not recommended but it happens. Privacy is no longer available unless the developer modifies the security settings (and that is probably a worse thing to do than working on a live system).
You can make arguments that both of these systems "should" have done things differently. However, previously it was not possible for the user to obtain a list of all accessible layouts and scripts from the UI. It was not possible for the user to go to those layouts via the UI. Nor was it possible for users to trigger those scripts via the UI. Now it is.
Sorry Malcolm,
have you checked that really? I’ve checked it: One file with full access, another with restricted access for the user logged in. Open Quickly respects the privilege sets and if the checkmark for a script or a layout is set. Without this checkmark you can’t enter the script in the non-full-access file nor can you execute it via open quickly. And it doesn't matter if you're in the one or the other file when you run open quickly.
So taking off the checkmarks helps a lot.
Well, I also had to look twice to understand what was really happening. First, I was misled: There are two icons for scripts: one is an "illustrated script" and the other is a play/run icon.
If the script has a tick, the permission controls whether it can be run or opened. And indicates this with the appropriate icon. I didn't notice this difference the first time.
The standard behaviour for us as developers should be in future: Remove tick marks from layouts and scripts where they are not absolutely necessary before going live with a file.
And take a look at the existing files in this regard.
Here is a scenario - not well thought through but what the hey.
In preview, no ui elements are functional; you have to expose the toolbar and layout selection and that has to include checked layouts to show - and now exposed to OQ
Now I need to re-engineer those files for preview in a second named window so the parent can close it.
Of change menu sets when switching to preview to ….Oh, but how do I do that in WebDirect or FMGo?
Need to noodle on that a bit and see if there is a better path…….
My earlier tests focussed on scripts. And I had mentally transferred the logic to the layouts. After your post, I looked specifically at the layouts:
If you have full access privileges OQ shows every layout! If the user does not have full access privileges, the tick in layout management determines whether OQ shows the layout or not. Even if the user has the permission to modify the layout!
[Added:]
But if the tick is set and the user has no privileges to see the layout, then it will not be displayed by OQ.
It looks like Claris has thought this through - with regards to scripts AND layouts!
A weakness comes from visibility into other open files that may not have invoked that same level of discipline. Running a script in file b when you are in file a could have disastrous results.
I have yet to use the old standby technique of creating a custom menu and removing choices that you don’t want the user to be able to make. Pretty sure that will work.
