v6.2.1 - Configuration to enable working day calculation

Restore the old behaviour to calculate the planed and due date based on day and not based on milliseconds

To enable WorkingDayCalculatorImpl instead of WorkingTimeCalculatorImpl:

taskana.workingTime.useWorkingTimeCalculation=false # default value is true
taskana.workingTime.timezone=<YOUR TIMEZONE>

Bugfix in ServiceLevelHandler to recalculate the due date when the classification key has changed.

What's Changed

• Configuration to enable working day calculation instead of working time calculation by @arolfes in #2352

Full Changelog: v6.2.0...v6.2.1

v6.1.1 - Configuration to enable working day calculation

Restore the old behaviour to calculate the planed and due date based on day and not based on milliseconds

To enable WorkingDayCalculatorImpl instead of WorkingTimeCalculatorImpl:

taskana.workingTime.useWorkingTimeCalculation=false # default value is true
taskana.workingTime.timezone=<YOUR TIMEZONE>

Bugfix in ServiceLevelHandler to recalculate the due date when the classification key has changed.

What's Changed

• Configuration to enable working day calculation instead of working time calculation by @arolfes in #2351

Full Changelog: v6.1.0...v6.1.1

v6.0.3 - Configuration to enable working day calculation

Restore the old behaviour to calculate the planed and due date based on day and not based on milliseconds

To enable WorkingDayCalculatorImpl instead of WorkingTimeCalculatorImpl:

taskana.workingTime.useWorkingTimeCalculation=false # default value is true
taskana.workingTime.timezone=<YOUR TIMEZONE>

Bugfix in ServiceLevelHandler to recalculate the due date when the classification key has changed.

What's Changed

• Configuration to enable working day calculation instead of working time calculation by @mustaphazorgati in #2342

Full Changelog: v6.0.2...v6.0.3

v6.3.0

Database Schema Update

• This release requires an update to the TASKANA database schema.

New

• #2242 - In order to have more flexibility and expressiveness in the workbasket permissions, two new permissiones have been introduced:
  ** READTASKS: the visibility of tasks is no longer attached to the READ permission of the workbasket. Instead there is a the READTASKS permission, which grants the right to view a task.
  ** EDITTASKS: in addition to READTASKS, EDITTASKS allows the editing of tasks in a workbasket. This allows the distinction between auditing (read-only) and working access.

IMPORTANT: to be compatible with earlier versions, this new permissions are granted to everyone who had READ permission so far.

Improvements

• Column 'AccessID' is now dynamically resizable in the Workbasket Access Items view

Complete list of features and fixes

• #2292 - removed erroneous read-only annotation from TaskCommentController

• #2246 - add grouping by sors and pors

• #2259 - Refactor UpdateTaskAccTest to use test-api

• Flaky Test in CreateTaskAccTest fixed

• #2334 - Make column width of AccessID dynamic under Workbasket Access Overview

• #2306 - extend Admin-UI by permissions READTASKS and EDITTASKS (#2318)

• #2295 - implement EDITTASKS Permission

• #2269 - Implement READTASKS Permission

• #2286 - adjust REST with READTASKS and EDITTASKS

• #2283 - Extend models and data for READTASKS AND EDITTASKS

• #2273 - write update scripts for adding EDITTASKS

• #2240 - write update scripts for adding READTASKS

• #2328 - fix smoketest by waiting for demployment

• #2326 - fixed documentation smoketest (azure)

• #2310 - Default TimeIntervalColumnHeader Ranges are incorrect

• #2322 - set ownerLongName to null during cancelClaim

• #2316 - refactor DmnTaskRouterAccTest to use test-api

• #2299 - remove lock from the query when unnecessary

• #2296 - add ownerLongName during update

• #2262 - Fixed Flaky Test in CreateTaskAccTest

• #2262 - Refactor GetWorkbasketAccTest to use test-api

• Bump json from 20230227 to 20230618

• Bump version.spring.boot from 2.7.13 to 2.7.14

• Bump word-wrap from 1.2.3 to 1.2.4 in /web

• Bump equalsverifier from 3.14.3 to 3.15

