diff --git a/docs/source/_static/app_projectroles/sodar_login.png b/docs/source/_static/app_projectroles/sodar_login.png index 4bfcb197..620e1c01 100644 Binary files a/docs/source/_static/app_projectroles/sodar_login.png and b/docs/source/_static/app_projectroles/sodar_login.png differ diff --git a/docs/source/app_projectroles_usage.rst b/docs/source/app_projectroles_usage.rst index 785ce6b9..3dc43c44 100644 --- a/docs/source/app_projectroles_usage.rst +++ b/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 -------------------------- diff --git a/docs/source/app_timeline_usage.rst b/docs/source/app_timeline_usage.rst index 7712530b..4699b688 100644 --- a/docs/source/app_timeline_usage.rst +++ b/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 diff --git a/docs/source/dev_project_app.rst b/docs/source/dev_project_app.rst index 165b1bc5..00c32c68 100644 --- a/docs/source/dev_project_app.rst +++ b/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 ) ] diff --git a/docs/source/major_changes.rst b/docs/source/major_changes.rst index 80501687..ed9c8016 100644 --- a/docs/source/major_changes.rst +++ b/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 `_ 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 -------------------------------------------