Merge pull request #144 from ds-wizard/release/4.6.0

Release 4.6.0

docs/about/introduction/knowledge-model.rst

@@ -21,10 +21,10 @@ Knowledge model consists of several entities connected together. You can see how
    Knowledge model schema
 
 
-Knowlege Model
---------------
+Knowledge Model
+---------------
 
-At the top level, the knowledge model contains :ref:`chapters<chapter>`, and entities refered to elsewhere from the knowledge model: :ref:`metrics<metric>`, :ref:`phases<phase>`, :ref:`question tags<question-tag>`, and :ref:`integrations<integration>`.
+At the top level, the knowledge model contains :ref:`chapters<chapter>`, and entities referred to elsewhere from the knowledge model: :ref:`metrics<metric>`, :ref:`phases<phase>`, :ref:`question tags<question-tag>`, and :ref:`integrations<integration>`.
 
 
 .. _chapter:
@@ -44,20 +44,23 @@ Questions are used to collect the answers from users. Each question has a **titl
 
 Then there are some additional settings based on the **question type**.
 
+
 .. _options-question:
 
 Options Question
 ^^^^^^^^^^^^^^^^
 
 The options question contains a closed list of :ref:`answers<answer>` where users can pick one. Answers can have some follow-up questions that are only presented to the user when they pick the answer. So the options question can be used for questionnaire branching.
 
+
 .. _list-question:
 
 List Question
 ^^^^^^^^^^^^^
 
 The list question is used when there are multiple answers and we want to ask more details about those. For example, we can ask about different datasets that will be produced -- users will have multiple datasets but we want to ask the same questions for each of those. For that, we configure the **item template**, which defines the questions for each item.
 
+
 .. _value-question:
 
 Value Question
@@ -77,6 +80,7 @@ The value question asks for a single value that users type in. There are many di
 
 The input field differs based on the value type (simple input for string, date picker for date, etc.). Some of these have a check whether the entered value is valid (such as valid email or URL) and displays a warning if not.
 
+
 .. _integration-question:
 
 Integration Question
@@ -127,7 +131,6 @@ Reference
 
 We can provide some additional references for :ref:`questions<question>` to help users better understand it or learn more details. There are more types of references.
 
-
 URL Reference
 ^^^^^^^^^^^^^
 
@@ -139,6 +142,7 @@ Book Reference
 .. warning::
     Book references are deprecated.
 
+
 Resource Page Reference
 ^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -153,6 +157,7 @@ Expert
 
 We can provide a contact information to an expert for some :ref:`questions<question>`. An expert has a **name** and an **email**. We can use this, for example, if there is an expert for a specific topics in our institution and we want to make it easy to find out in our customized knowledge model.
 
+
 .. _metric:
 
 Metric
@@ -189,7 +194,7 @@ Question Tag
 
 We can define question tags on the knowledge model and then assign them to different :ref:`questions<question>`. This can be used to group together questions on the same topic or for the same purpose.
 
-When researchers create a new project from the knowledge model, they can only choose the question groups they are interested in for their research. So we can use this to create a very rich knowledge model but researchers will be able to use only the parts relevant to them.
+When researchers create a new project from the knowledge model, they can only choose the question groups they are interested in for their research. Selection of question tags is done in :ref:`custom project creation<create-project-custom>` So we can use this to create a very rich knowledge model but researchers will be able to use only the parts relevant to them.
 
 
 .. _integration:

docs/application/administration/locales/index.rst

@@ -5,7 +5,7 @@ After navigating to :guilabel:`Locales` (under :guilabel:`Administration`), we c
 
 There is always the **English** locale (``wizard:default:1.0.0``) which is embedded and cannot be deleted. For others, we can use :guilabel:`Export` and :guilabel:`Delete` options from the right item menu.
 
-Another option is to switch other locale to be the default one using :guilabel:`Set default` action. The default locale will be used in case no available locale tgat matching user's preferences (explicit or implicit from the web browser). We can :guilabel:`Disable` or :guilabel:`Enable` locales except the default one (which must be enabled).
+Another option is to switch other locale to be the default one using :guilabel:`Set default` action. The default locale will be used if there isn't an available locale that matches the user's preferences (explicit or implicit from the web browser). We can :guilabel:`Disable` or :guilabel:`Enable` locales except the default one (which must be enabled).
 
 If there is a locale with newer version available in the `DSW Registry <https://registry.ds-wizard.org>`__ (and if configured), *update available* clickable badge may appear. Finally, we can use :guilabel:`Import` to :doc:`./import` and :guilabel:`Create` to :doc:`./create`.
 

docs/application/administration/settings/content/document-submission.rst

@@ -3,7 +3,7 @@ Document Submission Settings
 
 If we enable the **Document Submission** feature, users will be able to see :guilabel:`Submit` option for their documents. After selecting it, they will be prompted to select a service compatible with the document where they want to submit it.
 
-Each service must have its own **ID** (recommended is to use lowecase alphanumeric symbols and dash symbols). Then, we can set human-readable **Name** and **Description** (Markdown-enabled) to clarify for users what is this service and in what cases they should use it. We also need to specify the **Supported Formats**, for each we need to select a document template, its version, and the desired format. Finally, we configure how the document is sent to the external service, the request may contain some **User Properties** (users will be able to set values for them in their user profiles) and it is a HTTP request with a specific **Method**, sent to the **URL**, possibly with HTTP **Headers**. The very last option is to check whether the file should be sent as **Multipart** (with its own **File Name**) instead of plainly in the request body. Most of this configuration should be specified by the external submission service.
+Each service must have its own **ID** (recommended is to use lowercase alphanumeric symbols and dash symbols). Then, we can set human-readable **Name** and **Description** (Markdown-enabled) to clarify for users what is this service and in what cases they should use it. We also need to specify the **Supported Formats**, for each we need to select a document template, its version, and the desired format. Finally, we configure how the document is sent to the external service, the request may contain some **User Properties** (users will be able to set values for them in their user profiles) and it is a HTTP request with a specific **Method**, sent to the **URL**, possibly with HTTP **Headers**. The very last option is to check whether the file should be sent as **Multipart** (with its own **File Name**) instead of plainly in the request body. Most of this configuration should be specified by the external submission service.
 
 .. NOTE::
 

docs/application/administration/settings/content/knowledge-models.rst

@@ -6,12 +6,12 @@ Knowledge Models Settings
 Public Knowledge Models
 =======================
 
-If we want to let users to see and browse certain Knowledge Models (specifically, visit the :ref:`KM detail<km-detail>` and the :ref:`KM preview<km-preview>`) even if not logged in, we can enable **Public Knowledge Models**. Then, we need to specify **Allowed Packages**, e.g. which ranges of verions of a certain knowledge model will be publicly available. A blank value serves as *any value*, for example, if we fill the **Organization ID** and **Knowledge Model ID** but leave **Min Version** and **Max Version**, it will result in all version of that knowledge model to be public.
+If we want to let users to see and browse certain Knowledge Models (specifically, visit the :ref:`KM detail<km-detail>` and the :ref:`KM preview<km-preview>`) even if not logged in, we can enable **Public Knowledge Models**. Then, we need to specify **Allowed Packages**, e.g. which ranges of versions of a certain knowledge model will be publicly available. A blank value serves as *any value*, for example, if we fill the **Organization ID** and **Knowledge Model ID** but leave **Min Version** and **Max Version**, it will result in all version of that knowledge model to be public.
 
 Integration Config
 ==================
 
-The integrations specified in Knowledge Models can use configuration values (typicaly secrets such as API keys or tokens) from YAML configuration specified in :ref:`integration.yml file<integration-yml-file>` or the content specified here under **Integration Config**. The value here can be for example:
+The integrations specified in Knowledge Models can use configuration values (typically secrets such as API keys or tokens) from YAML configuration specified in :ref:`integration.yml file<integration-yml-file>` or the content specified here under **Integration Config**. The value here can be for example:
 
 .. CODE-BLOCK:: yaml
 

docs/application/administration/settings/info/usage.rst

@@ -1,7 +1,7 @@
 Usage
 *****
 
-Usage allows us quickly see numbers of entities in the |project_name| instance such as number of users, active users, knowledge models, KM editors, templates, projects, or documents. Moverover, we can see storage usage, i.e. how much capacity is being used by documents and templates (their files). We cannot perform any actions on this page.
+Usage allows us quickly see numbers of entities in the |project_name| instance such as number of users, active users, knowledge models, KM editors, templates, projects, or documents. Moreover, we can see storage usage, i.e. how much capacity is being used by documents and templates (their files). We cannot perform any actions on this page.
 
 .. figure:: usage/usage.png
 

docs/application/administration/settings/user-interface/dashboard-and-login-screen.rst

@@ -26,7 +26,7 @@ We can select the **Dashboard Style** whether the user should see a standard **w
 
   * **Outdated KM / Document Templates Widgets** allow to quickly see outdated packages and document templates in case the DSW Registry connection is configured.
 
-  * **Usage Widget** summarises the usage just as is also possible to see in the :doc:`../info/usage`.
+  * **Usage Widget** summarizes the usage just as is also possible to see in the :doc:`../info/usage`.
 
   * **Configure Organization Widget** quickly navigates to :doc:`../system/organization` if it is not yet done.
 
@@ -64,7 +64,7 @@ Announcements
 
 Another option to adjust the dashboard and/or the login screen is to add Announcements. Announcements are displayed above the main content in the login screen. In dashboard, they are also displayed above the main content for both **welcome** and **role-based** dashboard style. There are three levels of Announcements:
 
-* **Info** - light blue color for sending informations to the users.
+* **Info** - light blue color for sending information to the users.
 * **Warning** - yellow to warn the users about something.
 * **Critical** - red to signalize the Announcement is critical and it needs attention.
 

docs/application/administration/settings/user-interface/look-and-feel.rst

@@ -7,13 +7,13 @@ This part of settings allows us to adjust how the |project_name| instance looks
 Application Titles
 ==================
 
-There are two titles that we can set. First, **Application Title** is the full title that should identify the |project_name| instance, for example, in browser's tab. Second is **Short Application Title** which is visibile, for example, at the top of the main (left) menu next to the icon. We should keep **Short Application Title** really short (about 10 characters at maximum) so it fits well.
+There are two titles that we can set. First, **Application Title** is the full title that should identify the |project_name| instance, for example, in browser's tab. Second is **Short Application Title** which is visible, for example, at the top of the main (left) menu next to the icon. We should keep **Short Application Title** really short (about 10 characters at maximum) so it fits well.
 
 
 Custom Menu Links
 =================
 
-We can easily add custom links to the main (left) menu by clicking :guilabel:`Add` under **Custom Menu Links**. For each link, we can set **Icon** (from `Font Awesome <https://fontawesome.com/v5/search>`_), **Title** and the target **URL**. We can also set whether the link should open in **New Window** (if not, it will nagivate user directly in the same window/tab from |project_name| instance). Once the links are there, we can manage them or delete them at this place.
+We can easily add custom links to the main (left) menu by clicking :guilabel:`Add` under **Custom Menu Links**. For each link, we can set **Icon** (from `Font Awesome <https://fontawesome.com/v5/search>`_), **Title** and the target **URL**. We can also set whether the link should open in **New Window** (if not, it will navigate user directly in the same window/tab from |project_name| instance). Once the links are there, we can manage them or delete them at this place.
 
 
 .. figure:: look-and-feel/custom-links.png

docs/application/document-templates/index.rst

@@ -3,7 +3,7 @@
 Document Templates
 ******************
 
-This section is about managing the document templates and document template editors. Similarly to Knowledge Models, we can manage :doc:`./list/index` or work on new or customise existing templates using :doc:`./editors/index`.
+This section is about managing the document templates and document template editors. Similarly to Knowledge Models, we can manage :doc:`./list/index` or work on new or customize existing templates using :doc:`./editors/index`.
 
 ----
 

docs/application/knowledge-models/editors/create.rst

@@ -17,6 +17,6 @@ Every knowledge model needs to have a **name**, a **knowledge model ID** and **v
 
     <organizationId>:<knowledgeModelId>:<version>
 
-We can create a new project either from scratch, i.e. the new knowledge model will be empty and we will build it all ourselves, or based on an existing knowledge models, which means that everything from the chosen knowledge model will be copied to ours. We can start from there and add, delete, or modifiy the existing entities in there. We just need to choose the original knowledge model in the **based on** field. Alternatively, we can open the :ref:`knowledge model detail<km-detail>` and click on :guilabel:`Fork KM` there.
+We can create a new project either from scratch, i.e. the new knowledge model will be empty and we will build it all ourselves, or based on an existing knowledge models, which means that everything from the chosen knowledge model will be copied to ours. We can start from there and add, delete, or modify the existing entities in there. We just need to choose the original knowledge model in the **based on** field. Alternatively, we can open the :ref:`knowledge model detail<km-detail>` and click on :guilabel:`Fork KM` there.
 
 We can only have one knowledge model editor with the same knowledge model ID. If we deleted the editor but want to continue working on that knowledge model, we can create a new editor with the same knowledge model ID. Or we can open the :ref:`knowledge model detail<km-detail>` and click on :guilabel:`Create KM editor` there to have the editor create form prefilled.

docs/application/knowledge-models/editors/index.rst

@@ -3,7 +3,7 @@
 Knowledge Model Editors
 ***********************
 
-Here, we can see a list of all knoweldge model editors. Everyone with the data steward role assigned can see all the knowledge model editors.
+Here, we can see a list of all knowledge model editors. Everyone with the data steward role assigned can see all the knowledge model editors.
 
 .. figure:: index/knowledge-model-editors-list.png
 

docs/application/knowledge-models/editors/migration.rst

