It is necessary to also check & change the FileMaker GUI language!

On Windows

• The setting is in the Preferences GUI
• Registry Path?
• I guess can be changed via Registry setting

On Mac

• Where is this 'setting'?
  • In recent Mac OSes the language can be set in the OS
  • Before that we hacked around in the Resources by deleting de.lproj
• Can it be changed?

It can however be easily read via FileMaker function Get ( ApplicationLanguage ).

Maybe we need the ability to…?

• define a setting (read-function) via FileMaker function
• define a setting (write-function) via FileMaker script

Note: A similar issue exists for checking file & system locale settings!

fmSetupAssistant accidentally creates a superfluous folder one too deep with the name of the setting.

E.g. When you create the Recent Files Max setting…

an extra empty folder is created:

Probably caused by the create path CF.

fmSetupAssistant needs splitting off from fmWorkMate !

In fmWorkMate fmSetupAssistant needs to be changed to an external tool.

All fmSetupAssistant issues can be transfered ☺ - see https://stackoverflow.com/questions/9720718/how-do-i-move-an-issue-on-github-to-another-repo

The layout for saving settings to the profile is suboptimal.

• All references in conditional formatting to the computers current value should be removed
• Conditional formatting should be changed to reflect the save-status of the setting

Until now fmSetupAssistant has been mac-only, however, all/most of the functionality is available for windows.

• Separate settings records for Mac and Windows
• Fields IsMac and IsWin
  • Checkboxes, so title-Records can be shared?
    • or will that make a mess of sorting? (probably yes!)
• Extend the Data Types value list for Windows Data Types
• Extend the Data Types output field with Windows Data Types
• Extend the settings path fields
  1. Either
     • Field "Setting Domain" can be used on windows for the registry path
     • Field "Setting Path" can be used for the property name
  2. Or
     • Field "Setting Domain" can be "windows registry"
     • Field "Setting Path" can be used for the registry path
     • New Field "Setting Name" can be used for the registry setting name
  3. Or
     • Field "Setting Domain" can be "windows registry"
     • Field "Setting Path" can be used for the registry path AND setting name
     • No New Field needed
• The latter seems better, since
  • the fields/semantics matches better (domain = registry, full path = full path)
  • it would leave open the possibility of maybe defining settings in ini-files?
    • However, settings values in ini-files may also be a requirement on Mac? (e.g. setting contents of Assisted Install file?)

Currently the domain field (plist filename on Mac or the registry path on windows) hard codes FileMaker Version specific information into the data.

For example:

• Mac: com.filemaker.client.pro12 ... is not compatible with FM18(17?) FileMaker Pro Advanced app, which uses com.filemaker.client.advanced.pro12 (or something like that)
• Win: HKEY_CURRENT_USER\SOFTWARE\FileMaker\FileMaker Pro\19.0\CalcDialog ... is only compatible with FM19.*

Before we start duplicating hundreds of settings records to target different domains, a flexible solution would be more sensible.

Idea 1: Domain placeholders?

• An empty field, or the placeholder {app} should be expanded to the respective domain for the current FileMaker-app

Idea 2: Change Windows use of fields to only put the domain part in the domain field

Current field use:

Domain: HKEY_CURRENT_USER\SOFTWARE\FileMaker\FileMaker Pro\19.0\CalcDialog
Setting Path: AutoEvaluate

This works easily with the MBS function MBS( "Registry.GetValue" ; Domain; Setting Path )

Suggested field use:

Domain: HKEY_CURRENT_USER\SOFTWARE\FileMaker\FileMaker Pro\19.0\
Setting Path: CalcDialog\AutoEvaluate

The relative part of the path (CalcDialog\) has been moved from the Domain field to the path field.

This would

• make it possible to just leave the Domain field EMPTY to automate the domain path,
• require a bit of logic to move the relative part of the path (CalcDialog\) back to MBS's first parameter.
• Plus it would make the field use more consistent

I've used a GBS custom function that seemingly uses the TroiFile plugin!

That must be removed!

While we are at it, maybe we can create our own function with a non-german name

FM20 has arrived. We need to make sure that fmSetupAssistant will work on it.

