mrwatson-de
commented
1 year ago Solution ideas:
- Move all setting logic to the ConfigSettings table, rather than importing it to the settings table
- like that users using the same config would share the same config records, but since they are all of the same config, there should be no problem, so long as all fields are either non-stored calculations or global (shouldn't there?)
- This could lead to having to maintain the same logic based on two different tables (_config_settings and _settings)
- Create temp. session records for each user?
fmSetupAssistant was originally designed to be a tool for the desktop, for a single user to set up their FileMaker workstation.
Originally it was just a list of settings. The user selects the settings they want, can press a button and hey presto, fmSetupAssistant checks &/ sets up the workstation as desired.
fmSetupAssistant was then extended to support multiple configs and to run on the server, for ease of integration with existing software - initially with advanterĀ® from GBS GmbH.
When a user's configuration should be applied to the workstation, the configs settings are loaded into the settings table and applied to the machine.
However, if a second user, maybe a user with a DIFFERENT configuration, also starts fmSetupAssistant a split second later, then their configuration is also loaded into the settings table and applied.
Problem: Because the settings table is used for both users, the first user's settings may be overwritten by the next user's settings! š²
In the case of automated configurations which occur during (first) login (to a new system) I think the time window where this could happen is probably very smallā¦nevertheless it could occur.