• Bump semver from 5.7.1 to 5.7.2 in /web

• Bump version.testcontainers from 1.18.2 to 1.18.3

• Bump version.spring.boot from 2.7.12 to 2.7.13

• Bump equalsverifier from 3.14.1 to 3.14.3

• Bump checkstyle from 10.12.0 to 10.12.1

• Bump actions/setup-node from 3.6.0 to 3.7.0

v6.2.0 - Query results grouping by por and sor

New

• #2246 add grouping by sors and pors
  It is now possible to group query results by key and value of the primary and the secondary object references.
• #2187 - Add additional user configuration in wildfly
  The wildfly example now includes sample code how a userid can be passed into the REST API and set as the security context for further processing

Improvements

• #2227 - Category of classifications should have the same order as in taskana.properties
  TASKANA retains the order of the categories in the UI as they are configured in the properties file.

Complete list of features and fixes

• #2292 - removed erroneous read-only annotation from TaskCommentController

• #2246 - add grouping by sors and pors

• #2259 - Refactor UpdateTaskAccTest to use test-api

• Flaky Test in CreateTaskAccTest fixed

• #2256 - Refactor SetOwnerAccTest to use test-api

• #2187 - Add additional user configuration in wildfly

• #2271 - fix hooks for github

• #2270 - add login to Microsoft Azure

• #2270 - add deployment to Microsoft Azure

• #2171 - Refactor toLowerCopy

• #2250 - Refactor TerminateTaskAccTest to use test-api

• #2249 - Refactor CancelTaskAccTest to use test-api

• #2235 - Refactor GetTaskAccTest to use test-api

• #2232 - Refactor DeleteTaskAccTest to use test-api

• #2229 - load correct constructor to init TaskanaJob

• #2222 - refactor TaskCleanupJobAccTest to use new TestApi

• #2205 - Refactor CreateTaskAccTest to use test-api

• #2227 - Category of classifications should have the same order as in taskana.properties

• Bump maven-surefire-plugin from 3.1.0 to 3.1.2

• Bump version.testcontainers from 1.18.1 to 1.18.2

• Bump maven-checkstyle-plugin from 3.2.2 to 3.3.0

• Bump maven-dependency-plugin from 3.5.0 to 3.6.0

• Bump checkstyle from 10.11.0 to 10.12.0

• Bump asciidoctor-maven-plugin from 2.2.3 to 2.2.4

• Bump mybatis-spring from 2.1.0 to 2.1.1

• Bump maven-source-plugin from 3.2.1 to 3.3.0

• Bump version.testcontainers from 1.18.0 to 1.18.1

• Bump version.spring.boot from 2.7.11 to 2.7.12

• Bump checkstyle from 10.10.0 to 10.11.0

• Bump maven-surefire-plugin from 3.0.0 to 3.1.0

• Bump checkstyle from 10.9.3 to 10.10.0

• Bump jacoco-maven-plugin from 0.8.9 to 0.8.10

• Bump maven-checkstyle-plugin from 3.2.1 to 3.2.2

• Bump version.spring.boot from 2.7.10 to 2.7.11

• Bump version.camunda.dmn from 7.18.0 to 7.19.0

v6.1.0

• #2185 - Upgrade Postgres to 14.7

• #2162 - forceCancelClaim does not throw InvalidOwnerException

• #2202 - Refactor ClaimTaskAccTest to use test-api

• #2184 - fix setting ownerLongName during claim

• #2201 - add master domain always to configured domains

• #2219 - fixes SpringBoot CORS Configuration to run example App locally

• Bump version.spring.boot from 2.7.9 to 2.7.10 #2194

• Bump checkstyle from 10.9.2 to 10.9.3 #2198

• Bump maven-resources-plugin from 3.3.0 to 3.3.1 #2199

• Bump version.testcontainers from 1.17.6 to 1.18.0 #2212

• Bump ojdbc8 from 21.9.0.0 to 23.2.0.0 #2217

v6.0.2 - Bugfix release for TaskanaAdapter

Unfortunately we removed taskana-test dependencies from release v6.0.0 . These dependency is needed for TaskanaAdapter. There we create a new release with the test dependency.

