Skip to content

Urlaubsverwaltung 5.0 Migration Guide

Tobias Schneider edited this page Dec 30, 2023 · 25 revisions

Before you start

The 'Urlaubsverwaltung' needs Java 21 or later and a PostgreSQL 15.x or later

Important Announcement: MariaDB/MySQL

Urlaubsverwaltung is designed to provide our users a secure and stable platform. To guarantee this, the choice of the database is important. We decided to only support PostgresSQL in future releases starting with 5.x. Therefore we will provide a longer security support for the 4.x version, so that there will be enough time to move to PostgresSQL. See the migration guide from MariaDB to PostgreSQL. Before you migrate your data. You need to upgrade to the latest version of 4.x.

No support for Internet Explorer

We stop supporting Internet Explorer because JavaScript files are now included with type=module. Old browsers like IE11 do not support this. You can see which browsers no longer support the function at https://caniuse.com/es6-module.

Deprecation's from Urlaubsverwaltung 4.x

Classes, methods and properties that were deprecated in Urlaubsverwaltung 4.x have been removed in this release. Please ensure that you aren’t calling deprecated apis before upgrading.

  • Removed stackdriver (io.micrometer:micrometer-registry-stackdriver) dependency (#1780)
  • Removed old vacation overview api under /api/vacationoverview (#1622)
  • Removed uv.account.defaultVacationDays property. Please set this in the UI under "settings". (#2352)
  • Removed uv.workingtime.defaultWorkingDays property. Please set this in the UI under "settings". (#2348)
  • Removed to build a urlaubsverwaltung.war file. Please use the docker images or the urlaubsverwaltung.jar file. (#3549)
  • Removed LDAP and Active Directory as Security Provider (#4147)

Configuration changes

Change:

  • Default value of uv.security.auth changed from development to oidc (#1659)
  • Default value of gravatar was changed to false for new installations. (#4006)
  • Default value of months to apply vacation in advance was set to 18 months for new installations. (#3508)
  • Replaced uv.mail.sender with uv.mail.from
  • Replaced uv.mail.sender-display-name with uv.mail.from-display-name
  • Removed uv.mail.administrator and errors will now be logged instead of sending a mail with the error
  • Removed uv.security.directory-service.* that contains 'ldap' and 'active-directory'`
  • Removed uv.security.oidc.client-id
  • Removed uv.security.oidc.client-secret
  • Removed uv.security.oidc.issuer-uri
  • Removed uv.security.oidc.logout-uri
  • Removed uv.security.oidc.scopes=openid,profile,email

More information how to configure oidc the standard "spring boot way" can be found for Spring Boot oAuth2/OIDC and for the Resource Servers via JWT

API Changes

Availability API

The Urlaubsverwaltung is an absence management system. So we decided to remove the availability API, which is the opposite. If you want to calculate the availability of a person, then use the absence API and invert it e.g..

Absence API

The absence API was completely changed and returns the following information

  • absence type: provides the type of the absence e.g. VACATION, SICK_NOTE, NO_WORKDAY or PUBLIC_HOLIDAY
  • category: provides the category ,could also be seen as the absence account, the value depends on the absence type and couldbe HOLIDAY or SICK_NOTE_CHILD e.g.
  • absent: provides the length of the absence as name, e.g. FULL, MORNING, NOON
  • absenceNumeric: is numeric representation of FULL, MORNING and NOON and will be a 1 or 0,5
  • id: provides the id of the absence and is together with the absence type the identifier of this object. In the future we plan to provide links to the vacation or sick note API.
{
  "absences": [
    {
      "date": "2023-11-14",
      "absenceType": "VACATION",
      "id": 30,
      "status": "WAITING",
      "absent": "FULL",
      "absentNumeric": 1,
      "category": "OVERTIME",
      "typeId": 9954,
      "links": []
    },
    {
      "date": "2023-11-03",
      "absenceType": "VACATION",
      "id": 40,
      "status": "WAITING",
      "absent": "FULL",
      "absentNumeric": 1,
      "category": "HOLIDAY",
      "typeId": 9951,
      "links": []
    },
    {
      "date": "2023-11-02",
      "absenceType": "VACATION",
      "id": 41,
      "status": "ALLOWED",
      "absent": "FULL",
      "absentNumeric": 1,
      "category": "HOLIDAY",
      "typeId": 9951,
      "links": []
    },
    {
      "date": "2023-10-18",
      "absenceType": "SICK_NOTE",
      "id": 8,
      "status": "ACTIVE",
      "absent": "FULL",
      "absentNumeric": 1,
      "category": "SICK_NOTE",
      "typeId": 1000,
      "links": []
    },
    {
      "date": "2023-10-19",
      "absenceType": "SICK_NOTE",
      "id": 8,
      "status": "ACTIVE",
      "absent": "FULL",
      "absentNumeric": 1,
      "category": "SICK_NOTE",
      "typeId": 1000,
      "links": []
    },
    {
      "date": "2023-10-05",
      "absenceType": "SICK_NOTE",
      "id": 9,
      "status": "ACTIVE",
      "absent": "FULL",
      "absentNumeric": 1,
      "category": "SICK_NOTE_CHILD",
      "typeId": 2000,
      "links": []
    },
    {
      "date": "2023-10-06",
      "absenceType": "SICK_NOTE",
      "id": 9,
      "status": "ACTIVE",
      "absent": "FULL",
      "absentNumeric": 1,
      "category": "SICK_NOTE_CHILD",
      "typeId": 2000,
      "links": []
    },
    {
      "date": "2023-04-08",
      "absenceType": "NO_WORKDAY",
      "id": null,
      "status": "ACTIVE",
      "absent": "FULL",
      "absentNumeric": 1,
      "category": null,
      "typeId": null,
      "links": []
    },
    {
      "date": "2023-04-07",
      "absenceType": "PUBLIC_HOLIDAY",
      "id": null,
      "status": "ACTIVE",
      "absent": "FULL",
      "absentNumeric": 1,
      "category": null,
      "typeId": null,
      "links": []
    },
  ]
}

Vacation API

The vacation API has been changed to consume the "status" of an vacation.

The default is:

  • waiting
  • temporary_allowed
  • allowed
  • allowed_cancellation_requested

and also returns all active, see above, status, if not filtered, instead of only 'allowed' and 'allowed_cancellation_requested'