Core functions: Overview

In the Core functions, administrators and system administrators define the basic settings that apply to the whole system: from language and landing pages to e-mail and files, up to the interfaces through which other systems access OpenOlat. The sections of this page follow the order of the menu. You find the menu in the system administration under:
Administration > Core functions
Profile
| Name | Core functions |
|---|---|
| Available since | Release 8.0 (2012) |
Language and region
In which language users see OpenOlat, administrators define here: the default language and the languages users can choose from. With "Import language packages" and "Export language packages" they transfer languages between OpenOlat systems. Under "Gender-sensitive language" they choose how designations of persons are written in the user interface.
In the section "Formats" administrators define the "Number format". It determines which thousands separator and decimal separator OpenOlat uses to display numbers and prices system-wide.
REST API
Other systems such as a student administration or an external course administration exchange their data with OpenOlat via the REST API (Representational State Transfer). Here administrators switch the REST API on and off, determine the externally managed objects and evaluate the logged calls in the tab "Audit log".
See the details >
To the top of the page ^
MCP server
Anyone who works with an AI client such as Claude Code accesses OpenOlat via the MCP server directly from within this client. MCP (Model Context Protocol) is the interface through which an AI client calls the MCP tools of OpenOlat. The AI client authenticates with a personal token. Every tool checks the rights of the user in OpenOlat and never gives the user more rights than the user has in OpenOlat.
The MCP server is switched off until administrators switch it on with the toggle "MCP server". The page has four tabs:
- "Configuration": switch the MCP server on and off and read the endpoint URL. In the section "Tokens" administrators define whether users may create their tokens themselves ("Self-service"), how many tokens an account may have and for how many days a token remains valid. In addition there are the sections "Request limit (rate limiting)" and "Audit log".
- "Profiles": define which MCP tools a group of users gets. A role profile applies to every user with one of its roles, a user profile applies to its members. The tools of all matching active profiles add up.
- "Tokens": all MCP tokens of all users. A token that administrators revoke here stops working within one minute.
- "Audit log": evaluate the logged calls of the MCP server.
Users with access through a profile create their tokens themselves in the Settings of the personal menu, in the tab "MCP". When the MCP server is switched on, administrators and user managers see the tokens, profiles and effective tools of a user in the user management under:
User management > "Username" > Tab "MCP"
Landing pages
So that every person starts where they work after the login, administrators preset a landing page for roles or for users with certain user attributes.
See the details >
To the top of the page ^
User tools
Which tools are available to users at all, administrators define in the list "Available tools". In the list "Preset" they choose which of these tools appear by default as an icon in the menu bar.

Calendar
If an organisation does not use the calendar, or only in some places, administrators switch it off here for the whole system or for individual places. The page "Calendar configuration" has five checkboxes:
- "Enable calendar" releases the calendar for the whole system. Only when this checkbox is set can the other four be changed.
- "Enable personal calendar" for the calendar in the personal menu
- "Enable group tool" for the calendar as a tool of a group
- "Enable course tool" for the calendar as a tool of a course
- "Enable course element" for the course element "Calendar"

WebSocket
When someone writes a message in the chat or coaches end an assessment mode, the other persons should see this at once and not only after their next click. WebSocket is a permanent connection between the browser window and the server. Through it OpenOlat tells the browser about a change, and the view updates without any action of the person. Among others, the chat, the assessment mode, tests, SCORM, BigBlueButton, Microsoft Teams and LTI benefit from it.
The toggle "WebSocket" on the page "Configuration WebSocket" switches the connection on for the whole system. By default it is switched off. If the connection cannot be established, for example because a proxy does not let it through, OpenOlat continues to work as without WebSocket: the browser asks the server at intervals and shows the change with the next request.
How OpenOlat sends e-mails and how they look, administrators define here. The page has two segments: "Settings" with the requirements for the e-mail address and the OpenOlat mailbox, and "E-mail template" with the look of the e-mails sent.
See the details >
To the top of the page ^
Files and folders
How much storage space folders may use, how OpenOlat keeps file versions and when the trash is emptied for good, administrators define here. The page has five tabs: "Overview", "Configuration", "Quotas", "Large files" and "Trash".

See the details >
To the top of the page ^
WebDAV
With WebDAV (Web-based Distributed Authoring and Versioning) users access their folders in OpenOlat from their computer. Here administrators switch WebDAV access on system-wide and define how it works.
See the details >
To the top of the page ^
Access control
Through offers, persons get access to learning resources and groups. With "Enable resource access control" administrators switch access control on for the whole system. Under "Available offer types" they choose which offer types can be selected in offers.
Statistics
If the statistics should be up to date before the next scheduled run, administrators trigger the update here themselves. The page shows whether the statistics generation is switched on and when the statistics were last updated. "Update statistics incrementally" adds the new data, "Recalculate statistics" calculates them anew from scratch.
Full-text search
So that the full-text search also finds the content of files, OpenOlat indexes them regularly. Here administrators see the status of the indexing and start or stop it with "Start indexing" and "Stop indexing". With the checkboxes "Index Excel files", "Index Powerpoint files" and "Index PDF files" they define which of these file types are included in the search.
Notifications
Anyone who has subscribed to a forum, a folder or another element receives the news by e-mail: OpenOlat sends each person one single e-mail that lists the news from all their subscriptions. Here you see when OpenOlat sends these notifications, and you can trigger a sending immediately. You find the page in the system administration under:
Administration > Core functions > Notifications

Three things control the sending:
- Schedule of the sending: The page shows whether the notifications are switched on and by which rule in cron syntax the sending runs. By default it runs every two hours, ten minutes past the full hour (00:10, 02:10, 04:10 and so on). Neither the rule nor switching on and off can be changed in the user interface. The rule is part of the server configuration and applies after a change only from the next restart of OpenOlat. frentix customers contact the frentix support for a change: support@frentix.com
- Immediate sending: The button "Trigger notifications" starts the sending immediately, without waiting for the next scheduled time. Here too, only users whose interval has expired and for whom there is news receive an e-mail.
- Interval per person: How often a person receives an e-mail at most, they set themselves in their Settings under "E-mail notification", from "Every two hours" to "Monthly". With "Never" they no longer receive notifications by e-mail. If they choose nothing, "Daily" applies. Administrators, user managers and role managers also change the interval of a person in the user management under
User management > "Username" > Tab "System settings", see Manage user settings.
The schedule only determines when OpenOlat checks, not who receives an e-mail. At each run, a person only receives an e-mail if their interval has expired since the last e-mail and there is something new in one of their subscriptions. If there is nothing new, OpenOlat sends no e-mail. Subscriptions that a person has paused are not taken into account.
The two settings complement each other, they do not override each other. Anyone who has chosen "Never" receives no e-mail, even when the sending of the instance runs. If the sending of the instance is switched off, nobody receives an e-mail, whatever interval a person has chosen. In both cases no news is lost: every person sees it themselves under Personal menu > Subscriptions > Tab "News" and via the bell icon in the respective course element.
GUI preferences
GUI preferences (Graphical User Interface) record how a person has set up the user interface. Here administrators reset them for all users. The table groups the stored entries by "Attributed class" with their "Number of entries". "Reset" deletes the entries of one row, "Bulk reset" the entries of the selected rows.
Licenses
A license shows under which conditions others may use a file, a question or a learning resource. Licenses are optional in OpenOlat. Here administrators switch them on for folders, the question bank and learning resources and manage the license types.
See the details >
To the top of the page ^
Further information
Further reading
User tools: Subscriptions >
Modules: Overview >
System >
Login: Overview >