v6.0.1 - Fixed initalization of PriorityServiceProviders

Extract from the v6.0.0 Release Notes:

To acess the WorkingTimeCalculator in the PriorityServiceProvider we have created a new default method PriorityServiceProvider#initialize(TaskanaEngine)

In v6.0.0 PriorityServiceProvider#initialize(TaskanaEngine) was not called by the PriorityServiceManager thus the Service Provider never received an instance of a TaskanaEngine. This has been fixed.

What's Changed

• #2181: init PriorityServiceProviders during TaskanaEngine init by @mustaphazorgati in #2182

Full Changelog: v6.0.0...v6.0.1

v6.0.0 - Improve precision for Service Level

We are happy to announce our new major TASKANA release. This release contains crucial changes regarding Classification.serviceLevel, the configuration of TASKANA and its job execution. Since these are significant changes we deviate from the regular release notes in order to provide you with more details and a guideline on how to migrate to the new version.
If anything is unclear or if you need assistance during the upgrade, please reach out to us (e.g. via GitHub discussions).

Overview

• The modules taskana-common-data and taskana-common-test are no longer released. They are internal test modules which should never have been released.
• Overhaul of TaskanaEngineConfiguration
  • its new name is TaskanaConfiguration.
  • it is immutable. Therefore, a builder class will be provided to configure it.
  • the provided builder class now fully supports the java API and configuration via property file (or mixed). Because of that the usage of a properties file is now optional.
  • initialization of the TaskanaEngine has been moved to TaskanaEngine#buildTaskanaEngine(...).
  • Instead of writing error messages TASKANA will now interrupt the startup (via RuntimeException) if any error was detected (e.g. value for specific property does not match).
• Minor rework of Exceptions. Some have been removed, some have been renamed, some have been modified.
• Increased precision of service level to milliseconds
  • The WorkingTimeCalculator class is replaced by an interface. An instance can be retrieved from the TaskanaEngine.
  • To acess the WorkingTimeCalculator in the PriorityServiceProvider we have created a new default method PriorityServiceProvider#initialize(TaskanaEngine)
  • The DaysToWorkingDaysConverter is removed. It's method are now part of the WorkingTimeCalculator.
  • The old algorithm for the WorkingTimeCalculator is replaced by a better, more compatible algorithm. This new algorithm works with completely new global configuration properties regarding the working time. This allows a user-friendly usage of the newly created precision.
    In order to fully embrace this feature, we are currently thinking about expanding the configuration properties to e.g. allow a working time configuration per Workbasket. As of right now this is just an idea, but the WorkingTimeCalculator is prepared to receive its configuration from somewhere else.
• Scheduling of TASKANA jobs is now part of taskana-core. Previously we have provided a JobScheduler-Example which shows how to schedule TASKANA jobs. That class is not necessary anymore. Instead the scheduling of jobs is now part of the TASKANA configuration (with new properties)
• TaskService#selectAndClaim(TaskQuery) now return Optional<Task> instead of Task. Previously an Exception was thrown when the given TaskQuery returned 0 Tasks. That Exception is replaced with the new return type.

Details / Migration Guide

Let's have a look at the details of this release and work through them step-by-step.

Removal of taskana-common-data and taskana-common-test from the release artifacts

These modules will no longer be released. If for some reason you have used them in the past reach out to us; we will find a solution. If not, you have nothing to do here.

Overhaul of TaskanaEngineConfiguration

The TaskanaEngineConfiguration is the entry point to the TASKANA library. Therefore, we should start migrating here.

1. Replace all usages of TaskanaEngineConfiguration with TaskanaConfiguration (its new name).

2. Replace the initalization with the new builder class TaskanaConfiguration.Builder. That builder has 4 required configuration parameters which have to be passed as constructor parameters: DataSource dataSource, boolean useManagedTransactions, String schemaName, boolean securityEnabled. All other parameters are optional (and have a default value). They can be configured through their corresponding builder methods. Please have a look at TaskanaConfiguration.Builder for their default values. Furthermore this builder has some copy constructors if you want to modify some values of an existing TaskanaConfiguration.

