Reelase 4.28 (Preview)

docs/applications/data-management-planner/knowledge-models/list/detail.rst

@@ -17,7 +17,14 @@ In the top pane, we can see the options based on our role:
 - :guilabel:`Fork KM` is again a shortcut for :doc:`../editors/create` for to create a fork (some more specific KM based on this one).
 - :guilabel:`Create project` is a shortcut to :doc:`../../projects/list/create` with this KM.
 - :guilabel:`Set deprecated` or :guilabel:`Restore` for setting a KM deprecated when we no longer want the **researchers** to use it.
-- :guilabel:`Delete` the specific version of the KM (possible only if is not used in any projects or linked in other KMs and editors, cannot be undone).
+- :guilabel:`Delete` for all versions of the KM. (Single version can be deleted from the KM's :doc:`./detail` page).
+
+.. WARNING::
+
+    It is possible to force delete a KM. Doing so will delete all KM versions, all KM editors based on this KM and all projects based on this KM, as well as all documents and files related to these projects.
+
+    This action is irreversible, so be careful when doing it.
+
 
 If we are not seeing the latest version of the KM, a warning message is shown in the top. Similarly, we will see a notification that update is available if there is a newer version in the `FAIR Wizard Registry <https://registry.fair-wizard.com/>`__.
 

docs/applications/data-management-planner/projects/index.rst

@@ -24,4 +24,3 @@ Projects are mainly used by the researchers. Watch this video to see the basic r
     List<list/index>
     Files<files>
     Documents<documents>
-    Importers<importers>

docs/applications/data-management-planner/projects/list/detail/questionnaire.rst

@@ -190,9 +190,9 @@ In the questionnaire tab, there is a menu bar with various options. The first on
 Import answers
 ==============
 
-Questionnaire answers can be imported for various sources using :ref:`project importers<importers>`.
+Questionnaire answers can be imported for various sources using :ref:`plugins<plugins>`.
 
-If there are some project importers available for the project, there is the :guilabel:`Import answers` button in the questionnaire menu bar. We can choose one of the available importers there and then follow the instructions in the importer window.
+If there are some project importer plugins available for the project, there is the :guilabel:`Import answers` button in the questionnaire menu bar. We can choose one of the available importer plugins there and then follow the instructions in the importer plugin window.
 
 
 .. _warnings:

docs/applications/data-management-planner/settings/system/plugins.rst

@@ -1,3 +1,5 @@
+.. _plugins:
+
 Plugins
 *******
 

docs/conf.py

@@ -18,15 +18,15 @@
 # -- Project information -----------------------------------------------------
 
 project = 'FAIR Wizard'
-copyright = '2020 - 2025, FAIR Wizard Team'
+copyright = '2020 - 2026, FAIR Wizard Team'
 author = 'FAIR Wizard Team'
 
 project_name = 'FAIR Wizard'
 project_name_full = 'FAIR Wizard'
 registry_name = 'FAIR Wizard Registry'
 
 # The full version, including alpha/beta/rc tags
-version = release = '4.27'
+version = release = '4.28'
 
 rst_prolog = f"""
 

docs/index.rst

@@ -88,9 +88,6 @@ Here are some recommended sections where to start based on the role:
     * - 
       - :ref:`integration-questions`
       - `Changelog <https://fair-wizard.com/changelog>`__
-    * - 
-      - :ref:`importers`
-      -
 
 .. raw:: html
 

docs/more/development/index.rst

@@ -1,7 +1,7 @@
 Development
 ***********
 
-|project_name| can be extended in many ways and new components and ways of integrations can be developed to support our needs. Besides the API available for everything that can be done in |project_name|, new :ref:`integration questions<integration-questions>` and :ref:`project importers<development-importers>` can be implemented to get data from outside to |project_name|, or new :ref:`document templates<document-template-development>` and :ref:`submission services<submission-service>` can be created to get the data outside of |project_name| in the desired form.
+|project_name| can be extended in many ways and new components and ways of integrations can be developed to support our needs. Besides the API available for everything that can be done in |project_name|, new :ref:`integration questions<integration-questions>` or new :ref:`document templates<document-template-development>` and :ref:`submission services<submission-service>` can be created to get the data outside of |project_name| in the desired form.
 
 This section provides information on how to develop custom content for |project_name| to fully tailor the tool to our specific requirements.
 
@@ -19,6 +19,5 @@ This section provides information on how to develop custom content for |project_
     metamodel-schemas
     Document Templates<document-templates/index>
     integration-questions/index
-    Project Importers<importers>
     submission-service
     Integration via API<api>

docs/more/development/integration-questions/index.rst

@@ -21,4 +21,5 @@ There are two ways of how we can connect |project_name| to these services:
     :maxdepth: 1
 
     API<integration-api>
+    Migration<migration>
     Widget<integration-widget>

docs/more/development/integration-questions/integration-api.rst

@@ -1,3 +1,5 @@
+.. _integration-api:
+
 Integration Question - API
 **************************
 
@@ -24,6 +26,8 @@ If we want to connect an external service using the API there are certain requir
   - The response must be JSON so |project_name| can parse it
   - There needs to be a JSON list where all the items matching the search query are
 
+.. _integration-api-configuration:
+
 Configuration
 =============
 
@@ -35,7 +39,7 @@ Watch this video to learn the basic API Integration setup:
 
 
 The configuration is done in the :ref:`knowledge model editor<knowledge-model-editor>`. First of all, we need to create a new integration and choose its **Type** to be **API**. Then we need to fill the integration **Name**.
-  
+
 Advanced Integration Configuration
 ----------------------------------
 
@@ -177,7 +181,7 @@ Secrets and Other Properties (Legacy)
 
 Sometimes, we might need to use some secrets (for example for authentication token), additional properties (such as API URL if we want to use different one for testing and production), or basically any information that we do not want to include in the knowledge model. In that case, we can define some properties in the instance settings.
 
-We need to navigate to :guilabel:`Administration → Settings → Knowledge Models` and there is a field called **Integration Config**. It is a YAML organized by the **Integration ID** at the top level and key value pairs for each property.
+We need to navigate to :guilabel:`Administration → Settings → knowledge models` and there is a field called **Integration Config**. It is a YAML organized by the **Integration ID** at the top level and key value pairs for each property.
 
 We can fill some properties in. So, for example, if the **Integration ID** of our integration is *ourIntegration* we can write:
 

docs/more/development/integration-questions/migration.rst

@@ -0,0 +1,116 @@
+.. _integration-migration:
+
+Migration from Legacy API Integration
+*************************************
+
+To migrate a knowledge model from API Integration Legacy to API Integration v2, we need to recreate the integration and connect it to the respective questions. To do that, open the knowledge model Editor. There, navigate to the existing integrations. The best practice is to create the integration from scratch. You can follow this :ref:`configuration guide<integration-api-configuration>`.
+
+We recommend recreating the integration to keep the original one as a reference. This allows you to copy the configuration from it and identify which questions are using the legacy integration so you can connect them to the new one.
+
+Once the new API Integration v2 instances are successfully created and the integration questions are connected to them, you can delete the old integrations and release the knowledge model. Then you can migrate projects.
+
+.. NOTE::
+
+    If you somehow manage to lose the content of the integrations before they are recreated, you can always create a new knowledge model editor.
+
+During the migration from API Integration Legacy to API Integration v2, the existing integration replies in projects are migrated automatically. However, there are differences in how the data is stored. The following sections describe how the data is handled in each state:
+- Legacy API Integration
+- Migrated to API Integration v2 (legacy data)
+- New API Integration v2 with “raw = HTTP response”
+
+**State A — Legacy API Integration (ApiLegacyIntegration)**
+
+This is how API Integration Legacy stores the data.
+
+**What is stored:**
+
+- an ``id`` (the selected item identifier)
+- a ``type``: ``IntegrationLegacyType``
+- a ``value`` (the rendered markdown or text displayed in the UI)
+
+.. code:: json
+
+    {
+        "type": "IntegrationReply",
+        "value": {
+            "id": "0000-0003-3856-1682",
+            "type": "IntegrationLegacyType",
+            "value": "**Kryštof** **Komanec** \nORCID: **0000-0003-3856-1682** \n\n\n*Czech Technical University in Prague*  \n*Prague University of Economics and Business*  \n "
+        }
+    }
+
+
+**State B — Migrated to API Integration v2 (existing data)**
+
+After migrating to API Integration v2, the existing data is stored differently.
+
+**What changes compared to Legacy:**
+
+- ``id`` is **removed**
+- ``raw`` is introduced but remains empty: ``"raw": {}``
+- ``type`` becomes ``IntegrationType`` instead of ``IntegrationLegacyType``
+- ``value`` remains the same (the markdown reply rendered in the UI)
+
+.. code:: json
+
+    {
+        "type": "IntegrationReply",
+        "value": {
+            "raw": {},
+            "type": "IntegrationType",
+            "value": "**Kryštof** **Komanec** \nORCID: **0000-0003-3856-1682** \n\n\n*Czech Technical University in Prague*  \n*Prague University of Economics and Business*  \n "
+        }
+    }
+
+
+**State C — New API Integration v2 with IntegrationType reply**
+
+If you delete the old answer and provide a new one, or if you answer a new integration question using API Integration v2, the data is stored differently. The semantics of the stored data also change. The ``raw`` field now contains the raw HTTP response from the API, which can be used in the answer template.
+
+**What is stored:**
+
+- ``raw`` = the actual integration HTTP response item or body, which serves as the source of truth
+- ``type`` = ``IntegrationType``
+- ``value`` = custom text entered by the user or rendered template output, generated from the ``raw`` data using the answer template
+
+.. code:: json
+
+    {
+        "type": "IntegrationReply",
+        "value": {
+            "raw": {
+                "credit-name": null,
+                "email": [],
+                "family-names": "Komanec",
+                "given-names": "Kryštof",
+                "institution-name": [
+                    "Czech Technical University in Prague",
+                    "Prague University of Economics and Business"
+                ],
+                "orcid-id": "0000-0003-3856-1682",
+                "other-name": []
+            },
+            "type": "IntegrationType",
+            "value": "**Kryštof** **Komanec** \nORCID: [**0000-0003-3856-1682**](https://orcid.org/0000-0003-3856-1682)\n\n"
+        }
+    }
+
+
+**State D - New API Integration v2 with PlainType reply**
+
+If custom reply is enabled in the integration configuration, the answer to an integration question can also be a plain text. In that case, the data is stored as follows.
+
+**What is stored:**
+
+- ``type`` = ``PlainType``
+- ``value`` = the plain text answer provided by the user.
+
+.. code:: json
+
+    {
+        "type": "IntegrationReply",
+        "value": {
+            "type": "PlainType",
+            "value": "https://orcid.org/0000-0003-3856-1682"
+        }
+    }