OpenProject Release 17.5: Project-based work package IDs

OpenProject 17.5: Wählen Sie zwischen projektbasierten oder numerischen Arbeitspaket-Kennungen

Geschätzte Lesezeit: 8 Minuten

Work packages are at the heart of project planning and collaboration in OpenProject. As organizations grow and projects become more complex, clear references and seamless collaboration become increasingly important. At the same time, organizations migrating from Jira need a reliable way to preserve established references and naming conventions when moving their projects to OpenProject.

With OpenProject 17.5, organizations can now choose between numerical and project-based work package identifiers, currently available in Beta. The release also improves Jira migrations and brings further enhancements to agile planning with Backlogs.

In diesem Artikel stellen wir die wichtigsten Änderungen vor und erläutern, was sie für Ihre tägliche Arbeit bedeuten. Wie immer finden Sie alle Änderungen, Funktionen und Fehlerbehebungen in unseren Release Notes.

Eine kurze Navigation durch den Artikel:

Your choice: project-based or numerical work package identifiers

If you worked with OpenProject at least once, you probably know that every work package has a unique identifier (ID). You encounter the ID when opening a work package URL, searching for a specific work package, mentioning it in documentation, or sharing it with colleagues.

Here’s an example of a numerical work package ID:

Screenshot of a work package with highlighted numerical ID next to the status, #683 in the example

Until now, OpenProject used a single numerical sequence across the entire instance. The first work package ever created on an OpenProject instance received the identifier #1, the second #2, and so on.

While this approach works well, the identifiers themselves provide little information about where a work package belongs. Additional context can be helpful when working across multiple projects, sharing work package references, or collaborating through external tools and integrations.

With OpenProject 17.5, organizations can now choose between the traditional numerical sequence and project-based work package identifiers.

Work package table displaying project-based work package IDs, example of OpenProject 17.5 scope on community.openproject.org

Hinweis

Project-based work package identifiers are currently available in Beta. While the feature is already supported across important areas of OpenProject, some areas may continue to display numerical identifiers until support for project-based identifiers is fully implemented. In these cases, numerical identifiers remain fully functional and continue to resolve to the same work packages. If you notice any inconsistencies or unexpected behavior, we welcome your feedback.

Easier to recognize, reference, and share work packages

Work package identifiers are used throughout OpenProject every day. They appear in links, notifications, documents, Activity discussions, filters, integrations, and more. The larger an organization grows, the more important it becomes to quickly recognize which project a work package belongs to.

Project-based work package identifiers add project context directly to the identifier. Instead of a generic numerical identifier such as #2385, teams can use semantic identifiers such as X-01, making it easier to recognize, reference, and share work packages across projects. The project-specific prefix immediately indicates which project the work package belongs to.

OpenProject administration setting to select either ‘Instance-wide numerical sequence (default)’ or ‘Project-based semantic identifiers’

Wichtig

The choice is made once for the entire OpenProject instance. This allows organizations to establish a consistent approach to work package identifiers and references across all projects and teams. We recommend informing all stakeholders before making that change. We also advise to do this during off-peak working hours.

OpenProject validates existing project identifiers and can generate compatible identifiers where necessary. Project-based work package identifiers are especially useful for organizations managing many projects or working across multiple teams. They provide immediate project context while preserving the flexibility to continue using the traditional numerical sequence if preferred. And: They also provide a foundation for preserving existing Jira issue identifiers during migrations to OpenProject.

Naturally, introducing a new identifier format raises a few questions. We’ve listed some FAQ below. For detailed information, please see our system admin guide.

Is switching to project-based IDs optional?

Ja. Organizations can continue using the traditional numerical sequence if it better fits their existing processes and workflows.

Existing numerical IDs remain valid and continue to resolve to the same work packages throughout OpenProject. Historical links, bookmarks, and references continue to work even after switching to project-based work package identifiers.

Can I switch back later?

Ja. The setting can be reverted later if needed. OpenProject also validates existing project identifiers and can generate compatible identifiers where necessary.

Why is this useful for Jira migrations?

One of the main reasons for introducing project-based work package identifiers is to support migrations from Jira. Organizations can now preserve their existing Jira issue identifiers when they migrate from Jira to OpenProject, helping teams maintain established naming conventions, references, and workflows.

