@saltcorn/server 1.0.0-beta.17 → 1.0.0-beta.19

package/help/Aggregation where formula.tmd

@@ -0,0 +1,11 @@
+The where formula allows you to restrict the rows included in the aggregations. 
+
+The formula should take the form of a JavaScript boolean expression such as
+`a === b` or `x>y && w==1` when is based on the row values in the rows in the target table for 
+inclusion in the aggregation. For instance, if you are displaying aggregations about 
+a row from a Projects table, and a Task table has a key to projects field and a Boolean
+field called `completed`, you may want to show the number of not-completed tasks for the Project.
+In this case use the where expression `completed == false`.
+
+You cannot here use view state or values from the row about which you are displaying aggregations. However, 
+if a user is logged in, the `user` variable can be used to access user fields, such as `user.id`.

package/help/Calculated fields.tmd

@@ -0,0 +1,28 @@
+A calculated field is a column that holds values that are not entered 
+or changed directly but are instead calculated automatically from other 
+values in that row of from rows in other tables related by a key field. 
+
+There are two types of calculated field values:
+
+*Not stored*: calculated fields that are not stored in the database are 
+recalculated every time the row is accessed. They are defined by a 
+JavaScript expression where the values of the other fields are in scope.
+They are suitable for quick calculations that depend only on other values 
+in the same row. Because they are recalculated they are guaranteed to be 
+up to date. Non-stored fields cannot access data in related rows by join 
+fields or aggregations and cannot use asynchronous functions provided by
+modules. They can use synchronous functions.
+
+*Stored*: the values of stored fields are stored in the database table. 
+They are more flexible in the way they can be defined. Stored fields can 
+be defined either by a JavaScript expression or by an aggregation. When 
+defined by a JavaScript expression, join fields can be accessed by the 
+dot notation. Stored fields may also use both synchronous and asynchronous f
+unctions provided by modules. Asynchronous functions can in principle do 
+input/output including calling APIs. This expression will be evaluated 
+every time the row changes.
+
+Stored fields that are defined by an aggregation are automatically updated 
+when one of the child rows is updated. Stored fields that are based on 
+JavaScript expressions involving join felds are not automatically updated. 
+You need to run the recalculate stored fields action to update them 

package/help/Protected fields.tmd

@@ -0,0 +1,4 @@
+Mmark a field as protected in order to set a minimum role required
+to write to this field. This will be checked in addition to the role
+required to write to the whole table; it will also stop changing the 
+field value even if the user is the owner of the row.

package/help/Snapshots.tmd

@@ -0,0 +1,19 @@
+A snapshot is a saved format of your application that includes all of 
+your application structure (table and fields definitions, views pages 
+and configuration settings) but excludes all of your data, that is, 
+table rows and files. A snapshot is the same format as a pack - a snapshot 
+is in fact merely a full pack of the application. (To create a partial 
+pack of the application, use tags or the pack export in the module store). 
+
+Snapshots have several possible uses:
+
+* If you have two different servers one for production and one for development 
+  then you can make changes to the development server and use a snapshot to 
+  move those changes to the production instance 
+
+* By enabling periodic snapshots Saltcorn allows you to restore versions of 
+  views, pages and triggers after you have made changes. This allows you to 
+  undo mistakes that you have made in building. 
+
+* If your application contains a large amount of data that can quickly be 
+  regenerated you may want to use snapshots instead of backups to save your application.

package/help/Table history.tmd

@@ -0,0 +1,42 @@
+When version history on a database table is enabled in Saltcorn,
+changes to row values are recorded in a secondary, hidden table. 
+This allows you to restore previous versions of individual rows 
+and undelete deleted rows. 
+
+The downside to enabling version history on tables is that this 
+can lead to a lot of data being retained which may mean your 
+database disk requirements will grow. In addition it will impact 
+performance when making changes to rows. There should be no 
+performance impact on reading data from the database.
+
+Note that when the history is first enabled the existing rows in 
+the table are not copied into the history table in their present 
+state. Only when a change is made to a row (or a row is created) 
+is the new row copied into the history table. 
+
+Enabling version history gives the administrator access to the 
+version history in the administrator's data edit facility (Edit 
+button on the table page). Each row will show the number of versions 
+recorded and by clicking this you will see the list of versions. 
+Each version shows the value for each field, the user who made the 
+change, the time at which the change was made and an option to 
+restore. This is the only facility for interacting with the version
+history in core Saltcorn.
+
+The history-control module provides additional facilities for 
+interacting with the history. The history-control module provides:
+
+* Actions to undo and redo row changes that will move the current 
+  row backwards and forwards in the table history
+
+* A history field difference view pattern that allows users to 
+  compare different versions of a field value
+
+* A "History for database table" table provider that can be used to create a "virtual"
+  table based on the history of an existing table. This table will have 
+  all the fields of the original table and fields for the user making 
+  the change and the time of the change being made 
+
+* A restore_from_history action that can be used on a view of the table
+  history (on the provided table) to restore or undelete any version of 
+  a specific row

package/load_plugins.js

@@ -55,7 +55,15 @@ const getEngineInfos = async (plugin, forceFetch) => {
  * @param plugin plugin to load
  */
 const ensurePluginSupport = async (plugin, forceFetch) => {
-  const versions = await getEngineInfos(plugin, forceFetch);
+  let versions = await getEngineInfos(plugin, forceFetch);
+  if (
+    plugin.version &&
+    plugin.version !== "latest" &&
+    !versions[plugin.version] &&
+    !forceFetch
+  ) {
+    versions = await getEngineInfos(plugin, true);
+  }
   const supported = supportedVersion(
     plugin.version || "latest",
     versions,

package/locales/en.json

@@ -1473,5 +1473,7 @@
 	"Select tag": "Select tag",
 	"Invalid build directory path": "Invalid build directory path",
 	"Invalid build directory name": "Invalid build directory name",
-	"clean node_modules": "clean node_modules"
-}
+	"clean node_modules": "clean node_modules",
+	"After delete": "After delete",
+	"Search only on exact match, not substring match. Useful for large tables": "Search only on exact match, not substring match. Useful for large tables"
+}