@@ -47,7 +47,7 @@ During the migration, we can see all the changes one by one and can choose wheth
 Cancelling a Knowledge Model Migration
 ======================================
 
-We can cancell the knowledge model migration at any point before we publish the new version of the Child KM. We need to navigate to the :ref:`list of knowledge model editors<knowledge-model-editors>` and choose :guilabel:`Cancel migration` from the dropdown menu for the desired KM editor.
+We can cancel the knowledge model migration at any point before we publish the new version of the Child KM. We need to navigate to the :ref:`list of knowledge model editors<knowledge-model-editors>` and choose :guilabel:`Cancel migration` from the dropdown menu for the desired KM editor.
 
 
 Finishing a Knowledge Model Migration
@@ -64,6 +64,6 @@ The publish screen shows us some information about the knowledge model, such as
 
 Then we need to add some additional metadata (these fields are pre-filled if there was a previous version published):
 
-- **License** - this is used when we want to share the knowledge model with other people so they know how they can do that. We recommend using a license identifier from `SPDX Licens List <https://spdx.org/licenses/>`_.
+- **License** - this is used when we want to share the knowledge model with other people so they know how they can do that. We recommend using a license identifier from `SPDX Licenses List <https://spdx.org/licenses/>`_.
 - **Description** - this should be really short and descriptive. It is used, for example, in select boxes when creating a new project to help researchers choose the best knowledge model for their use case.
 - **Readme** - this is where we can describe everything we need about the knowledge model. We can, for example, include a changelog of what changed in what version, etc. We can use :ref:`Markdown<markdown>` in this field to provide some nice formatting.

docs/application/profile/edit/index.rst

@@ -7,7 +7,7 @@ In case of configured submission services, there might be additional inputs unde
 
 .. figure:: index/form.png
 
-    Form for editting profile with example submission settings.
+    Form for editing profile with example submission settings.
 
 
 .. NOTE::

docs/application/projects/list/templates.rst

@@ -16,7 +16,9 @@ When we want to turn a project into a project template we need to go to the :ref
 Sharing the Project Templates
 =============================
 
-Project templates follow the same rules for sharing as regular projects. Therefore, to make it available for other users, we need to set up proper :ref:`sharing settings<sharing>`.
+.. WARNING::
+
+    Project templates follow the same rules for sharing as regular projects. Therefore, to make it available for other users, we need to set up proper :ref:`sharing settings<sharing>`.
 
 We can either share them with specific users only, or we can simply enable that the project template is **visible by all other logged-in users** and that they can only **view** it (as we do not want them to change it).
 

docs/conf.py

@@ -25,7 +25,7 @@
 project_name_full = 'Data Stewardship Wizard'
 
 # The full version, including alpha/beta/rc tags
-version = release = '4.5'
+version = release = '4.6'
 
 rst_prolog = f"""
 

docs/more/development/document-templates/document-context.rst

@@ -31,7 +31,7 @@ Document context is an object that carries all information related to a DSW ques
 * ``updatedAt`` = timestamp when the document was last updated
 * ``uuid`` = UUID of the document
 
-This structure is provided to a Jinja template in :doc:`steps/jinja` and outputed from :doc:`steps/json`. We can use the JSON step to observe the actual content of the document context (structure as well as the values). Finally, we can also check :doc:`../metamodel-schemas` (the relevant JSON schema for document context).
+This structure is provided to a Jinja template in :doc:`steps/jinja` and outputted from :doc:`steps/json`. We can use the JSON step to observe the actual content of the document context (structure as well as the values). Finally, we can also check :doc:`../metamodel-schemas` (the relevant JSON schema for document context).
 
 
 Objectified Document Context

docs/more/development/document-templates/steps/jinja.rst

@@ -49,8 +49,8 @@ Filters
 
 Within Jinja templates, you can use so-called `filters <https://jinja.palletsprojects.com/en/3.0.x/templates/#filters>`__.Basically, those are functions applied to a first argument using pipe ``|`` symbol.
 
-Bultin Filters
-~~~~~~~~~~~~~~
+Builtin Filters
+~~~~~~~~~~~~~~~
 
 There are several widely used `builtin filters <https://jinja.palletsprojects.com/en/3.0.x/templates/#builtin-filters>`__ directly in Jinja.
 
@@ -182,8 +182,8 @@ Within Jinja templates, you can use so-called `tests <https://jinja.palletsproje
    {% endif %}
 
 
-Bultin Tests
-~~~~~~~~~~~~
+Builtin Tests
+~~~~~~~~~~~~~
 
 There are several widely used `builtin tests <https://jinja.palletsprojects.com/en/3.0.x/templates/#builtin-tests>`__ directly in Jinja.