Added

• CVE-Radar (plugin, not active by default): first part with real data
  • Cases: vulnerabilities and incidents without CVE with measures, fix criteria and a closure overview telling whether a case can be closed.
  • Team checks: groups answer whether their projects or systems are affected.
  • Import of the versions and check results of a client agent from a log server (Graylog), configurable.
  • My CVE-Radar: employees confirm the measures and see their own devices.
• CVE-Radar: vulnerabilities from the NVD
  • Import of the vulnerabilities (CVEs) from the National Vulnerability Database on schedule and in the job monitor, incrementally and from a configurable CVSS score on; off by default.
  • The start page of the CVE-Radar lists the imported vulnerabilities with score, severity, weaknesses and dates; the prototype with test data moved to a demo page linked from there.
  • The tab "Statistics" of the CVE-Radar shows the reported cases and the vulnerabilities published by the NVD per day, week or month.
• Data transfer (also public): the upload shows its current speed in kB/s or MB/s.
• CVE-Radar: inventory of systems
  • Systems as a tree: areas of any depth, below them systems with instances (installations), components and technologies. Everybody creates areas for a group of their own; the groups of an area and the areas above it see and change what is below, the security team reads internal systems.
  • Areas and systems can be moved; the security officer moves an area below another one, e.g. below a customer.
  • Technology catalogue: ecosystems, products and frameworks, and libraries as a tree (a library may belong to several frameworks). The security team maintains it, the technologies of a component are picked from it.
  • Libraries of a component from lists: SBOMs (CycloneDX or SPDX as JSON, all ecosystems and operating system packages by their package URL), the lockfiles of npm, yarn, Composer, Go, Cargo and the pinned requirements of Python, package lists of Debian, Alpine and RPM systems, the output of Maven or Gradle, or the file names of a jar, several files merged, including the transitive dependencies; a list with a search field shows them. The preview before applying shows what is new, removed or changed in its version. The dialog shows which file or command to take.
• CVE-Radar: file of a CVE with ratings, measures and discussion
  • A row of the vulnerability list opens the file of the CVE: NVD data with the remediation hints apart from the other references, the ratings of the security team members side by side, the binding priority with a reason, the measures for techies and non-techies, fix version, workaround and references.
  • Take over, assign, status and a suggested priority from the CVSS score and the CISA KEV catalogue; a change over a newer version of the case is refused.
  • Discussion of a case in the chat for all readers; every team check has a file of its own with a discussion that only the asked group and the security team see.
  • The roles of the CVE-Radar (readers, security team, security officers) are PF groups named in the settings readGroup, writeGroup and securityOfficerGroup.
• Digital business cards
  • Several cards per user, each with a QR code (vCard) to show, e.g. as a screenshot. Reached from the user menu and the address list.
  • The data is taken over from an address of the address book (the own one is suggested), picked per field and editable; private data only if ticked.
  • The photo of the own address can be linked in the vCard: the gateway delivers it under a signed url and needs no further data for it.
• Order notifications (a button on the order list and beside the e-mail checkbox of each order): choose per user whether the e-mails about changed orders arrive at once, as one daily summary or not at all, as a default and as exceptions for single projects or customers.
• CVE-Radar: vulnerabilities matched against the inventory
  • Every imported vulnerability is matched against the technologies of the inventory, after each import and each change of the inventory or of the catalogue: by the CPE or the catalogue entry of a technology, otherwise by its name (then only "possibly affected"), with the version ranges of the NVD. A component of a system counts for every instance of it.
  • The findings show in the file of a CVE (tab "Affected"), as a count with a filter "With matches in the inventory" in the list of vulnerabilities and in the inventory tree, where affected rows are highlighted. Installations a person may not see are only counted. The security team discards false positives with a reason; a discarded finding stays discarded, even after a version was changed and reverted.
  • The inventory tree shows when the technologies of a component were last updated.
  • Discussions about a CVE take attachments, which are deleted after 30 days; the notice about confidential details shows in orange while writing.
  • New notification rule type "New findings of the CVE radar": the responsible team of an affected system (the group of the system or of the nearest area above) is notified, the recipients of the rule in copy, right after the matching found something new. A rule starts from a CVSS severity (known exploited vulnerabilities always), optionally with possible findings and vulnerabilities not yet rated. Each notification names only the systems visible to its recipient and every finding once; the text has variables for the vulnerabilities, the systems, the highest severity and a link.

Improved

• Tables no longer store their unchanged column layout again on every page view.
• Fewer requests per page view: the unread chat count of the top bar comes with the user status instead of two list requests, it is counted once for menu and status, and the event stream stops retrying after the session expired.
• Order statistics, forecast: new table "Breakdown of the forecast" per month with the invoiced sums, the remaining forecast of commissioned fixed price and flat rate positions, of commissioned time & materials positions (run rate) and of not yet commissioned positions (weighted), and the part of the forecast for which an invoice is already planned.
• Chat: the images of a message stand side by side (scrolling sideways when there are many), and the full size view pages through them with buttons and arrow keys.
• Dialogs with input fields ask before they are closed by a click beside them, Esc or the close button once something was entered, so the input is no longer lost by accident.
• Properties editor: the descriptions link to the matching sections of the admin guide and support code, bold text and links.

Changed

• Java 21 is required from version 9.2 on: ProjectForge is compiled for Java 21, the executable JAR no longer starts on Java 17. The Docker image already contains Java 21.
• Contribution margin: the preliminary revenue of unbooked outgoing invoices is taken from the cost assignments of the invoice positions (kost2 → project) if they are completely defined; otherwise from the project of the invoice as before.
• Files: the JCR (Apache Oak) is removed, all files are stored by the file store (attachments in the database, data transfer files in the file system). An installation still using the JCR has to migrate with 9.1.x first: ProjectForge refuses to start, if the JCR contains files, which weren't migrated. The JCR backup and the migration were removed from the system page, projectforge.jcr.maxDefaultFileSize is now projectforge.files.maxDefaultFileSize (the old key is still read, with a warning on start until it is renamed; obsolete JCR properties are reported too).
• Projects: the status is one of acquisition, active, paused and ended (or not set). Existing projects were mapped: build phase, productive and maintenance became active, on hold became paused. The history still shows the former values.
• The system configuration page now offers the projectforge.properties editor and the comparison with its backups for administrators, as the System page does.
• User menu: "Customize my menu" comes before "My account".

Fixed

• Invoice lists: an invoice that was marked as paid could stay in the filter "unpaid" (and in its sums) after a mass update, even after the caches were refreshed.
• Notification rules: a recipient gets at most one mail and one SMS per rule and day, even if a rule created several notifications. The next day, it reminds again. Tests are not limited.
• Long lists (orders, invoices, time sheets, accounting records, vulnerabilities): a search could show an outdated, e.g. empty, result after changes made at the same time or directly in the database. Reloading the page now always shows the current result.