Installation guide

Roles and Permissions

Ticket Management needs roles from other modules to be able to use them. The roles which are needed for the modules are:

MACMA - User Reader: Read users, groups and modules.
MDM - Equipment User: Has read access.
Portal - Web Portal Registration: Is allowed to register modules via API and custom modules and views via UI.
Deviation Processor - Deviation Processor Reactor: Role for reactor module to register and update deviations.
Notification Service - Notification Service Client Modules: Client Modules with full access to Notification Service’s resources.

Ticket Management also provides roles with following permissions:

Ticket Management User: The user can see the "Ticket Management" navigation element in Portal and has read permissions on Ticket Contexts, application configurations, public documents, context contributions, widgets and facilities.
Ticket Management Expert: The user can see the "Ticket Management" navigation element in Portal and has read permissions on Ticket Contexts, application configurations, public documents, context contributions, widgets and facilities.
Ticket Management Admin: The user can see the "Ticket Management" navigation element in Portal and has privileges to read, add, modify, delete (not supported yet) all tickets. The user can also read all ticket-contexts, application configurations, public documents, context contributions, widgets and facilities.
Ticket Reader: A role which allows to read any ticket. E.g. Operation Routines need this role to be able to read any ticket, without being restricted by the fine-grained-access-control implemented for Condition Monitoring ticket use case.
Ticket Creator: A role which allows to create any ticket. This is used for example from Deviation Processor to create any ticket, without being restricted by the fine-grained-access-control implemented for Condition Monitoring ticket use case.
Ticket Modifier: A role which allows to modify any ticket, without being restricted by the fine-grained-access-control implemented for Condition Monitoring ticket use case.
Ticket Context Registrar: A role to read, add, modify and delete ticket-contexts.
Ticket Escalation Mapping Administrator: A role to read, add, modify and delete escalation mappings.
Solution Group Configurator: A role to read, add, modify and delete solution group configurations.
Ticket Anonymization Configurator: A role to read, add, modify and delete ticket anonymization configurations. The user can also see the "Configuration" navigation element in Portal.
Ticket Anonymization Executor: A role to execute the ticket anonymization task. The user can also see the "Configuration" navigation element in Portal.
Ticket Archiving Configurator: A role to read, add, modify and delete ticket archiving configurations. The user can also see the "Configuration" navigation element in Portal.
Portal registration configuration Reader: Can read the Portal registration configuration.
Operator: Can perform operator related tasks.
Ticket Management Critical Configurator: A role to read, add, modify and delete critical ticket management configurations.
Notification Configurator: A role to read and modify notification configuration. The notification configuration allows to disable or enable sending direct messages to Notification Service for email/push notification functionality.

Manual configuration after installation

If it is another tenant than the zero tenant (BCI Tenant), make sure he has MDM 'Equipment user', MACMA 'User Reader' role assigned to the TM application:
Create a MACMA group "DEFAULT_ESCALATION_GROUP" for the tenant

Admin Rest API to control reloading of device master data from MDM for a specific tenant

POST /BCI_TS_ADMIN/v1/{{tenantId}}/device-master-data. Please pay attention the related MDM role 'Equipment user' is needed to be assigned to the TM application of this tenant.
e.g. in case it is a new tenant configured to have TM application after installation, and you want to have his device master data synchronized as soon as possible without waiting for the master data reload retry scheduler to run.
e.g. in case you want to synchronize the device master data for this tenant because of infrastructure outage like RabbitMQ.

Admin Rest API to control solution group filtering for a specific tenant

PUT /BCI_TS_ADMIN/v1/{tenant-id}/solution-group-configurations with the "enableSolutionGroupFiltering" attribute in the body set to true or false
The "Solution Group Configurator" role is needed to access this endpoint
In case a custom role is created, both ADD and MODIFY privileges of resourceId "urn:com:bosch:bci:tm:ts:Solution-Group-Configuration" are needed to access this endpoint
It is up to the customer to tag the group as solution group in the MACMA application.
e.g. Activate/Deactivate fetching only solution groups instead of all MACMA groups for the specified tenant by this operation.

