Details

    • PM Priority:
      140

      Description

      AT:

      • on login the user is authorized against each engine configured and the permissions per user & engine are stored
      • on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access
      • in multi engine scenario the following holds for user authorizations:
        • once a users logs in, we try to authenticate him on each configured engine. For each engine the user is authenticated successfully with we fetch Optimize application authorization and resource authorizations (definition & tenant authorizations)
        • a user can access Optimize as soon as one engine grants Optimize Application Access
        • if there are several engines with the same definitions (same key + version) a different `defaultTenantId` needs to be configured for each of those engines
          • then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        • the case that there are several engines with the same definitions (same key + version) and no `defaultTenantId` is configured is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines, multiple process definitions are listed for the same key etc.) => needs to be highlighted in the documentation
          • the same limitation applies if the same tenant and definition key pair is present on multiple engines
      • the multi-engine documentation is updated to reflect the new behavior

        Activity

        felix.mueller Felix Müller created issue -
        felix.mueller Felix Müller made changes -
        Field Original Value New Value
        Rank Ranked higher
        johannes.heinemann Johannes Heinemann made changes -
        Fix Version/s 2.5.0 [ 15385 ]
        Fix Version/s 2.5 [ 15364 ]
        felix.mueller Felix Müller made changes -
        Description Optimize supports One Process Engine Per Tenant correctly (including permissions):
        * https://docs.camunda.org/manual/7.10/user-guide/process-engine/multi-tenancy/#one-process-engine-per-tenant

        Optimize supports usage of same proc-def-key on different engines - separates multi-engine data correctly.
        felix.mueller Felix Müller made changes -
        PM Priority 140
        johannes.heinemann Johannes Heinemann made changes -
        Labels current_release needs_testing
        johannes.heinemann Johannes Heinemann made changes -
        Component/s backend [ 13653 ]
        johannes.heinemann Johannes Heinemann made changes -
        Assignee Sebastian Bathke [ sebastian.bathke ]
        sebastian.bathke Sebastian Bathke made changes -
        Description Optimize supports One Process Engine Per Tenant correctly (including permissions):
        * https://docs.camunda.org/manual/7.10/user-guide/process-engine/multi-tenancy/#one-process-engine-per-tenant

        Optimize supports usage of same proc-def-key on different engines - separates multi-engine data correctly.
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions from engines he is authorized for
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key

        Optimize supports One Process Engine Per Tenant correctly (including permissions):
        * https://docs.camunda.org/manual/7.10/user-guide/process-engine/multi-tenancy/#one-process-engine-per-tenant

        Optimize supports usage of same proc-def-key on different engines - separates multi-engine data correctly.
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions from engines he is authorized for
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key

        Optimize supports One Process Engine Per Tenant correctly (including permissions):
        * https://docs.camunda.org/manual/7.10/user-guide/process-engine/multi-tenancy/#one-process-engine-per-tenant

        Optimize supports usage of same proc-def-key on different engines - separates multi-engine data correctly.
        AT:
        - Optimize supports usage of same proc-def-key on different engines - separates multi-engine data correctly.
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions from engines he is authorized for
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - Optimize supports usage of same proc-def-key on different engines - separates multi-engine data correctly.
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions from engines he is authorized for
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        AT:
        - Optimize supports usage of same proc-def-key on different engines - separates multi-engine data correctly.
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions from engines he is authorized for
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        * in multi engine scenario the following holds for user authorizations:
        ** once a users logs in, we try go through each configured engine. For each engine the user has Optimize application access, we fetch the authorizations
        ** if there are several engines with the same definition (same key + version), then the user can only see the data the definition+engine combinations he has been granted access.
        ** the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        sebastian.bathke Sebastian Bathke made changes -
        Labels current_release needs_testing needs_testing next_release
        michael.wagner Michael Wagner made changes -
        Labels needs_testing next_release current_release needs_testing next_release
        michael.wagner Michael Wagner made changes -
        Labels current_release needs_testing next_release current_release needs_testing
        sebastian.bathke Sebastian Bathke made changes -
        Status Open [ 1 ] In Specification [ 10000 ]
        sebastian.bathke Sebastian Bathke made changes -
        Rank Ranked lower
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - Optimize supports usage of same proc-def-key on different engines - separates multi-engine data correctly.
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions from engines he is authorized for
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        * in multi engine scenario the following holds for user authorizations:
        ** once a users logs in, we try go through each configured engine. For each engine the user has Optimize application access, we fetch the authorizations
        ** if there are several engines with the same definition (same key + version), then the user can only see the data the definition+engine combinations he has been granted access.
        ** the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        * in multi engine scenario the following holds for user authorizations:
        ** once a users logs in, we try go through each configured engine. For each engine the user has Optimize application access, we fetch the resource authorizations (definition & tenant authorizations)
        ** if there are several engines with the same definition (same key + version) and a different `defaultTenantId` configured, then the user can only see the data the definition+tneant combinations he has been granted access.
        ** the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        * in multi engine scenario the following holds for user authorizations:
        ** once a users logs in, we try go through each configured engine. For each engine the user has Optimize application access, we fetch the resource authorizations (definition & tenant authorizations)
        ** if there are several engines with the same definition (same key + version) and a different `defaultTenantId` configured, then the user can only see the data the definition+tneant combinations he has been granted access.
        ** the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we try go through each configured engine. For each engine the user has Optimize application access, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definition (same key + version) and a different `defaultTenantId` configured, then the user can only see the data the definition+tneant combinations he has been granted access.
        -- the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        sebastian.bathke Sebastian Bathke made changes -
        Status In Specification [ 10000 ] In Development [ 10312 ]
        sebastian.bathke Sebastian Bathke made changes -
        Status In Development [ 10312 ] In Specification [ 10000 ]
        sebastian.bathke Sebastian Bathke made changes -
        Status In Specification [ 10000 ] In Development [ 10312 ]
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we try go through each configured engine. For each engine the user has Optimize application access, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definition (same key + version) and a different `defaultTenantId` configured, then the user can only see the data the definition+tneant combinations he has been granted access.
        -- the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we try go through each configured engine. For each engine the user has Optimize application access, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definition (same key + version) and a different `defaultTenantId` configured, then the user can only see the data the definition+tneant combinations he has been granted access.
        -- the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we try go through each configured engine. For each engine the user has Optimize application access, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definition (same key + version) and a different `defaultTenantId` configured, then the user can only see the data the definition+tneant combinations he has been granted access.
        -- the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we try go through each configured engine. For each engine the user has Optimize application access, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definition (same key + version)
        --- and a different `defaultTenantId` configured
        ---- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        --- and no `defaultTenantId` configured
        ---- then the user cannot select engine specific data using the tenant selection but only sees the instance data he is authorized to see
        -- the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we try go through each configured engine. For each engine the user has Optimize application access, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definition (same key + version)
        --- and a different `defaultTenantId` configured
        ---- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        --- and no `defaultTenantId` configured
        ---- then the user cannot select engine specific data using the tenant selection but only sees the instance data he is authorized to see
        -- the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version)
        --- and a different `defaultTenantId` configured
        ---- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        --- and no `defaultTenantId` configured
        ---- then the user cannot select engine specific data using the tenant selection but only sees the instance data he is authorized to see
        -- the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version)
        --- and a different `defaultTenantId` configured
        ---- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        --- and no `defaultTenantId` configured
        ---- then the user cannot select engine specific data using the tenant selection but only sees the instance data he is authorized to see
        -- the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version)
        --- and a different `defaultTenantId` is configured
        ---- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        --- and no `defaultTenantId` is configured
        ---- then the user cannot select engine specific data using the tenant selection but only sees the instance data he is authorized to see
        -- the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version)
        --- and a different `defaultTenantId` is configured
        ---- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        --- and no `defaultTenantId` is configured
        ---- then the user cannot select engine specific data using the tenant selection but only sees the instance data he is authorized to see
        -- the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version)
        --- and a different `defaultTenantId` is configured
        ---- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        --- and no `defaultTenantId` is configured
        ---- then the user cannot select engine specific data using the tenant selection but only sees the instance data of engines he is authorized to see in report results
        -- the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version)
        --- and a different `defaultTenantId` is configured
        ---- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        --- and no `defaultTenantId` is configured
        ---- then the user cannot select engine specific data using the tenant selection but only sees the instance data of engines he is authorized to see in report results
        -- the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version)
        --- and a different `defaultTenantId` is configured
        ---- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        --- and no `defaultTenantId` is configured
        ---- this case is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines multiple process definitions are listed etc.)
        -- the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version)
        --- and a different `defaultTenantId` is configured
        ---- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        --- and no `defaultTenantId` is configured
        ---- this case is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines multiple process definitions are listed etc.)
        -- the user gets notified if he sees only part of the data due to the previous point. For instance, user A has only access to defintion D on Engine E1, but user B has access to definition D on E1 and E2. Now we create a report R for definition D. Then A might see different results for in R than user B. In this case we show a warning to the user
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version)
        --- and a different `defaultTenantId` is configured
        ---- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        --- and no `defaultTenantId` is configured
        ---- this case is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines multiple process definitions are listed etc.)
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version)
        --- and a different `defaultTenantId` is configured
        ---- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        --- and no `defaultTenantId` is configured
        ---- this case is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines multiple process definitions are listed etc.)
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version) a different `defaultTenantId` needs to be configured for each of those engines
        ---- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        -- the case that there are several engines with the same definitions (same key + version) and no `defaultTenantId` is configured is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines multiple process definitions are listed etc.) => needs to be highlighted in the documentation
        - the multi-engine documentation is updated to reflect the new behavior
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version) a different `defaultTenantId` needs to be configured for each of those engines
        ---- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        -- the case that there are several engines with the same definitions (same key + version) and no `defaultTenantId` is configured is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines multiple process definitions are listed etc.) => needs to be highlighted in the documentation
        - the multi-engine documentation is updated to reflect the new behavior
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version) a different `defaultTenantId` needs to be configured for each of those engines
        --- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        -- the case that there are several engines with the same definitions (same key + version) and no `defaultTenantId` is configured is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines multiple process definitions are listed etc.) => needs to be highlighted in the documentation
        - the multi-engine documentation is updated to reflect the new behavior
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version) a different `defaultTenantId` needs to be configured for each of those engines
        --- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        -- the case that there are several engines with the same definitions (same key + version) and no `defaultTenantId` is configured is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines multiple process definitions are listed etc.) => needs to be highlighted in the documentation
        - the multi-engine documentation is updated to reflect the new behavior
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version) a different `defaultTenantId` needs to be configured for each of those engines
        --- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        -- the case that there are several engines with the same definitions (same key + version) and no `defaultTenantId` is configured is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines, multiple process definitions are listed for the same key etc.) => needs to be highlighted in the documentation
        - the multi-engine documentation is updated to reflect the new behavior
        sebastian.bathke Sebastian Bathke made changes -
        Labels current_release needs_testing needs_testing next_release
        sebastian.bathke Sebastian Bathke made changes -
        Status In Development [ 10312 ] In Specification [ 10000 ]
        sebastian.bathke Sebastian Bathke made changes -
        Status In Specification [ 10000 ] In Development [ 10312 ]
        sebastian.bathke Sebastian Bathke made changes -
        Labels current_release needs_testing next_release needs_testing next_release
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version) a different `defaultTenantId` needs to be configured for each of those engines
        --- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        -- the case that there are several engines with the same definitions (same key + version) and no `defaultTenantId` is configured is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines, multiple process definitions are listed for the same key etc.) => needs to be highlighted in the documentation
        - the multi-engine documentation is updated to reflect the new behavior
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version) a different `defaultTenantId` needs to be configured for each of those engines
        --- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        -- the case that there are several engines with the same definitions (same key + version) and no `defaultTenantId` is configured is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines, multiple process definitions are listed for the same key etc.) => needs to be highlighted in the documentation
        --- the same limitation applies if the same tenant and key pair is present on multiple engines
        - the multi-engine documentation is updated to reflect the new behavior
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version) a different `defaultTenantId` needs to be configured for each of those engines
        --- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        -- the case that there are several engines with the same definitions (same key + version) and no `defaultTenantId` is configured is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines, multiple process definitions are listed for the same key etc.) => needs to be highlighted in the documentation
        --- the same limitation applies if the same tenant and key pair is present on multiple engines
        - the multi-engine documentation is updated to reflect the new behavior
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version) a different `defaultTenantId` needs to be configured for each of those engines
        --- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        -- the case that there are several engines with the same definitions (same key + version) and no `defaultTenantId` is configured is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines, multiple process definitions are listed for the same key etc.) => needs to be highlighted in the documentation
        --- the same limitation applies if the same tenant and definition key pair is present on multiple engines
        - the multi-engine documentation is updated to reflect the new behavior
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access by the `Optimize` Application authorization
        - on executing a report an implicit filter is added to each command so the user can only see data from engines he is authorized to read history from for the particular process/decision key
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version) a different `defaultTenantId` needs to be configured for each of those engines
        --- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        -- the case that there are several engines with the same definitions (same key + version) and no `defaultTenantId` is configured is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines, multiple process definitions are listed for the same key etc.) => needs to be highlighted in the documentation
        --- the same limitation applies if the same tenant and definition key pair is present on multiple engines
        - the multi-engine documentation is updated to reflect the new behavior
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version) a different `defaultTenantId` needs to be configured for each of those engines
        --- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        -- the case that there are several engines with the same definitions (same key + version) and no `defaultTenantId` is configured is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines, multiple process definitions are listed for the same key etc.) => needs to be highlighted in the documentation
        --- the same limitation applies if the same tenant and definition key pair is present on multiple engines
        - the multi-engine documentation is updated to reflect the new behavior
        johannes.heinemann Johannes Heinemann made changes -
        Labels needs_testing next_release current_release needs_testing next_release
        johannes.heinemann Johannes Heinemann made changes -
        Labels current_release needs_testing next_release current_release needs_testing
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we iterate through each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version) a different `defaultTenantId` needs to be configured for each of those engines
        --- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        -- the case that there are several engines with the same definitions (same key + version) and no `defaultTenantId` is configured is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines, multiple process definitions are listed for the same key etc.) => needs to be highlighted in the documentation
        --- the same limitation applies if the same tenant and definition key pair is present on multiple engines
        - the multi-engine documentation is updated to reflect the new behavior
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we try to authenticate him on each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version) a different `defaultTenantId` needs to be configured for each of those engines
        --- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        -- the case that there are several engines with the same definitions (same key + version) and no `defaultTenantId` is configured is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines, multiple process definitions are listed for the same key etc.) => needs to be highlighted in the documentation
        --- the same limitation applies if the same tenant and definition key pair is present on multiple engines
        - the multi-engine documentation is updated to reflect the new behavior
        sebastian.bathke Sebastian Bathke made changes -
        Description AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we try to authenticate him on each configured engine. For each engine the user has Optimize application authorization, we fetch the resource authorizations (definition & tenant authorizations)
        -- if there are several engines with the same definitions (same key + version) a different `defaultTenantId` needs to be configured for each of those engines
        --- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        -- the case that there are several engines with the same definitions (same key + version) and no `defaultTenantId` is configured is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines, multiple process definitions are listed for the same key etc.) => needs to be highlighted in the documentation
        --- the same limitation applies if the same tenant and definition key pair is present on multiple engines
        - the multi-engine documentation is updated to reflect the new behavior
        AT:
        - on login the user is authorized against each engine configured and the permissions per user & engine are stored
        - on listing process/decision definitions a user only sees the definitions & tenants from engines he is authorized to access
        - in multi engine scenario the following holds for user authorizations:
        -- once a users logs in, we try to authenticate him on each configured engine. For each engine the user is authenticated successfully with we fetch Optimize application authorization and resource authorizations (definition & tenant authorizations)
        -- a user can access Optimize as soon as one engine grants Optimize Application Access
        -- if there are several engines with the same definitions (same key + version) a different `defaultTenantId` needs to be configured for each of those engines
        --- then the user can only see the data of the definition+tenant combinations he has been granted access to by each of the engines
        -- the case that there are several engines with the same definitions (same key + version) and no `defaultTenantId` is configured is not supported and leads to inconsistent behavior (e.g. if same key exists on multiple engines, multiple process definitions are listed for the same key etc.) => needs to be highlighted in the documentation
        --- the same limitation applies if the same tenant and definition key pair is present on multiple engines
        - the multi-engine documentation is updated to reflect the new behavior
        sebastian.bathke Sebastian Bathke made changes -
        Status In Development [ 10312 ] In Review [ 10212 ]
        sebastian.bathke Sebastian Bathke made changes -
        Assignee Sebastian Bathke [ sebastian.bathke ]
        Status In Review [ 10212 ] Done [ 10010 ]
        Resolution Done [ 10000 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            felix.mueller Felix Müller
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: