ds-wizard · krystofkomanec · Jun 4, 2026 · Jun 3, 2026 · Jun 3, 2026 · Jun 4, 2026
diff --git a/docs/application/administration/settings/system/authentication.rst b/docs/application/administration/settings/system/authentication.rst
@@ -12,13 +12,17 @@ The **Default Role** settings option allows us to define which role is assigned
 Internal
 ========
 
-For internal authentication, we can set whether the **Registration** is enabled or not. If enabled, any user who can visit the |project_name| instance may sign up (and obtain the default role).
+For internal authentication, we can set:
 
-.. NOTE::
+- **Registration** - whether users can sign up on their own or not.
+- **Non-Admin Login** - whether non-admin users can log in to the |project_name| instance or not.
+- **Two-Factor Authentication** - whether users need to confirm their login with a one-time code sent to their email address or not.
+- **Session Expiration** - how long the user session is valid before the user needs to log in again in hours.
+- **User Email Link Expiration** - how long the email links (e.g., for password reset) are valid before they expire and cannot be used anymore in hours.
 
-    In case we are using OpenID or creating user accounts manually, registrations should be disabled.
+.. NOTE::
 
+    In case we are using OpenID or creating user accounts manually, registrations should be disabled. It is recommended to also disable non-admin login.
 
-Another option is whether the **Two-Factor Authentication** (2FA) is enabled. If enabled, once users try to log in using credentials, they receive an email message with one-time code to confirm the login. Moreover, we can configure **Code Length** (how many character the code has) and **Expiration** period in seconds.
 
-We can also set up **Session Expiration** and **User Email Link Expiration** in hours. The first one defines how long the user session is valid before the user needs to log in again. The second one defines how long the email links (e.g., for password reset) are valid before they expire and cannot be used anymore.
+For **Two-Factor Authentication** (2FA) we can also configure **Code Length** (how many character the code has) and **Expiration** period in seconds.
diff --git a/docs/application/administration/settings/system/openid.rst b/docs/application/administration/settings/system/openid.rst
@@ -28,7 +28,7 @@ Microsoft Azure Setup
 11. Fill description, set ``Expires`` and note it somewhere, then click on ``Add``.
 12. Copy ``Value`` and store it somewhere. You will not able to view it again.
 
-13. Go to OpenID in DSW: ``Admin Center`` → ``Settings`` → ``Organization OpenID`` → ``Create``.
+13. Go to OpenID in DSW: ``Settings`` → ``OpenID`` → ``Create``.
 
 14. Fill in a ``Name`` of the service. This name will be used to identify the service in the list of login options, so it should be something descriptive.
 
@@ -72,7 +72,7 @@ ORCID Setup
 
 ORCID requires a redirect URI before it allows us to save the application and obtain credentials. Because DSW generates the callback URL only after the OpenID configuration is saved, we first create the DSW configuration with temporary credentials and then return to ORCID.
 
-1. Go to OpenID in DSW: ``Admin Center`` → ``Settings`` → ``Organization OpenID`` → ``Create``.
+1. Go to OpenID in DSW: ``Settings`` → ``OpenID`` → ``Create``.
 2. Fill in a ``Name`` of the service, for example ``ORCID``.
 3. Open the ``Custom`` tab.
 4. Fill in temporary values:
@@ -82,7 +82,7 @@ ORCID requires a redirect URI before it allows us to save the application and ob
 5. Leave ``Parameters`` empty.
 6. (optional) fill Icon (``fab fa-orcid``), ``Background Color`` (``#A6CE39``), and ``Text Color``.
 7. Click on ``Save``.
-8. Copy ``Callback URL`` from DSW. It will look similar to ``https://example.fair-wizard.com/admin/open-id/<uuid>/callback``.
+8. Copy ``Callback URL`` from DSW. It will look similar to ``https://<your-domain>/wizard/open-id/<uuid>/callback``.
 
 9. Go to https://orcid.org/signin and sign in to ORCID.
 10. Open ``Developer Tools`` from the account menu.
@@ -115,7 +115,7 @@ ORCID requires a redirect URI before it allows us to save the application and ob
 Custom Setup
 ============
 
-1. Go to OpenID in DSW: ``Admin Center`` → ``Settings`` → ``Organization OpenID`` → ``Create``.
+1. Go to OpenID in DSW: ``Settings`` → ``OpenID`` → ``Create``.
 2. Fill in a ``Name`` of the service. This name will be used to identify the service in the list of login options, so it should be something descriptive.
 3. Open the ``Custom`` tab.
 4. Prepare the OpenID endpoint ``URL``. This is usually the issuer URL of the provider. If the provider gives us a URL ending with ``/.well-known/openid-configuration``, use only the part before this suffix.

diff --git a/docs/application/administration/settings/system/plugins.rst b/docs/application/administration/settings/system/plugins.rst
@@ -5,7 +5,7 @@ Plugins
 
 On this page, you can enable or disable plugins. Some plugins may require additional configuration, which can also be edited here.
 
-.. TODO::
-
-    Add screenshot
+.. figure:: plugins/plugins.png
+    
+    List of available plugins.
 
diff --git a/docs/application/administration/settings/system/plugins/plugins.png b/docs/application/administration/settings/system/plugins/plugins.png
diff --git a/docs/application/knowledge-models/list/compare.rst b/docs/application/knowledge-models/list/compare.rst
@@ -7,7 +7,9 @@ We can compare two versions of a knowledge model by clicking :guilabel:`Compare`
 
 The comparison can be starter in project migration and in KM list and detail.
 
-.. TODO::
-
-    Add screenshot
+.. figure:: compare/compare.png
+    :width: 500
+
+    Creating a KM comparison.
 
+
diff --git a/docs/application/knowledge-models/list/compare/compare.png b/docs/application/knowledge-models/list/compare/compare.png
diff --git a/docs/application/profile/settings/connected-accounts.rst b/docs/application/profile/settings/connected-accounts.rst
@@ -0,0 +1,11 @@
+.. _connected-accounts:
+
+Connected Accounts
+******************
+
+In the **Connected Accounts** section, we can see the list of connected accounts and manage them. We can add or remove external identity providers that we can use to log in to the |project_name| instance.
+
+.. TODO::
+
+    Add screenshot
+
diff --git a/docs/application/profile/settings/index.rst b/docs/application/profile/settings/index.rst
@@ -28,6 +28,7 @@ If we want to :doc:`./password`, we need to switch to :guilabel:`Password` from
     :maxdepth: 2
 
     Password<password>
+    Connected Accounts<connected-accounts>
     Language<language>
     API Keys<api-keys>
     Active Sessions<active-sessions>

diff --git a/docs/more/self-hosted-dsw/upgrade-guidelines.rst b/docs/more/self-hosted-dsw/upgrade-guidelines.rst
@@ -48,7 +48,7 @@ Usually, nothing special is required for the upgrade. Internal structure changes
 4.30.X to 4.31.X
 ----------------
 
-- ``callbackUrl`` and ``logoutUrl`` in :ref:`openid-settings` changed. It is necessary to adjust those values in the **OpenID** provider.
+- Copy the ``clientId`` and ``clientSecret`` again from your :ref:`openid-settings` provider, as the values currently stored in the wizard are no longer valid. Then take the newly generated ``callbackUrl`` and ``logoutUrl`` from the wizard and configure them in your **OpenID** provider.
 
 4.29.X to 4.30.X
 ----------------