Particularly we should use FM20 to check that our {app} placeholder generates the correct (windows registry) path to the root folder.

There are too many safety-net dialogs.
The popover is maybe unnecessary.

Maybe we need to differentiate between

• a new setting
• a tried and tested setting

Once basic support for Windows is achieved (Issue #7), we need to discover where FileMaker stores the various settings (Windows registry paths).

Currently the Prepare Release script deletes all profiles and resets the settings - to a state which is undesirable.

How should the Prepare Release Script be best setup to deliver a safe and sensible set of settings?

Note: Some related problems are soon going to be:

• the missing ability to easily update existing deployments of fmSetupAssistant!
• the problem of sorting the hierarchical list in a way which makes updating / merging of settings easy

So long as a definition error can be detected, it should be rendered harmless / deactivated.

• Avoid failure due to Settings Definition Error - implemented in version 0.27
  • Detect & visual warning of Data Type error
  • Detect & visual warning of Settings Definition error
  • Deactivate setting automatically, if a settings definition error is detected
  • Settings cannot be re-activated whilst they have a settings definition error
• Ensure that definitions cannot be written whilst deactivated

On the mac preference entries are automatically created if they do not yet exist.

On Windows you seem to need to create the registry entry before you can write it.

Currently Watch List entries cannot be set on windows unless they already exist.

Config lists are, unsurprisingly, a list of configurations, which can be applied one after the other. That means where configurations contain the same setting, the last configuration in the list wins since it overrides the previous Setting.

Examples:

• GBS Advanter user workplace
  1. GBS Basic user workplace
  2. GBS advanter User start file
• MrWatson's workplace
  1. GBS Developer workplace
  2. Start file fmLaunchPad
  3. …

Indeed , a Natural extension of this would be for config lists to be a list of configurations OR config lists.

Where one configuration list contains another configuration list and the contained configuration list will be applied in its normal way sequentially as one would expect.

This of course will require, checking to avoid infinite loops.

Preference FM > Preferences > Memory > File Cache Frequency requires a value list for its 5 possible values:

Save Cache…

0 - during idle time
10 - every 10 minutes
15 - every 15 minutes
30 - every 30 minutes
60 - every hour

This must be a two column value list, which hides the internal value and only shows the text.

The Display As field would need to be extended to include value list.

Hm…How to best implement (dynamic) 2-column Value Lists?

CFs to centralise the logic of handling, reading and writing settings.

• _SettingDomain // Calculate the full domain[path] for the given domain[path] and OS (by applying defaults and expansions)
• _SettingGetDataType // Get a setting's data type
• _SettingExist // Check if a setting exists
• _SettingGetRawValue // Read a setting's value
• _SettingSetRawValue // Write a setting's value

The purpose of these functions is to centralise the logic.

This is actually a Milestone rather than a separate issue

Currently the API provides the following script to apply a config to the current computer

fmSA_ApplyConfig

…but

• How should the automatic config application behave & look?
• What options are needed other than the config name?
• What are sensible defaults for these options?

Automatic Process

A sensible automatic process would be a silent one:

• a completely silent/transparent automatic application of a config
• which passes all information back to the calling app
• giving the calling app the entire control over the process

This is simple and makes the options clear to understand, since they are all positive - see below.

Process…

1. Optionally show splash
2. Optionally create extra (card) window (otherwise hide window)
3. Apply config
   • optionally show progress (optionally slowly)
4. Optionally
   • Show summary of results
   • Optionally pause
   • Optionally show button to restart (quit) FileMaker
5. Hide window
6. Return results

JSON Parameters

The script accepts JSON parameters:

• @param (string) config_id - the human readable id of the config

• @param (string) config_uuid - the computer readable uuid of the config

• @param (string) config_name - the name of the config, or a keyword from the config

• @param (boolean) show_gui - show a gui // default is don't show

• @param (number) show_progress_seconds - adds a pause between settings // default is no pause

• @param (boolean) show_results - show results: // default is don't show

• @param (number) show_results_seconds - seconds to show results // default is infinite pause

• @param (boolean) show_restart_button - the restart button performs a quit by default // default no button

• @param (boolean) show_splash - show splash screen // default is don't show

[
It may also be sensible to extend the parameters to be able to accept a ¶-separated list of config identifiers, so that several configs can be applied one after the other.

For example "StdUser001¶Open fmLaunchPad at startup" would apply config StdDeveloper001 (basic user workplace) followed by the config to set FileMaker's startup file to fmLaunchPad.

(or maybe NOT if this complicates the return parameter and error handling too much!)
]

Returns JSON

The script result contains up to 4 JSON parameters:

• @returns (boolean) aok - true = OK, false = FAIL = error occurred / config could not be completely successfully applied
• @returns (object) error - optional error object - see below
• @returns (object) return - optional return parameters - see below
• @returns (object) xtras - optional extra info, for example, for debugging

The return parameters (return.*):

• @returns (number) count_settings_changed - the number of settings that were actually changed
• @returns (number) count_settings_skipped - the number of settings that were skipped
• @returns (number) count_settings_tested - the total number of settings that were tested/applied
• @returns (number) count_settings_total - the total number of settings in the config (total = tested + skipped, tested = changed + unchanged)
• @returns (boolean) restart_required - whether a restart is required or not
• @returns (boolean) restart_required_for_activation - restart required to activate some settings (for example: use advanced tools)
• @returns (boolean) restart_required_for_gui - restart required to show some settings correctly (for example: use advanced tools)

Details:

• @returns (string) settings_changed - a list of settings that were changed
• @returns (string) settings_requiring_restart_for_activation - a list of settings that were automatically changed but will first be activate after a restart of FileMaker
• @returns (string) settings_requiring_restart_for_gui - a list of settings that were automatically changed but will first be shown correctly after a restart of FileMaker

The error object has 3 main attributes (actor/code/message) and two optional (error.*):

• @returns (string) actor - the name of the component which encountered the error
• @returns (string) code - the error number or CODE_STRING
• @returns (string) message - the (human readable) error message
• @returns (string|object|array) more_details - optional more details about the error (context, etc.)
• @returns (object) next - further (=earlier/deeper/actually previous) errors, which may contain more specific/technical details and can be useful for debugging.

Possible values of error actor - code / message:

• fmSetupAssistant

  • PARAMETER_MISSING / "Parameter {0} is missing."
  • CONFIG_NOT_FOUND / "Config {0} not found."
  • SYSTEM_ERROR / "…"

• MBS Plugin

  • MBS_ERROR / "[MBS] «MBS error message»"

A function to duplicate an entry would be useful, which

• sets the sort value correctly
• adds " Copy" to the path name

I'm somehow not happy with the UX here, but am not sure of what is needed, so some notes/feelings/ideas:

The current implementation treats watch list settings identically to other settings. This has some problems

• Data Viewer > Watch List entries are referenced by number
  • The order of the entries is not really relevant
• You maybe don't want to do Watch List settings at the same time as other settings?
  • Maybe they should simply be in a separate Profile, and applying multiple Profiles needs to be implemented?

It might be good to be able to merge Watch List entries, rather than blankly overwriting them?

Data Viewer > Watch List entries are on a different kind of level than the other settings.

Where the internal value of a setting is different to the GUI value, and conversion functions are used … is there a bug when writing?

The field _Setting::_kCurr_Pref_Value_GUI_FIXME seems to need fixing

Script Fix BTN has the comment

# FIXME - THIS SHOULD NOT set the Raw value directly!

Use Cases

• check the state of a computer against a desired configuration (manually)
• apply a configuration (manually)
• document the state of a computer
  • optional detail
    • all settings in the configuration
    • only active settings in the configuration
    • only incorrect settings in the configuration
  • documentation type
    • instant visual report
    • Report as PDF-File / email
    • Report as JSON-File

Call type

• Manual use
• Call by script from master DB
• API-Call from remote computer

fmSetupAssistant has been used as an offline tool until now.

For use at a specific company, it may make sense to host the file - next to the hosting app (for example, advanter), so that the hosting app can call fmSetupAssistant as part of it's initialisation of a new workplace.

Functionality will need to be added to make global field changes permanent.

The current security is too thin. The user account currently has full access, so Layouts can be edited, etc.

First steps:

• Change user account to be a data entry only account priv.
• Rename user to User.
• Change PW to user.
• Ensure that fmSetupAssistant starts in the user account.
• Add a Re-Login button on the start page to swap between User and Admin

For now that should suffice.

It may be useful to log per Setting

• how many successful setting write operations
• how many failed setting write operations
• how many successful setting read operations
• how many failed setting read operations

occur.

Adding these statistics

• would highlight incorrectly set up settings
• would help users to trust that settings work

Open issue

I can easily log successful write operations, however,
since a write operation with an incorrect data type is first apparent when FileMaker is restarted it is not possible to detect a failed write operation automatically. Indeed it will be logged as a successful write operation, until the user corrects this him/herself.

Currently the Important flag is only in the settings table. However, since a setting might be unimportant in one profile but important in another profile the Important flag needs to also be stored and settable in profiles.

Need to

1. Add field Important to the _ProfileSettings table
2. Add the field to layout(s) somewhere
3. Add the field to the profile load & save scripts
4. Extend the logic to indicate a setting has changed/must be saved when the important field in the profile differs from the important field in the settings

Writing preferences back needs to be extended to write the correct data type.

Requires:

• read data type from source preference
• write preference with correct data type
• conversion of display values to preference values
  • specifically convert integer-as-checkbox to correct integer ("" -> Integer 0)
• tests

A Boolean preference, gets compared to its bit value twice. It should only be compared once.

For normal boolean values this is (unnecessary, but) not a problem, but by inverted boolean values (where the preference value is the inverted GUI-value) the not-inversion gets applied twice and thus is annulled.

Fix: Apply inversion only once.

Currently target values are static.

It may be useful to be able to define a calculated value, for example, maybe the FileMaker username could be set dynamically:

«Path to FileMaker UserName» = MBS( "System.GetUsername" /* or whatever */ ) & " " & Get ( SystemIPAddress )

Checkboxes should handle conversion of 0=>""=>0 automatically as necessary.

Clicking Display as Checkbox should be enough.

Maybe it's not working on windows due to windows data type not yet being fully implemented.

Checkbox assumes {0,1}

Boolean as checkbox {0,1}
Number as checkbox {0,1}
Text as checkbox {"",1}

There are too many checkboxes in FileMaker!

The On/Off checkbox (and the Edit and write privs) would be better implemented as a toggle switch.

This would look great and reduce the number of checkboxes, helping users to distinguish better between a setting's on/off option and the setting's values.

Did I not see that an error came, when a non-admin windows user used fmSetupAssistant?

Which configuration should be selected by default, when you go to the config list?

Would it make sense, when you first open fmSetupAssistant on a machine which has already been configured, if the last applied configuration was selected?

And in that case, should a config first be marked as current, when you view or apply it?

Like that, when you first look at the config list, it would be an instant indicator of the current config of the machine.

Hm…

>thinking<

fmSetupAssistant has been developed by me for me - and is thus understood only by …er… me. 😄

The GUI needs better UX, better in-app documentation to make it usable by 'non-me's. 😆

Particularly:

• Placeholders in the setting calculation fields need to be explained:
  • Use placeholder '|' for string value and '#' for number value
• UX of Saving Settings to Config is strange
  • [+] button for new configuration is more like a 'Save as' function
  • [++] duplicate/compare button is also strange
  • Adding/removing Settings to a Config via Searching is also strange

…and probably more // need to gather details here

When is sitting his read-only setting the [(i)] button is fine, but in a writable setting in no-write mode, the [←] fix button with an arrow pointing to the left is confusing, because the user expects to it to fix the setting, but it only opens the GUI dialogue.

It would make more sense, if I'm this situation the GUI button was shown in its place - maybe with a tool tip to hint that writing is currently not allowed.

It has become clear that we shall need a further level of grouping settings.

The currently implemented profiles group settings into collections targeting a particular context, for example:

• FileMaker Developer settings
• Enduser workplace settings
• Keyboard-Developer settings
• Mouse-Developer settings
• Start File=fmLaunchPad
• Advanter Debugger Watch Settings
• FileMaker Server settings

When setting up a machine several of these profiles will need to be selected and applied.

For example:

a GBS customer's FileMaker Server, which is used both as a server and a support client, may need

• FileMaker Server settings
• Enduser workplace settings
• FileMaker Developer settings
• Mouse-Developer settings
• Keyboard-Developer settings
• Advanter Debugger Watch Settings

When targeting a GBS customer's FileMaker Server, it will be necessary

• to select these profiles for the given target
• to apply all the settings of all the profiles
• to deal with potential conflicts between the selected profiles

Handling Conflicts between multiple Profiles

A (theoretical) example of a potential conflict could be

• FM > Preferences > Layout > Always Lock Layout Tools Setting
  • Some users want tools always locked
  • Some users (me) want them always unlocked
• Operating System Show all filename extensions Setting
  • Generally, end users want this OFF
  • Developers want it ON

When there are conflicting settings in the selected profiles, how should this be handled / dealt with?

Targets

The term Target seems to cover the idea here.

Maybe a new table is needed to define the different Targets

• Advanter FMS
• Advanter AAS
• Advanter Enduser Workplace
• MrWatson's Workplace

Note:

• The Target-Profile-Setting structure does seem to model well the idea that a machine has multiple dimensions of settings, each dimension being modelled in a profile.
• It is, of course, possible to do without a Targets table and to define everything in the Profiles table.
• This would, however, lead to a lot of redundancy, where identical settings are repeated in many profiles, and it may become hard to manage:
  • Should a settings value need to be adjusted (change in policy), it would have to be changed in multiple profiles.

This is a bit of a general, all-in-one 'I have some concerns' issue, which is in construction / a thought gathering process.

UNDER CONSTRUCTION

Safety

• Workstation's safety - avoid breaking prefs files
• User's safety - need protecting against own mistakes
• My Safety - liability

Protection

• Protection against errors
• Protection against future changes in the environment

Privileges

• Who can do what?

Security

• Who can be trusted with what?
• Open accounts?
• Security+Safety via an approval system?
• Security+Safety+Recovery via a logging system?

Issue: writing errors

• Avoid writing errors:
  • Priv: Allow Settings with logged errors to be written
  • Priv: Allow (new) Settings without logged success to be written
  • Priv: Suppress warnings when writing (new) settings
  • Priv: Allow MBS in Demo Mode
• Approval: Distinguish between Approved Settings

Issue: Future Safety

• What is to stop things breaking when something new comes along?
• A new version of FileMaker could change the way preferences work
• An updated OS might change OS-Settings

Who can do what?

• We currently have two privilege sets in fmSetupAssistant, Admin (=DEV) and User

• Would it be better to adopt the three privilege levels used by GBS Developer, Administrator and User?

• Privilege levels only make Do we need to

• …

Idea: Approval System

Can we avoid such breakages by introducing an approval system

• Approval required for unknown / new FileMaker version
• Approval required for unknown / new OS version
• Approval required for unknown / new settings

Idea: History Log

• Do we need a log of changes, so that when something goes wrong, we can identify what lead up to the situation?

Hm...It seems that we may need to store more setting-attributes with a configuration.

A setting in one configuration may be a testable setting, in another only a read only setting.

• The Setting DoTest field needs to be added to the save provcess.
• Maybe also the Writable field?

Illustrative example: FileMaker language:

• In the basic user's workplace maybe this setting should be shown as an informational, read-only setting, (since some users are German, some are swiss, portuguese, etc.)

whereas

• in the developers configuration setting, however, it may be necessary to check that this setting is set to english.

Problems

• Adding further fields to the config-save may make the save status message slow.

Considerations for a faster calculation of save-status

Maybe we can

• bundle several fields together in a JSON field for saving
• or only compare an MD5 // probably the best!

Maybe a good security measure would be to make a backup of the target preference file before performing a write, so that should the preference file get trashed and FileMaker not be openable, the old preference file could be restored.

Would this need some kind of non-FileMaker script (AppleScript / Batch-Script)

• either to reinstate the settings file directly
• or to delete the broken settings file
  • and fmSetupAssistant could reinstate the backup file itself?

Some settings first show a changed value after a restart.
Some settings require a restart before a change is activated.

Two fields already exist to log this.

We need 3 session fields to log that we need to restart:

• A field to say FileMaker needs to be restarted
• A field to list the properties that will be activated
• A list of the properties that will be refreshed.

and

• a button to click, when a restart is necessary.

How can we get a file to restart - in the same FM?

fmSetupAssistant needs a way of limiting properties to specific versions of FileMaker.

This is the same functionality / requirement that fmSyntaxColorizer already solves by way of an FM-Version field containing "fm18…", "FM15…FM17.1" or similar.

This works well for fmSyntaxColorizer and the same functionality should be built into fmSetupAssistant.

A simple method to correct the sort would be good.

If the MBS plugin is running in Demo mode and stops working whilst using fmSetupAssistant there is a situation, I believe, where this could lead to

• a default properties file (on Mac),
• FileMaker not being able to re-open
• users / admins having to…
  • understand the problem,
  • find & delete the properties file,
  • or, after all, manually setup the computer
• support
• Ärger

What is the best way to protect against this?

TL;DR: Not allow write operations, when plugins not licensed.

Part 0 - Avoid failure due to Settings Definition Error

= already implemented in version 0.27

• See issue #41

An untimely plugin failure (whilst defining a setting) can cause a settings definition error (due to an incorrect data-type="[MBS]…"). To avoid problems in a later session, such a faulty setting is automatically detected and deactivated in this situation.

Part 1 - Protect against Damage by Plugin

= Disallow writing settings, when Plugins are not OK

• Distinguish between Plugin State Error and Plugin State Warning

  • Plugin State Error when plugins missing or disabled
  • Plugin State Warning when MBS Demo mode or MBS license nearly expired?

• If there is a Plugin State Error (plugins missing, disabled, expired)

  • De-activate navigation to config and settings

• If there is a Plugin State Warning (MBS Demo mode (or license nearly expired?))

  • Show a warning in the footer - or around the Home logo (to lead you back home)
  • Deactivate write permission

• Actively check changed plugin state, if plugin has changed to a dangerous state, abort action - and return to home page?

  • before performing write operations
  • before navigating to config
  • before navigating to settings

Part 2 - Protect Liability

= Allow writing settings in MBS Demo mode only when user has accepted liability.

• Define a Liability Warning = Plugin warning and no user-consent
• If there is a Plugin Error -> as above
• If there is no Liability Warning, everything is allowed
• If there is a Liability Warning, request user-consent before proceeding, otherwise abort

[Further implementation details ToDo]

Part 3 - Protect against damaged property files

The last line of protection: In the unlikely situation of property files being damaged, it should be possible to revert the damage.

• Backup property file(s) before changing them
• Provide some method to restore the property file
• Provide documentation of this process

MrWatson's Standard Menüs, including

• App menu
  • Home (⌘+1)
  • Configs (⌘+2)
  • Settings (⌘+3)
  • … (⌘+4)
  • … (⌘+5)
  • … (⌘+6)
  • … (⌘+7)
  • … (⌘+8)
  • App Settings (⌘+9)
• Records
  • Record deletion protection
  • Custom record duplication
    • Configs
    • Settings
• Windows (⌘+0)
  • Max/Min Window
• Navigation

A method is needed to make it possible to automate running / setting up particular configs.

• System automation technique?
• automation technique within file itself to say install settings 'X'

Assisted Setup ini file?

fmSetupAssistant uses the MBS Plugin.

• Does the tool need to register the MBS plugin?
• Or should plugin registration be
  • outsourced to an external database
  • outsourced to the target database (advanter)

Houston: We have a chicken & egg situation here!

1. fmSetupAssistant is needed to setup the OS- & FileMaker environment for the host DB
2. the host DB is needed to register the MBS plugin
3. fmSetupAssistant needs the MBS Plugin
4. Goto 1

What information should be stored on the machine in order to implement an "initial setup" function?

A minimal information would be just a Boolean, but a configuration history of events/applied configurations may be useful for correction logic at a later date.

Something like

• «fmSetupAssistant Domain»
  • .state
    • .is_config_applied
  • .history
    • .table
      • .columns[]
        • …
      • .rows[]

We need more than one settings list.

This could be achieved by duplicating the file for each constellation of settings one needs.

However, a better solution may be to support profiles.

Each profile can include:

• a name
• a subset of properties
• specific values