update default app/config.yml (#1692)

app/views/pages/developer-guide/json-documents/mapping.liquid

@@ -11,7 +11,7 @@ Mapping is the process of defining how a document, and the fields it contains, a
 
 Each document is a collection of fields, which each have their own data type. When mapping your data, you create a mapping definition, which contains a list of fields that are pertinent to the document. A mapping definition also includes metadata fields, like the _source field, which customize how a document’s associated metadata is handled.
 
-In platformOS, you can define document type via `search_indxes` in `app/config.yml` file. Example mapping definition:
+In platformOS, you can define document type via `search_indxes` in [app/config.yml](/developer-guide/platformos-workflow/codebase/config.yml) file. Example mapping definition:
 
 ```yaml
 search_indexes:

app/views/pages/developer-guide/json-documents/persisting-json-documents.liquid

@@ -7,7 +7,7 @@ metadata:
 
 ## Step 1: Requirements
 
-I want to store my "docs" in platformOS, which is defined by the following mapping. Creating a mapping itself is not required, however it allows you to optimize results of your queries. For the time being, you can define mappings of your documents in `app/config.yml` file:
+I want to store my "docs" in platformOS, which is defined by the following mapping. Creating a mapping itself is not required, however it allows you to optimize results of your queries. For the time being, you can define mappings of your documents in [app/config.yml](/developer-guide/platformos-workflow/codebase/config.yml) file:
 
 ```yaml
 search_indexes:

app/views/pages/developer-guide/platformos-workflow/codebase/config.liquid

@@ -9,17 +9,17 @@ metadata:
 
 | flag                                                           | default value   | Explanation |
 |----------------------------------------------------------------|-----------------|-------------|
-|do_not_add_return_to_to_authorization_policies                  |false|By default, if the authorization policy fails and is set up to redirect, it automatically appends the return_to parameter. By setting the flag to true, the return_to parameter will not be appended|
-|escape_output_instead_of_sanitize                               |false|By default, any variable is sanitized before the output and treated as html and corrected, which is unideal as it can change the expected output. By setting this flag to true, the output will be escaped, not sanitized. We highly recommend setting this flag to true. |
-|graphql_argument_type_mismatch_mode                             |warning|Defines behavior when the argument type in the GraphQL query is wrong. Possible values:<br/> `warning` - display warning message in log<br/> `error` - raise error, do not allow to deploy query<br/> `ignore` - silently ignore error |
-|liquid_check_mode                                               |warning|When you deploy/sync liquid files we run static analysis on the files. By setting this flag to `error` we gonna throw error if file contains unknown filter. <br/>Possible values:<br/> `warning` - display warning message in log<br/> `error` - raise error, do not allow to deploy liquid file|
-|liquid_raise_mode                                               |false|By default, Liquid runtime errors are displayed in line and the whole code is executed. By setting this flag, whenever there's any Liquid error - like parsing json fails, or GraphQL query receives invalid arguments, etc, a 500 page is raised instead and the rest of the code is not executed. This is generally the desired and expected behavior and we recommend setting this flag to true.|
-|require_table_for_record_delete_mutation                        |false|The argument `table` for the `record_delete` mutation is optional by default, which can lead to security issues if the type of the record is not explicitly checked before executing the mutation. By setting the flag to true, you effectively make the `table` attribute required to avoid such vulnerability.|
-|safe_translate                                                  |false|By default, the `translate` filter (`t` is an alias for it) marks the output as html_safe. This can lead to XSS vulnerability, if you provide user input as a variable, which can contain JavaScript. In such scenario, you should explicitly use another filter, `translate_escape` (or `t_escape`). By setting this flag to true, the system will automatically use the equivalent of `t_escape` if you provide any variable to the translation key, making your application safer by default. We highly recommend setting this flag to `true`.|
-|skip_elasticsearch                                              |false|If you do not use the `keyword` argument in `records`/`users` queries or `customizations`/`people` queries, you can increase performance by avoiding indexing data in the ELasticSearch by setting this flag to true.|
-|slug_exact_match                                                |false|By default, a page with slug `abc` will match not only  `example.com/abc`, but also URLs like `example.com/abc/1`, `example.com/abc/1/x` and to control this behavior, you should use max_deep_level. By setting this flag to true, only `example.com/abc` will be matched. Additionally, you will be able to use named parameters in the URLss, like /abc/:id. We highly recommend setting this flag to true.|
-|websockets_require_csrf_token                                   |false|By default websocket connection does not check csrf token. By setting this flag to `true` connections to websocket require csrf token passed as on of the parameters.
-|maintenance                                   |null|Allows to setup mandatory password protection, useful when the site should be restricted only to users who know the password.
+|do_not_add_return_to_to_authorization_policies                  |false|By default, if the authorization policy fails and is set up to redirect, it automatically appends the return_to parameter. By setting the flag to `true`, the return_to parameter will not be appended|
+|escape_output_instead_of_sanitize                               |true|If disabled, any variable will be sanitized before the output and treated as html and corrected, which is unideal as it can change the expected output. By keeping this flag as `true`, the output will be escaped, not sanitized. We highly recommend setting this flag to true. |
+|graphql_argument_type_mismatch_mode                             |error|Defines behavior when the argument type in the GraphQL query is wrong. Possible values:<br/> `warning` - display warning message in log<br/> `error` - raise error, do not allow to deploy query<br/> `ignore` - silently ignore error |
+|liquid_check_mode                                               |error|When you deploy/sync liquid files we run static analysis on the files. By keeping this flag as `error` we gonna throw error if file contains unknown filter. <br/>Possible values:<br/> `warning` - display warning message in log<br/> `error` - raise error, do not allow to deploy liquid file|
+|liquid_raise_mode                                               |true|If diabled, liquid runtime errors will be displayed inline and the code will continue to execute despite error. By keeping this flag as `true`, whenever there's any Liquid error - like parsing JSON files, providing invalid arguments to GraphQL query, etc., the 500 page will be raised instead and the execution will stop. This is generally the desired and expected behavior and we recommend keeping this flag as `true`.|
+|require_table_for_record_delete_mutation                        |true|The argument `table` for the `record_delete` mutation is optional by default, which can lead to security issues if the type of the record is not explicitly checked before executing the mutation. By setting the flag to true, you effectively make the `table` attribute required to avoid such vulnerability.|
+|safe_translate                                                  |true|If disabled, the `translate` filter (`t` is an alias for it) will mark the output as html_safe. This can lead to XSS vulnerability, if you provide user input as a variable, as it could contain malicious JavaScript. In such scenario, you should explicitly use another filter, `translate_escape` (or `t_escape`). However, by keeping this flag as `true`, the system will automatically use the equivalent of `t_escape` if you provide any variable to the translation key, making your application safer by default. We highly recommend keeping this flag to `true`.|
+|skip_elasticsearch                                              |false|If you do not use the `keyword` argument in `records`/`users` queries or `customizations`/`people` queries, you can increase performance by avoiding indexing data in the ELasticSearch by setting this flag to `true`.|
+|slug_exact_match                                                |true|If disabled, a page with slug `abc` will match not only  `example.com/abc`, but also URLs like `example.com/abc/1`, `example.com/abc/1/x` and to control this behavior, you would need to set [max_deep_level Page property](/developer-guide/pages/pages#available-properties). By keeping this flag as true, only `example.com/abc` will be matched. Additionally, you will be able to use named parameters in the URLss, like /abc/:id. We highly recommend setting this flag to true.|
+|websockets_require_csrf_token                                   |true|If disabled, the websocket connection will not check the CSRF token. By keeping this flag as `true`, connections to websocket will require CSRF token to be included in the parameters, increasing the security of your application.
+|maintenance                                   |{ enabled: false, password_constant: 'MAINTENANCE_PASSWORD', partial: 'maintenance' }|Allows to setup mandatory password protection, useful when the site should be restricted only to users who know the password.
 |modules_that_allow_delete_on_deploy                             |[]|Allows to list module names, for which if a file will be missing on deploy, it will be removed. The default behaviour of module is to not delete any files, because it is possible that developer would know download all of the source code and would like to just deploy an overwrite for a few chosen files. If the module is listed and sync is enabled, then users will be also able to remove the files from the instance by removing them in their filesystem.
 
 
@@ -28,7 +28,6 @@ Example `app/config.yml` file with recommended values:
 
 ```yml
 ---
-do_not_add_return_to_to_authorization_policies: true
 escape_output_instead_of_sanitize: true
 graphql_argument_type_mismatch_mode: error
 liquid_check_mode: error

app/views/pages/release-notes/2020/NOVEMBER/30.liquid

@@ -12,7 +12,7 @@ slug: release-notes/30-NOVEMBER-2020
 
 <h4 class="release-note release-note__new">NEW</h4>
 
-* possibility to add `app/config.yml` to configure feature flags per Instance for backwards compatiblity. Currently, the only supported config is `escape_output_instead_of_sanitize` which takes no effect, as the new feature will be deployed separately.
+* possibility to add [app/config.yml](/developer-guide/platformos-workflow/codebase/config.yml) to configure feature flags per Instance for backwards compatiblity. Currently, the only supported config is `escape_output_instead_of_sanitize` which takes no effect, as the new feature will be deployed separately.
 * new [digest](/api-reference/liquid/platformos-filters#digest) filter
 
 <h4 class="release-note release-note__improved">IMPROVED</h4>

app/views/pages/release-notes/2021/MARCH/16.liquid

@@ -13,5 +13,5 @@ slug: release-notes/16-MARCH-2021
 <h4 class="release-note release-note__new">NEW</h4>
 
 * When implementing the websockets, now you are able to create `channels/<channel_name>/subscribed.liquid` which works the same as an Authorization Policy: if it evaluates to true, the user will have access to the channel, otherwise they won’t. This will prevent listening to other people's DMs, etc. If the `subscribed.liquid` file is not created, then there is no authorization and we assume this is a public channel. 
-* Added new flag `do_not_add_return_to_to_authorization_policies` which can be set in `app/config.yml` 
+* Added new flag `do_not_add_return_to_to_authorization_policies` which can be set in [app/config.yml](/developer-guide/platformos-workflow/codebase/config.yml) 
 * Added new filters `amount_to_fractional` and `fractional_to_amount`

app/views/pages/use-cases/using-websockets.liquid

@@ -190,7 +190,7 @@ To avoid broadcasting (for example if the user is not authorized to add a messag
 
 ### Employing Cross-Site Request Forgery token validation
 
-If you've enabled `websockets_require_csrf_token` in your `app/config.yml`, the CSRF token must be passed as below:
+If you've enabled `websockets_require_csrf_token` (default) in your [app/config.yml](/developer-guide/platformos-workflow/codebase/config), the CSRF token must be passed as below:
 
 ```javascript
 const token = csrfToken();