Taskana is configured via a configuration file 'taskana.properties'
. This configuration file contains all parameters to control the behaviour of the taskana library.
General Parameter
Parameter | Description | Sample Value |
---|---|---|
taskana.domains | The comma separated list of administrative domains | DOMAIN_A, DOMAIN_B |
taskana.classification.types | The comma separated list of classification types | TASK, DOCUMENT |
taskana.classification.categories | The comma separated list of classification categories | EXTERNAL, MANUAL, AUTOMATIC, PROCESS |
taskana.user.minimalPermissionsToAssignDomains | The list of minimal Workbasket permissions of a user needed to belong to the domain. Needed to determine the domains of a user, which are aggregated in the getUser() method of the UserService. | READ, OPEN |
Security Configuration
The properties file contains the specification of the lists of access ids (i.e. users or groups) that belong to the roles user, business_admin or admin.
The keywords to specify these roles are as follows:
Role | Keyword |
---|---|
user | taskana.roles.user |
business_admin | taskana.roles.businessadmin |
task_admin | taskana.roles.taskadmin |
admin | taskana.roles.admin |
Each entry may contain a list of access ids that are separated by the '|' character. Whitespace at the begin or end of each access id is ignored. This is, as sample config may look like
...
By adding the property taskana.german.holidays.enabled to the taskana property file the german holidays can be activated.
Additionnally Additionally the holiday corpus christi can be enabled using the following property: taskana.german.holidays.corpus-christi.enabled
...
If the format for a single custom holiday is not in that format, then this custom holiday will be ignored and a warning will be logged with the ignored custom holiday.
Working time configuration
Via the property taskana.workingtime.schedule you are able to specify the schedule of your working time.
Info |
---|
If there is no such property, the default value of Taskana takes care that working day calculation happens as before (assuming your Timezone is Europe/Berlin). This means there is no reconfiguration of Service Levels and similar things necessary. |
You can have multiple working slots per day separated by
|
The precision is up to you. You can theoretically specify nanoseconds if you want to. But typically minutes is the highest precision you will need. The full format is documented by LocalTime of the Java SDK
Values after
taskana.workingtime.schedule.
and up to=
must be one of Monday, Tuesday, Wednesday, Thursday, Friday, Saturday or Sunday. Those values can be written in any case you prefer.
Code Block |
---|
taskana.workingtime.schedule.MONDAY=07:00-12:00|13:00-18:00
taskana.workingtime.schedule.tuesday=08:00-13:00|14:00-19:31
taskana.workingtime.schedule.weDneSDaY=06:30-12:30 |
Time zone
Via the property taskana.workingtime.timezone you specify the time zone that is used in to calculate working time. The format of the possible values is documented by ZoneId of the Java SDK. We generally recommend to use region Ids.
The default value is Europe/Berlin
.
Code Block |
---|
taskana.workingtime.timezone=America/Phoenix |
History deletion upon task deletion
...
Code Block |
---|
taskana.routing.dmn=/dmn-routing.dmn |
Validation of timestamps
...
with a service level mismatch
The taskana.validation.allowTimestampInThePastallowTimestampWithServiceLevelMismatch
allows the user to create and update tasks with timestamps in the pastthat do not match i.e. exceed the service level of the classification. If the property is set to true
, the planned and due timestamp of a Task can be set to a past point points in time, which are further apart than the service level of the classification would normally allow.
Additional User Info
If you are using the USER_INFO table you can add the Full/Long name when retrieveing Tasks/TaskComments/TaskHistoryEvents with the property taskana.addAdditionalUserInfo