Invenio-Config-TUW
Invenio package for tweaking InvenioRDM to the needs of TU Wien.
The following list is a quick overview of the most relevant customizations happening in this package:
TUW-centric default configuration values
Tightened permission policies
Mandatory submission reviews (via Invenio-Curations)
Extensions for record types and services
Customized OIDC authentication handling
Several e-mail/notification tweaks
Extension of user profiles
Custom background tasks
Integration with other TU Wien services
Details
Configuration values
The primary purpose of this Invenio package is to provide some baseline configuration for InvenioRDM to suit deployment at TU Wien. These updated configurations include (but are not limited to) setting default values for record metadata and enabling access requests for restricted records per default.
Permission policies
InvenioRDM is not just some sort of cheap storage platform where users can upload their data and update it at any time. Instead, it is a platform intended to host digital objects that get DOIs assigned. Since the idea behind DOIs (and persistent identifiers in general) is to point at the same content over time, it does not allow users to change the files after publication.
This is one of the unique features that the system offers that may not be immediately obvious to users. To make sure that users understand the implications of using the system, we require a brief communication between the users and operators.
In contrast to vanilla InvenioRDM, having an account is not enough to create uploads in our system. Instead, the creation of records requires the trusted-user role, which is given out automatically to TU Wien employees and needs to be requested by other users.
Also, communities can be quite confusing in the beginning. Thus, we restrict the creation of new communities to administrators.
Mandatory submission reviews
Before any upload can be published, it needs to undergo a mandatory submission review. This enhances the quality, reusability, and long-term preservation of uploaded content.
Previously, this was implemented via customized permission policies and required communication via external channels. As of v2025.1.0, the workflow is based on Invenio-Curations. This allows the entire workflow to be handled through the system, and allows the system to act as a ticketing system for reviews.
OIDC authentication handling
We do not want to handle certain aspects like password management of user management in our system. Instead, we offload authentication to a separate service, with which InvenioRDM communicates via OIDC. Sometimes we have slightly non-standard requirements, which are satisfied by the authentication handler logic in this package.
Extended record classes
We provide customized subclasses for records and drafts. They have additional “systemfields” that make it easier for developers to fetch the requests that are related to a record/draft. Also, they have a hook that supports setting an alterantive file storage location if the record was created from a specific IP address.
Additionally, we also provide a record extension that trigger the reindexing of all related requests on record.commit(). This keeps the requests up to speed with any changes to the record (e.g. visibility updates when permissions for the record are shared).
Extended service layer components
We add several record service components that…
Set some default values for new records and new versions (access settings and metadata)
Send notification emails to uploaders when their records have been initially published
Send notification emails to uploaders when metadata edits for their records get published by somebody else
Ensure that source URLs for images embedded in the description stay valid on publication
Also, we add a request service component that notifies users when they have been added as reviewer to a request (cf. the v13.1 request reviewers feature).
E-Mail notification on backend errors
This package defines a custom log handler for error-level logs which sends out notifications as e-mail to a set of configured recipient addresses (typically admins).
Conversely, we also override the Flask-Mail extension to temporarily store information about failed dispatch of emails, to assist in troubleshooting.
Generalized notification builders
We provide generalized notification types (“builders”) for users and groups that can be used to send arbitrary notification messages that are not tied to any kind of request. They are used in the “outreach email” feature that can be used by admins to send out news to (a selectable subset of) all users in the system.
Customized notification backends
To make setting automatic email handling rules simple, we set the X-Sender email header field to a configurable value.
User profile extension
By default, authentication in our system is tied to an institutional account (e.g. via eduGAIN), which becomes unavailable when the affiliation ends. This means that users may not be able to log in and manage their records and requests anymore at some point.
We provide a “secondary email address” to include in notification emails, so that users at least get notified about relevant events (e.g. access requests). This way, they can contact a colleague with sufficient permissions to handle the event for them.
“Quick login” panel for Flask-DebugToolbar
Authentication setups can be quite involved with OIDC or SAML, and especially if MFA is involved. It can be quite painful for developers to set everything up correctly, and jump through all the hoops of authentication each time they want to test something locally.
To alleviate some of these pain points, we’ve added a new Flask-DebugToolbar panel that enables quickly switching to another user in the current session.
Integration with other TU Wien services
One of the benefits of hosting InvenioRDM as an institutional repository is that it enables some conveniences by integrating with the local environment more. For example, we integrate with TISS by periodically querying it for TU Wien employees and adding their names to the controlled vocabulary of known names.
Custom background tasks
To make the continued operation of the system smoother, this package also provides some background tasks:
Reminder notifications to reviewers about open submission reviews
Reminder notifications to users about accepted submissions
Periodic updates of the names vocabulary via TISS
1 maintainer
Release files for Invenio-Config-TUW 2026.1.6
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| invenio_config_tuw-2026.1.6.tar.gz | 87.6 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| invenio_config_tuw-2026.1.6-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 174.8 kB
Release files / invenio_config_tuw-2026.1.6.tar.gz
| Download URL | invenio_config_tuw-2026.1.6.tar.gz |
|---|---|
| Size | 87.6 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
c6697dc1b2d143eb9753bbc19ffbe41d13452f87407f36f2ae7ad669225dd2da
|
|
BLAKE2b-256 checksum How to use checksums |
a97f3082f5d97fe7fdb3cff031f607918e371a9ec5c5ca13e38078bfe6b247a0
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.0
|
Release files / invenio_config_tuw-2026.1.6-py3-none-any.whl
| Download URL | invenio_config_tuw-2026.1.6-py3-none-any.whl |
|---|---|
| Size | 87.2 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
da7330ee4cbfb4c269e87862e01312c29f5af01f627e6e57ab6cf43c990f59eb
|
|
BLAKE2b-256 checksum How to use checksums |
1e4775621323ed79f854b04915aad0fb600d246186cde4f94a33834a12e63547
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.0
|
