Changelog 10.0

Users can be excluded from participating in a process activity

As a modeler of a workflow model, I would like to be able to configure which users, groups and roles are excluded from participation in an activity, in order to implement business processes that have such requirements (for instance, processes where it has to be ensured that two different persons have to perform a certain action).

Acceptance criteria:

• BPM-Scripting allows management (creating, changing) of a list of users that are excluded from participating in an activity

• The exclude list may contain users, groups and roles

• The exclude list applies only to the activity for which it was defined

• Users, groups and roles that are in exclude-list cannot participate in the activity, even if

  • they are in the list of performers of the activity

  • they are substitutes of performers

Exclusions-configuration of a process activity is visible in REST-API

As an API user, I would like to know who was excluded from participation in an activity, in order to know why they did not receive a task resulting from that activity.

Acceptance criteria:

• The existing endpoint /bpm/process/{processId}/activity/{activityId}/inboxitem is extended to also contain the users, groups and roles that were excluded from participation in a workitem

  • The endpoint already contains "perfomer"

  • This part of the response is extended to "exclusions" (resulting in performer.exclusions, same structure as in the scripting API)

  • performer and performer.exclusions contain the organisation members as configured (i.e., the groups and roles are not expanded)

Remove deprecated script API method "createEntry" in "History" class

BPM-Scripting API call "$.history.createEntry" was deprecated by a new method "$.history.addEntry".
The new method is available since version 8 LTS. Thus, the deprecated method may be removed with version 10.0.

Read-only fields in scripting-API behave as such

As a modeler that writes scripts for process models, I would like to get clearer feedback from scripting-API which properties can be changed, and which are read-only, without having to check documentation for each field. Currently, the changes of all properties are possible in script, but the changes of the read-only properties are not persisted.

Acceptance criteria:

• All read-only properties in BPM Scripting-API are covered with the change

• If script attempts to write data in a read-only field, an exception is thrown

HttpRequest object has a timeout property

As a model developer, I would like to set the timeout for an HTTP call by setting the timeout property of the HttpRequest object to the appropriate value.

Acceptance criteria:

• Timeout (in miliseconds) can be set on a HttpRequest 

• If timeout is not set, the default value from server settings is used (com.os.ecm.messaging.LocalSidecarPreferences.SocketTimeout)

• The timeout of a HttpRequest can be set to larger value than the timeout of the server, but then the timeout of the server will be trigger first

New objecttype right 'Share' provides control over who can share documents in a system

As a project modeler, I would like to control who can share an object type, in order to have better control over document access in a system. Currently, sharing right is bound to edit-right, thus everyone who can edit a document can also share it with other users.

Acceptance criteria:

• A new object type right "share" is provided in role management

• It is possible to set clauses on the right 

• The existing setting on object type "sharing allowed" remains (this decides if sharing of type is allowed at all - if sharing of objecttype is not allowed, it does not matter what rights/roles define)

• Core service allows/forbids document sharing based on the object type and rights settings

Additional icons are available for document and folder types

As a modeler, I would like to have more icons available for object types in a yuuvis RAD system, in order that users can better distinguish between them and associate them more easily with the designed purpose of an object type.

Acceptance criteria:

• Documents and folder get icons that depicts general purpose document/folder, but so that the whole english alphabet is covered (currently, only P, W, X are available for documents / C, M, P, V for folders)

• Two types of icons from https://pictogrammers.com/library/mdi/category/alpha-numeric/   are added so that modeler has more visual options (for instance one type for folders and other for documents)

  • Circle (filled circle version)

  • Box-outline (box around a letter)

• The icons are added to a separate group in the dialog that provides icon configuration in the designer

It can be seen in which processes an object is being used

As a user, I want to see whether an object is used in an active process, in order to understand better the state of the object and processes relevant for it. 

Acceptance criteria:

• The existing endpoint in bpm-service for querying of processes is extended to accept objectId as an optional query parameter 

  • The query can be combined with existing filtering options (such as running, finished, suspended, etc. )

  • A process administrator can query and filter all processes 

  • A user can query and filter only his/her processes

  • The endpoint returns the same process metadata as before

• The query works as follows :

  • Only direct references are shown. For instance

    • if a folder F is referenced by a process P, and processes are queried whether F is used in a process, then the endpoint will return P.

    • but if a document D from a folder F is used in a process P, and processes are queried whether D is used in a process, then the endpoint will not return P.

Names of deadlines and delays can be localized

As a workflow user, I would like to have better understanding of process history when the process contains deadlines and delays. Currently, the history entries are technical and not translated into my language.

Acceptance criteria:

• Name of a delay/deadline can be localized in schema

Localized names of deadlines and delays are provided in task history

As a workflow user, I would like to have better understanding of process history when the process contains deadlines and delays. Currently, the history entries are technical and not translated into my language.

Acceptance criteria:

• Task-history endpoint is extended to provide localized values for deadlines and delays

Username of users that cannot be deleted is changed to unique value

As a system administrator, I would like to be able to reuse usernames that are no longer in active use, in order to be able to synchronize system with external identity providers.

Currently, if a user has made changes on a document, it cannot be completely removed from a yuuvis RAD system (to preserve history of changes on objects). So, if a user X is active in system, leaves company and is deleted from company's identity provider, the username X becomes available in the identity provider system. Administrator can assign it to a new user, but then the synchronization with yuuvis RAD fails, since username is occupied and cannot be reused.

Acceptance criteria:

• If a user cannot be deleted from a yuuvis RAD system, its username is changed to a unique value: username_ID

• This applies both to users deleted via LDAP-Sync operation and those deleted in management studio

The form editor shows technical names of fields and datafields

As a system modeler, I would like to see technical names of fields in form editor instead of neutral names, in order to be able to track fields over multiple user interface views more easily. For instance, in object-field overview, the technical names are shown. 

Acceptance criteria:

• Technical names are shown in form editor instead of neutral names, both for object- and process-forms

Users that are excluded from participating in a process activity are listed in API

As an API user, I would like to know who was excluded from participation in an activity, in order to know why they did not receive a task resulting from that activity.

Acceptance criteria:

• Endpoint /bpm/process/processId/activity/activityId/performer is adjusted so that response also contains

  • The configured includes and excludes

  • The current/last editor

  • The list of candidates (potential users that are seeing the activity in their inbox and are able to take over the item) with a visibility reason (such as "belongs to a role", or "substitute of")