Hinweis

The Jira Migrator has also been extended to support migrating due dates, estimated hours, and remaining hours. Learn more in our Jira migration documentation.

OpenProject Jira Migrator in version 17.5

More flexibility and clarity in Backlogs

Agile planning and execution continue to be major focus areas for OpenProject. Over the last releases, we have expanded Backlogs and sprint planning with dedicated sprint objects, improved backlog management, and more flexible planning workflows.

With OpenProject 17.5, teams can now further tailor Backlogs to their own processes. Administrators can exclude specific work package types from Backlogs, helping teams focus backlog refinement and sprint planning on the work that is actually relevant for agile execution.

Backlogs settings in OpenProject: Excluded work package types with example ‘Candidate interview’

Sprint views and work package cards have also been redesigned to improve visibility and provide better context during backlog refinement and sprint planning. Parent work packages, priorities, story points, assignees, and sprint status are now easier to scan, helping teams stay focused on the most important work.

Redesigned sprint view and work package cards in OpenProject Backlogs

To learn more about upcoming improvements in Backlogs and sprints, read what our CPO Rosanna Sibora wrote about the future of agile work in OpenProject. For information on the current functionalities, please see our user guide.

Other great improvements with OpenProject 17.5

OpenProject 17.5 offers more features and updates. Um diesen Artikel übersichtlich zu halten, finden Sie hier einen kurzen Überblick über einige weitere Verbesserungen, die besonders hervorzuheben sind:

More natural work package references

Work package references are now more flexible throughout OpenProject. In Documents, work package links can be inserted directly within text paragraphs, making documentation easier to read and structure. CKEditor-based text fields now also expand work package references to show additional context while editing.

More flexible recurring meetings

Recurring meetings can now be scheduled monthly based on common patterns such as the first Monday or last Friday of a month. OpenProject also reduces meeting-related email noise by consolidating multiple meeting updates into fewer emails.

OpenProject 17.5: Migration, Installation, Updates und Support

Folgen Sie der Upgrade-Anleitung für die Paket- oder Docker-Installation, um Ihre OpenProject Installation auf OpenProject 17.5 zu aktualisieren. Wir aktualisieren Ihre gehosteten OpenProject Umgebungen (Enterprise Cloud) heute, 10. Juni 2026.

Mehr Informationen über alle neuen Funktionen und Änderungen finden Sie in unseren Release Notes und in der OpenProject Dokumentation.

Falls Sie Unterstützung benötigen, stellen Sie Ihre Fragen im Community Forum. Falls Sie für den Enterprise-Support berechtigt sind, kontaktieren Sie uns und wir werden Sie gerne persönlich unterstützen.

Danksagungen

Ein besonderes Dankeschön geht an das Helmholtz-Zentrum Berlin, die Stadt Köln, die Deutsche Bahn und ZenDiS für das Sponsoring veröffentlichter oder kommender Features. Ihre Unterstützung, zusammen mit den Bemühungen unserer großartigen Community, hilft uns, solche Innovationen voranzutreiben.

Ein großes Dankeschön geht auch an unsere Community Mitglieder, die uns helfen, Fehler zu finden und zu beheben. Besonderer Dank für die Berichterstattung und das Finden von Fehlern geht an Walid Ibrahim, Billy Kenne und Agustín Dall’Alba.

Nicht zuletzt sind wir sehr dankbar für unsere sehr engagierten Übersetzer:innen auf Crowdin, die eine ganze Reihe von OpenProject-Strings übersetzt haben! Für dieses Release möchten wir insbesondere den folgenden Personen danken:

  • Đorđe Dželebdžić, für eine herausragende Anzahl von Übersetzungen ins Serbische (kyrillisch).
  • tuananhhurc, für eine große Anzahl von Übersetzungen ins Vietnamesische.

Möchten Sie selbst bei den Übersetzungen mithelfen? Then take a look at our translation guide and find out exactly how you can contribute. Wir wissen das sehr zu schätzen!

Bleiben Sie mit OpenProject in Verbindung

Bleiben Sie auf dem Laufenden über die neuesten Nachrichten, Funktionen und Produktänderungen von OpenProject. Melden Sie sich für unseren monatlichen Newsletter an, um kein Update zu verpassen.

Link in neuem Tab öffnen