The --unsafe flag is needed in order to compile SQLite. I wish we didn't need it, but we do.
Note: you can now also update from inside the application, in the Admin menu under Settings.
The plug-ins in the Saltcorn store are from time to time updated with bug fixes or new features. Upgrading your plug-ins is an all or none operation, there is no functionality to upgrade a single plug-in.
If you are running a single tenant, you update the plug-ins through the store. The drop-down menu near the top left of the store has an Upgrade installed plug-ins option. Running this will upgrade your plug-ins.
If you are running a multitenant server, upgrading the plug-ins is slightly more complicated. Because of a limitation of the plug-in loading mechanism will use, all plug-ins across all tenants will be the same version. To upgrade all plug-ins across all instances, run the following command on the command line:
saltcorn plugins -u
This will take some time as it is collecting all plug-ins installed across all tenants and looking for available updates. When this is finished, you should restart the server before the upgrade takes place.
Changing the database schema
Sometimes, you want to run Saltcorn under PostgreSQL in a different schema than the default public without activating the multi-tenancy functionality. To change the schema, do one of the following:
Set the default_schema key of the JSON object which constitutes the configuration file. If you don't know where this file is, run saltcorn paths - the value printed as the configFilePath is where Saltcorn expects to find the configuration file. In this file, add default_schema: name_of_your_schema inside the curly brackets, with a comma to separate it from the previous keyvalue pair.
Set the SALTCORN_DEFAULT_SCHEMA environment variable to the name of the schema you want to use.
Now you should run the reset-schema command, for instance as follows:
You can restrict the configuration settings the administrator can change in the Settings -> Configuration menu, in order to restrict their choice, or to relieve them from the need to make repetitive changes
Fixed configuration: by setting configuration values in the configuration file or in the environment variables, these configuration options will always be used and will be removed from the settings configuration menu in both the root tenant and in any tenant subdomains. For instance, say we would like to fix the smtp_host configuration value to smtp.example.com. To set this in the configuration file, add a fixed_configuration key, the value of which should be an object with every key/value pair you want to fix. In our example, edit your JSON configuration file to include the last line:
if you use environment variables to control Saltcorn rather than the configuration file, set the environment variable SALTCORN_FIXED_CONFIGURATION to the JSON object with the fixed configuration key/value pairs:
Inherited configuration: if you would like to let the administrator of the root tenant set the variables in the administrative user interface, and you would like the subdomain tenants to follow the configuration values set by the root tenant administrator, you can declare that some configuration values are inherited. In the JSON configuration file, set the inherit_configuration value to an array of strings with the names of the configuration settings that are to be inherited. For example, if you would like the smtp_host, smtp_user, and smtp_password configuration values to be inherited, add the following to yourJSON configuration file