update docs (#1389)

docs/source/app_projectroles_usage.rst

@@ -27,6 +27,12 @@ One can either log in using a local Django user or, if LDAP/AD is enabled, their
 LDAP/AD credentials from a supported site. In the latter case, the user domain
 must be appended to the user name in form of ``user@DOMAIN``.
 
+If OpenID Connect (OIDC) single-sign on authentication is enabled, an extra
+login element will be displayed next to the standard login controls. This will
+take the user to the login view of the OIDC provider. The element can be
+replaced with a custom template to e.g. use specific graphics recommended by the
+provider.
+
 .. figure:: _static/app_projectroles/sodar_login.png
     :align: center
     :scale: 75%
@@ -325,12 +331,6 @@ and the user email domain is not associated with configured LDAP domains.
 Invites expire after a certain time and can be reissued or revoked on the
 :guilabel:`Project Invites` page.
 
-.. note::
-
-    If the site enables both LDAP and OpenID Connect (OIDC) authentication,
-    LDAP will take precedent over OIDC login in invites if a configured LDAP
-    domain is recognized in the user email address.
-
 Batch Member Modifications
 --------------------------
 

docs/source/app_timeline_usage.rst

@@ -156,9 +156,9 @@ Defining Status States
     need to pay attention to this functionality right now.
 
 By default, ``timeline.add_event()`` treats events as synchronous and
-automatically saves them with the status of ``TL_STATUS_OK``. However, in case of e.g.
-asynchronous requests, you can alter this by setting the ``status_type`` and
-(optionally) ``status_desc`` types upon creation.
+automatically saves them with the status of ``TL_STATUS_OK``. However, in case
+of e.g. asynchronous requests, you can alter this by setting the ``status_type``
+and (optionally) ``status_desc`` types upon creation.
 
 .. code-block:: python
 
@@ -182,8 +182,8 @@ Currently supported status types are listed below, some only applicable to async
 events:
 
 - ``TL_STATUS_OK``: All OK, event successfully performed
-- ``TL_STATUS_INFO``: Used for events which do not change anything, e.g. viewing something
-  within an app
+- ``TL_STATUS_INFO``: Used for events which do not change anything, e.g. viewing
+  something within an app
 - ``TL_STATUS_INIT``: Initializing the event in progress
 - ``TL_STATUS_SUBMIT``: Event submitted asynchronously
 - ``TL_STATUS_FAILED``: Asynchronous event submission failed

docs/source/dev_project_app.rst

@@ -643,10 +643,10 @@ use e.g. ``all`` as your only category. Example of a return data:
     # ...
     return [
         PluginSearchResult(
-            'category': 'all',  # Category ID to be used in your search template
-            'title': 'List title',  # Title of the result set
-            'search_types': [],  # Object types included in this category
-            'items': [],  # List or QuerySet of objects returned by search
+            category='all',  # Category ID to be used in your search template
+            title='List title',  # Title of the result set
+            search_types=[],  # Object types included in this category
+            items=[],  # List or QuerySet of objects returned by search
         )
     ]
 

docs/source/major_changes.rst

@@ -51,11 +51,11 @@ Django v4.2 Upgrade
 -------------------
 
 This release updates SODAR Core from Django v3.2 to v4.2. This is a breaking
-change which causes many updates and also potentially requires updating several
+change which causes many updates and also requires updating several
 dependencies.
 
-To upgrade, please update the Django requirement along with your site's other
-Python requirements to match ones in ``requirements/*.txt``. See
+Please update the Django requirement along with your site's other Python
+requirements to match ones in ``requirements/*.txt``. See
 `Django deprecation documentation <https://docs.djangoproject.com/en/dev/internals/deprecation/>`_
 for details about what has been deprecated in Django and which changes are
 mandatory.
@@ -74,13 +74,13 @@ System Prerequisites
 --------------------
 
 PostgreSQL
-    The minimum required PostgreSQL version has been bumped to v12. In CI we
-    currently use PostgreSQL v16, but anything from v12 to above should work
-    with this SODAR Core release. It is strongly recommended to make backups of
-    your production databases before upgrading.
+    The minimum required PostgreSQL version has been bumped to v12. We recommend
+    PostgreSQL v16 which is used in CI for this repo. However, any version from
+    v12 onwards should work with this release. We strongly recommended to make
+    backups of your production databases before upgrading.
 Python v3.11 Support Added
-    Python v3.11 support has been officially added in this version. 3.11 is now
-    also the recommended Python version to use.
+    Python v3.11 support has been officially added in this version. 3.11 is also
+    the recommended Python version.
 Python v3.8 Support Dropped
     This release no longer supports Python v3.8.
 General Python Dependencies
@@ -91,11 +91,11 @@ General Python Dependencies
 REST API Versioning Overhaul
 ----------------------------
 
-The REST API versioning system has been overhauled in this release. Before, we
-used two separate accept header versioning systems: 1) API views in SODAR Core
-apps with ``CORE_API_MEDIA_TYPE``, and 2) API views of the site built on SODAR
-Core with ``SODAR_API_MEDIA_TYPE``. The version number has been expected to
-match the SODAR Core or the site version number, respectively.
+The REST API versioning system has been overhauled. Before, we used two separate
+accept header versioning systems: 1) API views in SODAR Core apps with
+``CORE_API_MEDIA_TYPE``, and 2) API views of the site built on SODAR Core with
+``SODAR_API_MEDIA_TYPE``. The version number has been expected to match the
+SODAR Core or the site version number, respectively.
 
 In the new system there are two critical changes to this versioning scheme:
 
@@ -194,7 +194,6 @@ If your site only accesses these models through ``TimelineAPI`` and
 ``TimelineAPI.get_model()``, which is the strongly recommended way, no changes
 should be required.
 
-
 AppSettingAPI Plugin Name Arguments Updated
 -------------------------------------------