Admin Rest API to configure ticket anonymization for a specific tenant

PUT /BCI_TS_ADMIN/v1/{tenant-id}/anonymization-configurations
Example request body:

{
  "anonymizationTimeInDays": 90
}

The "Ticket Anonymization Configurator" role is needed to access this endpoint
In case a custom role is created, both ADD and MODIFY privileges of resourceId "urn:com:bosch:bci:tm:ts:Anonymization-Configuration" are needed to access this endpoint

Admin Rest API to read ticket anonymization for a specific tenant

GET /BCI_TS_ADMIN/v1/{tenant-id}/anonymization-configurations
The "Ticket Anonymization Configurator" role is needed to access this endpoint
In case a custom role is created, READ privilege of resourceId "urn:com:bosch:bci:tm:ts:Anonymization-Configuration" is needed to access this endpoint

Admin Rest API to configure ticket archiving for a specific tenant

PUT /BCI_TS_ADMIN/v1/{tenant-id}/archive-configurations
Example request body:

{
  "archivingTimeInDays": 30
}

The "Ticket Archiving Configurator" role is needed to access this endpoint
In case a custom role is created, both ADD and MODIFY privileges of resourceId "urn:com:bosch:bci:tm:ts:Archiving-Configurations" are needed to access this endpoint
Example response body:

{
	"tenantId": "a80d483c-522e-11ee-be56-0242ac120002",
	"archivingTimeInDays": 30,
	"updatedBy": "502d43fe-c916-11eb-b8bc-0242ac130003",
	"updatedTime": "2023-01-31T23:00:00Z"
}

Admin Rest API to read ticket archiving for a specific tenant

GET /BCI_TS_ADMIN/v1/{tenant-id}/archive-configurations
The "Ticket Archiving Configurator" role is needed to access this endpoint
In case a custom role is created, READ privilege of resourceId "urn:com:bosch:bci:tm:ts:Archiving-Configurations" is needed to access this endpoint
In case no configuration is configured for a specific tenant, the default archiving time is returned.
Example response body:

{
	"tenantId": "a80d483c-522e-11ee-be56-0242ac120002",
	"archivingTimeInDays": 30,
	"updatedBy": "502d43fe-c916-11eb-b8bc-0242ac130003",
	"updatedTime": "2023-01-31T23:00:00Z"
}

Admin Rest API to configure notification configuration for a specific tenant

PUT /BCI_TS_ADMIN/v1/{tenant-id}/notification-configurations
Example request body:

{
  "sendDirectMessages": true
}

The "Notification Configurator" role is needed to access this endpoint
In case a custom role is created, both READ and MODIFY privileges of resourceId "urn:com:bosch:bci:tm:ts:Notification-Configurations" are needed to access this endpoint

Admin Rest API to read notification configuration for a specific tenant

GET /BCI_TS_ADMIN/v1/{tenant-id}/notification-configurations
The "Notification Configurator" role is needed to access this endpoint
In case a custom role is created, READ privilege of resourceId "urn:com:bosch:bci:tm:ts:Notification-Configurations" is needed to access this endpoint
Example response body:

{
	"tenantId": "a80d483c-522e-11ee-be56-0242ac120002",
	"sendDirectMessages": true,
	"updatedBy": "502d43fe-c916-11eb-b8bc-0242ac130003",
	"updatedTime": "2023-01-31T23:00:00Z"
}

Admin Rest API to create/modify/delete module context definitions for a ticket domain in a tenant dependent way

It is normally module’s own responsibility to register domain for specific tenant. In case he is not able to perform the operation automatically, a privileged user can also do it on behalf of the module.

