Official v12 release notes

docs/customize/dois.md

@@ -80,7 +80,9 @@ record that is published. The second DOI is the parent DOI, which represents
 the concept of the record and will always resolve to the latest version.
 This feature has been implemented in Zenodo for many years, and the concept DOI enables
 researchers to cite something that won't change when they make changes to their
-records. 
+records.
+
+![Concept DOI help-text](./img/concept_doi.png)
 
 The parent DOI is optional and can be disabled by setting the following in
 invenio.cfg:

docs/customize/index.md

@@ -35,3 +35,4 @@ In the following sections, we cover customization opportunities that InvenioRDM
     - [Subjects](vocabularies/subjects.md)
     - [Users](vocabularies/users.md)
 - [Internationalisation (i18n) and Localisation (l10n)](i18n-and-l10n.md)
+- [Notifications](notifications.md) - customize content, recipients and backends of notifications

docs/customize/notifications.md

@@ -0,0 +1,146 @@
+# Notifications
+
+Depending on your instance needs regarding notifications, you might want to customize the configuration values provided by the `invenio-notifications` module.
+
+Specifically, we are going to have a look at templates and the following variables:
+
+- [NOTIFICATIONS_BACKENDS](#notifications_backends)
+- [NOTIFICATIONS_BUILDERS](#notifications_builders)
+
+## Templates
+
+In order to provide your own customized templates or override parts of existing ones, templates can be placed in the `my_site/templates/semantic-ui/invenio_notifications` folder. The file name then has to match the base template name (e.g. `community-submission.submitted.jinja`).
+
+Let's have a look at a base template and then customize parts of it for our own needs.
+
+Assume a notification context like this:
+
+```py
+{
+    "request": {
+        "links": {
+            "self_html": "<link to the request>",
+        },
+        "created_by": {
+            "id": 3,
+            "username": "Chris the Creator",
+        },
+        "receiver": {
+            "id":  "3fc4fcaa-ce2c-4ec7-97cd-4b29ca204035",
+            "metadata": {
+                "title": "Notification Community",
+            },
+            "links": {
+                "self_html": "<link to the community>",
+            }
+        },
+        "topic": {
+            "id": "49e72dea-f14a-4774-a52d-a3d581fed86e",
+            "metadata": {
+                "title": "My Submitted Record",
+            },
+        }
+    }
+}
+```
+
+```jinja
+{# notifications/community-submission.submitted.jinja #}
+
+{%- block subject -%}
+New record submission for your community {{ notification.context.get("request").get("receiver").get("metadata").get("title") }} submitted by {{ notification.context.get("request").get("created_by").get("username") }}
+{%- endblock subject -%}
+
+{%- block html_body -%}
+<p>The record "{{ notification.context.get("request").get("topic").get("metadata").get("title") }}" was submitted to your community {{ notification.context.get("request").get("receiver").get("metadata").get("title") }} by {{ notification.context.get("request").get("created_by").get("username") }}.</p>
+
+<a href="{{ notification.context.get("request").get("links").get("self_html") }}" class="button">Review the request</a>
+{%- endblock html_body -%}
+
+{%- block plain_body -%}
+The record "{{ notification.context.get("request").get("topic").get("metadata").get("title") }}" was submitted to your community {{ notification.context.get("request").get("receiver").get("metadata").get("title") }} by {{ notification.context.get("request").get("created_by").get("username") }}.
+
+Review the request: {{ notification.context.get("request").get("links").get("self_html") }}
+{%- endblock plain_body -%}
+```
+
+We are pretty happy with most of the content, but want to override the `html_body` to include a link to the community and all requests.
+To do this, we will create a file with the same name and extend the base template.
+
+```jinja
+
+{% extends "invenio_notifications/community-submission.submitted.html" %}
+
+{% block html_body %}
+
+<p>The record "{{ notification.context.get("request").get("topic").get("metadata").get("title") }}" was submitted to your community {{ notification.context.get("request").get("receiver").get("metadata").get("title") }} by {{ notification.context.get("request").get("created_by").get("username") }}.</p>
+
+<a href="{{ notification.context.get("request").get("receiver").get("links").get("self_html") }}" class="button">Check out the community"</a>
+
+<a href="{{ notification.context.get("request").get("links").get("self_html") }}" class="button">Review the request</a>
+
+<a href="{{ notification.context.get("request").get("receiver").get("links").get("self_html") + "/requests" }}" class="button">Check out all community requests</a>
+
+
+{% endblock %}
+```
+
+## NOTIFICATIONS_BACKENDS
+
+This config variable allows to specify the available backends.
+For instance, you can provide an implementation of your institute specific tool of communication and send notifications via this backend. For this, simply extend the `NotificationBackend` class and implement the `send` method.
+
+```py
+from invenio_notifications.backends import JinjaTemplateLoaderMixin, NotificationBackend,
+
+class InstitutationalBackend(NotificationBackend, JinjaTemplateLoaderMixin):
+    """Base class for notification backends."""
+
+    id = "institutional-backend"
+    """Unique id of the backend."""
+
+    def send(self, notification, recipient):
+        """Send the notification message as markdown to a user."""
+        template = self.render_template(notification=notification, recipient=recipient)
+        institutation_communication_tool.send_message(user_id=recipient.data["id"], template["md_body"])
+```
+
+This backend can now be specified (e.g. in `invenio.cfg`):
+
+```py
+NOTIFICATION_BACKENDS = {
+    EmailNotificationBackend.id: EmailNotificationBackend,
+    InstitutationalBackend.id: InstitutationalBackend,
+}
+```
+
+## NOTIFICATIONS_BUILDERS
+
+This config variable defines which builder class should be used for a specific notification type.
+Let us assume that you want to override who will get notified in the event of a community record submission (community curator and owner) and add the previously defined backend (so recipients will get notified via whatever the base class has defined and via the `InstitutationalBackend`).
+To do this, we will create a custom builder, which will inherit most of the properties from the existing base class.
+
+```py
+from institutational_package.notifications import InstitutationalBackend
+from invenio_communities.notifications.generators import CommunityMembersRecipient
+from invenio_rdm_records.notifications.builders import CommunityInclusionSubmittedNotificationBuilder
+
+class CustomSubmissionBuilder(CommunityInclusionSubmittedNotificationBuilder):
+
+    # properties not overwritten will keep their base value
+    recipients = [
+        CommunityMembersRecipient(key="request.receiver", roles=["curator", "owner"]),
+    ]
+
+    recipient_backends = CommunityInclusionSubmittedNotificationBuilder.recipient_backends + [
+        InstitutationalBackend(),
+    ]
+```
+
+This builder can now be specified (e.g. in `invenio.cfg`):
+
+```py
+NOTIFICATIONS_BUILDERS = {
+    CustomSubmissionBuilder.type: CustomSubmissionBuilder,
+}
+```

docs/develop/architecture/notifications.md

@@ -6,6 +6,7 @@ The notification system in InvenioRDM is provided via the [`invenio-notification
 
 
 ## Service Level
+
 Notifications are registered at the service level in the unit of work and send off to a celery task - which takes care of further processing. When dispatching this notification in the service, the context shall be as minimal as possible, to reduce passing huge chunks of data.
 The implications of sending all of the required immediately would be a hit on performance and higher memory usage.
 As the notification operations are registered during methods of the service level, it would increase response time for requests using these methods.
@@ -28,9 +29,8 @@ After it is build, it can be dumped and send to a background task for further pr
 
 
 ## Notification Manager
-A notification manager is created, which will rely on certain [configuration values](../howtos/notifications.md#configuration-values) and provide logic to send notifications. Its task is also to call respective methods to resolve the notification context, generate recipients, filter recipients and generate the backend ids for further processing. With all information created, it will then dispatch further tasks to relay the notification to the backend, which will take care of sending the actual notification.
-
 
+A notification manager is created, which will rely on certain [configuration values](../howtos/notifications.md#configuration-values) and provide logic to send notifications. Its task is also to call respective methods to resolve the notification context, generate recipients, filter recipients and generate the backend ids for further processing. With all information created, it will then dispatch further tasks to relay the notification to the backend, which will take care of sending the actual notification.
 
 <details>
 <summary>A recipient entity could look like this</summary>

docs/develop/howtos/notifications.md

@@ -187,7 +187,7 @@ Configuration values used in the `invenio-notifications` module can be overriden
 
 ### NOTIFICATION_BACKENDS
 
-This config variable allows to specify the available backends. For a detailed description on backends, checkout the respective [reference section](/reference/notifications/#backends).
+This config variable allows to specify the available backends. For a detailed description on backends, checkout the respective [reference section](../../reference/notifications.md#backends).
 For instance, you can provide an implementation for your institution's preferred communication tool and send notifications via this backend.
 
 As an example, take the backend shown in [build your own backend](#notification-backend). Then you only have to specify it in the config variable (e.g. in `invenio.cfg`).
@@ -201,7 +201,7 @@ NOTIFICATION_BACKENDS = {
 
 ### NOTIFICATION_BUILDERS
 
-Specifies [notification builders](#notificationbuilder) to be used for certain types of notifications. When a notification is handled by the manager, it will lookup the type in this variable and build the notification with the provided builder class.
+Specifies [notification builders](#notification-builder) to be used for certain types of notifications. When a notification is handled by the manager, it will lookup the type in this variable and build the notification with the provided builder class.
 
 As an example, take the backend shown in [build your own builder](#notification-builder). Then you only have to specify it in the config variable (e.g. in `invenio.cfg`).
 
@@ -222,7 +222,7 @@ NOTIFICATIONS_BUILDERS = {
 
 ### NOTIFICATIONS_ENTITY_RESOLVERS
 
-Specifies entity resolvers (not to be confused with [EntityResolve](#entityresolve)) to be used for resolving the notification context. These are usually `ServiceResultResolver` objects, which provide functionality to dump an object to a reference dictionary and later on use the dump to fetch information as seen on the API/service level (i.e. fully resolved objects with links for easy access).
+Specifies entity resolvers to be used for resolving the notification context. These are usually `ServiceResultResolver` objects, which provide functionality to dump an object to a reference dictionary and later on use the dump to fetch information as seen on the API/service level (i.e. fully resolved objects with links for easy access).
 
 ```py
 NOTIFICATIONS_ENTITY_RESOLVERS = [

docs/features/features-walk-through/access_requests.md

@@ -11,15 +11,21 @@ Note: accepted access requests grant to the requestor access to **all** versions
 ## Enable access requests
 
 As a record owner, you first need to allow accessing restricted files via a request:
+
 0. Create a record with restricted files
+
 1. Click on the "Share" button on the record landing page:
 ![Share button](./img/access_request_share_button.png)
-2. Navigate to the "Access requests" tab of the modal:
+
+2. Navigate to the "Settings" tab of the modal:
 ![Access requests tab](./img/access_requests_tab.png)
+
 3. Change the settings for the access requests:
-*  Allow authenticated or/and unauthenticated users to request access to restricted files of your record.
-*  Accept conditions. Provide a message that will be visible to the users in the request form (see screenshots below)
-*  Set access expiration date. This setting will be applied by default to all access requests. When reviewing an access request, you can set a different value.
+
+    * Allow authenticated or/and unauthenticated users to request access to restricted files of your record.
+    * Accept conditions. Provide a message that will be visible to the users in the request form (see screenshot below)
+    * Set access expiration date. This setting will be applied by default to all access requests. When reviewing an access request, you can set a different value.
+
 4. Save your changes
 ![Access requests tab save](./img/access_requests_tab_save.png)
 

docs/features/features-walk-through/notifications.md

@@ -1,8 +1,10 @@
 # Notifications
 
-Notifications are sent at specific events (e.g. community invitation, community recod submission), to inform users of relevant actions. Institutions can define their own available ways of sending notifications. InvenioRDM ships with E-Mail notifications as standard.
+_Introduced in InvenioRDM v12_
 
-As an example, imagine submitting a record to a community. When you do this, a notification will be sent to community owners and managers informing them of your request. When they comment on your request, you will receive a notification of said comment. This will allow all participating parties to get informed of relevant actions and updates, without the need of manually observing the site.
+Notifications are sent at specific events (e.g. community invitation, community record submission), to inform users of relevant actions. Institutions can define their own available ways of sending notifications. InvenioRDM ships with E-Mail notifications as standard.
+
+As an example, imagine submitting a record to a community. When you do this, a notification will be sent to community owners and managers informing them of your request. When they comment on your request, you will receive a notification of said comment. This will allow all participating parties to get informed of relevant actions and updates, without anyone needing to manually observe the site.
 
 ## Notification Settings
 

docs/index.md

@@ -5,6 +5,6 @@ hide:
 template: frontpage.html
 ---
 
-!!! tip "Jan 26th, 2023: InvenioRDM v11 released"
+!!! tip "August 1st, 2024: InvenioRDM v12.0 Long-term support available! ✨"
 
-    🚀 Read the full [release notes](releases/versions/version-v11.0.0.md).
+    🚀 Read the full [release notes](releases/versions/version-v12.0.0.md).

docs/install/index.md

@@ -35,13 +35,13 @@ invenio-cli check-requirements
 
 Scaffold your InvenioRDM instance. Replace ``<version>`` with the version you want to install:
 
-- LTS release (for production systems): ``v9.1``
+- LTS release (for production systems): ``v12.0``
 - STS release (for feature previews): ``v11.0``
 
 ```shell
 invenio-cli init rdm -c <version>
 # e.g:
-invenio-cli init rdm -c v9.1
+invenio-cli init rdm -c v12.0
 ```
 
 You will be asked several questions. If in doubt, choose the default.
@@ -95,23 +95,23 @@ Go and explore your InvenioRDM instance on:
 
 To create a new administrator account:
 
-Depending on whether you are in a local or containerized setup, take note of the variations immediately following before stepping through the subsequently outlined steps. 
+Depending on whether you are in a local or containerized setup, take note of the variations immediately following before stepping through the subsequently outlined steps.
 
 **Local application**
 
 In a local application context, precede the `invenio` commands by `pipenv run` (e.g., `pipenv run invenio users create <EMAIL> --password <PASSWORD> --active --confirm`).
 
-**Containerized application**   
-In a fully containerized context, connect to a container first e.g. the web-api container: `docker exec -it my-site-web-api-1 /bin/bash`. Then run the commands from within the container as-is. 
+**Containerized application**
+In a fully containerized context, connect to a container first e.g. the web-api container: `docker exec -it my-site-web-api-1 /bin/bash`. Then run the commands from within the container as-is.
 
 **Steps**
-The following command creates an activated and confirmed user (assuming you have email verification enabled as is the default). 
+The following command creates an activated and confirmed user (assuming you have email verification enabled as is the default).
 
 ```shell
 invenio users create <EMAIL> --password <PASSWORD> --active --confirm
 ```
 
-Then, allow the user to access the administration panel: 
+Then, allow the user to access the administration panel:
 
 ```shell
 invenio access allow administration-access user <EMAIL>