3. Here is a table of all changes to the TASKANA properties. If you want to keep using a properties file, please adjust your properties file according to this table. To include the TASKANA properties file you have to call TaskanaConfiguration.Builder#initTaskanaProperties(String propertiesFile, String separator). This will parse all properties within that file and set them accordingly.
   WARNING: Since initTaskanaProperties is a builder function you can override previously set values through this method. Builder methods after this will also override the values of the TASKANA properties. We think this is intuitive, just wanted to give you a heads up.
   INFO: This table already contains new properties and describes their data types. They will be referenced later in the migration guide.
   INFO: Unfortunately this table is wide and you have to scroll vertically. Alternatively you can install wide-github so that you don't have to scroll vertically anymore.

   Change	Old Name	New Name	Comment
   UNCHANGED	taskana.domains	taskana.domains
   RENAMED	taskana.validation.allowTimestampServiceLevelMismatch	taskana.servicelevel.validation.enforce	The new property is inversed.
   UNCHANGED	taskana.roles.user	taskana.roles.user
   RENAMED	taskana.roles.businessadmin	taskana.roles.business_admin
   UNCHANGED	taskana.roles.admin	taskana.roles.admin
   UNCHANGED	taskana.roles.monitor	taskana.roles.monitor
   RENAMED	taskana.roles.taskadmin	taskana.roles.task_admin
   RENAMED	taskana.roles.taskrouter	taskana.roles.task_router
   UNCHANGED	taskana.classification.types	taskana.classification.types
   UNCHANGED	taskana.classification.categories.<TYPE>	taskana.classification.categories.<TYPE>	<TYPE> = value from taskana.classification.types
   NEW		taskana.workingTime.schedule.<DayOfWeek>	<DayOfWeek> = one of: [ MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY]
   NEW		taskana.workingTime.timezone	Value is parsed via java.time.ZoneId#of(String zoneId)
   RENAMED	taskana.custom.holidays	taskana.workingTime.holidays.custom
   RENAMED	taskana.german.holidays.enabled	taskana.workingTime.holidays.german.enabled
   RENAMED	taskana.german.holidays.corpus-christi.enabled	taskana.workingTime.holidays.german.corpus-christi.enabled
   RENAMED	taskana.history.deletion.on.task.deletion.enabled	taskana.history.simple.deleteOnTaskDeletion.enabled
   RENAMED	taskana.historylogger.name	taskana.history.logger.name
   NEW		taska...

Oracle support

New

• TSK-1971: Added support for Oracle database

Improvements

• TSK-1699: comma values in any REST queryparameter are not split anymore.
  Example: /api/v1/tasks/name=foo,bar will result in a search for [“foo,bar”] and NOT for [“foo”, “bar”] anymore.
  This is now in line with our REST documentation “Whenever a parameter is an array type, several values can be passed by declaring that parameter multiple times.”. So a search for [“foo”, “bar”] should look like this: /api/v1/tasks/name=foo&name=bar
• TSK-1946: updated spring-boot dependency to 2.7.8
• TSK-1975: added database indices for secondary Object References.
  A schema update is required for this change. Please choose the correct update file (schema update v5.2.0 -> v5.10.0) from here: https://github.com/Taskana/taskana/tree/master/common/taskana-common/src/main/resources/sql

Complete list of features and fixes

• TSK-1699: AccessItems for groups are not returned from REST API
• TSK-1828: Remove resteasy-client dependency
• TSK-1866: Refactor UpdateClassificationAccTest to use Test-API
• TSK-1922: Disable cyclic dependency architecture tests
• TSK-1946: Update spring-boot to 2.7.X
• TSK-1971: Add support for Oracle database
• TSK-1975: Database Index for OBJECT_REFERENCE table
• TSK-1976: OwnerLongName isn't set during Task creation
• TSK-1977: forceClaim doesn't change the ownerLongName
• TSK-1980: Bump maven-surefire-plugin from 3.0.0-M5 to 3.0.0-M8
• TSK-1981: Fix Code Smells to fix pipeline.