PUT /BCI_TS/v1/{tenant-id}/domains/{domain-id}/ticket-contexts
The Role "Ticket Context Registrar" is necessary for calling the REST API.
In case a custom role is created, ADD, DELETE, MODIFY privilege of resourceId "urn:com:bosch:bci:tm:ts:All-Ticket-Context" is needed to access this endpoint
An optional domain owner can be set in the request from a privileged user to specify the owner of the domain.
Once a domain owner is set, it can not be changed.
Request from other modules by using client credential flow will have the domain owner set automatically to the caller module.
Example request body:

{
  "displayName": "Your Own Application",
  "domainOwnerApplicationId": "232j7ssxuzo21s9d4dxw06wey",
  "contexts": [
    {
      "attribute": "productId",
      "mandatory": true,
      "translations": {
        "en": "Product Id",
        "de": "Produkt Id"
      }
    },
    {
      "attribute": "code",
      "mandatory": false,
      "translations": {
        "en": "Code"
      }
    }
  ]
}

Copy data from one IAS instance to another to share the same data of Ticket Management

Preconditions:
- The source IAS instance should not be actively used during the operation, to make sure no data get lost during the cloning.
- There are no pending messages in TM related RabbitMQ queues.
- The data in MACMA, MDM has be cloned already (including dynamic resources) and no data has been changed in MACMA and MDM (e.g. new device created, relink of device to another facility) in the target system since then.
Then:
- as long as the tenantId, userId, groupId, dynamic resourceId (dependency to MACMA. If MACMA tables can be cloned, then fine), and facilityId, deviceId, deviceTypeId (dependency to MDM. If MDM tables can be cloned, then fine) stay unchanged, the TM tables (Tables starting with "TM_") can be cloned.
- restart TM services (Ticket Service) after data cloning so that the local caches are built based on the cloned data in DB.

Read Portal registration configuration

GET /portal-api/v3/registration-configuration
The "Portal registration configuration Reader" role is needed to access this endpoint
In case a custom role is created, READ privilege of resourceId "urn:com:bosch:bci:tm:ts:Portal-Registration-Configuration" is needed to access this endpoint
The response body has the same schema as Portal’s "Create or update a registered module" endpoint.

Admin Rest API to configure resource registrations for a specific tenant

PUT /BCI_TS_ADMIN/v1/{tenant-id}/resource-registration-configurations
Example request body:

{
  "facilityTypesToRegisterResources": [
    "E14CAB2A-2113-441C-A4A1-FCC6AF91861D"
  ],
  "facilityTypesToDeleteResources": [
    "FEE7685D-2114-4AD3-9F22-6480E2D717ED"
  ]
}

The configuration is used to define the facility types for which the dynamic resources (necessary for fine-grained access) should be registered or deleted.
The Ticket Management Critical Configurator role is needed to access this endpoint
In case a custom role is created, both ADD and MODIFY privileges of resource with id urn:com:bosch:bci:tm:ts:Resource-Registration-Configuration are needed to access this endpoint

Admin Rest API to read resource registrations for a specific tenant

GET /BCI_TS_ADMIN/v1/{tenant-id}/resource-registration-configurations
The configuration is used to define the facility types for which the dynamic resources (necessary for fine-grained access) should be registered or deleted.
The Ticket Management Critical Configurator role is needed to access this endpoint
In case a custom role is created, READ privilege of resource with id urn:com:bosch:bci:tm:ts:Resource-Registration-Configuration is needed to access this endpoint

Admin Rest API to delete resource registrations for a specific tenant

DELETE /BCI_TS_ADMIN/v1/{tenant-id}/resource-registration-configurations
The configuration is used to define the facility types for which the dynamic resources (necessary for fine-grained access) should be registered or deleted.
The Ticket Management Critical Configurator role is needed to access this endpoint
In case a custom role is created, DELETE privilege of resource with id urn:com:bosch:bci:tm:ts:Resource-Registration-Configuration is needed to access this endpoint

Start Docker Container

After the helm deployment is finished, the pods for Ticket Management are started:

Docker Container Name	Description
tm/ticket-service	Ticket Service Application

Docker Container Name

Description

tm/ticket-service

Ticket Service Application