Uploaded image for project: 'Camunda Optimize'
  1. Camunda Optimize
  2. OPT-1675

Decision instance import only imports one instance and overwrites it with new data

XMLWordPrintable

    • Icon: Bug Report Bug Report
    • Resolution: Fixed
    • Icon: L3 - Default L3 - Default
    • 2.3.0
    • None
    • backend
    • None

      Context:
      The issue is the import maps the decisionDefinition id to the decisionInstance id resulting in only one instance document present.

      Use the decisionInstanceId correctly and add a test that verifies multiple instances are imported correctly.

      Problem:

      • given:
        • I have a engine running with one decision definition deployed
        • for the decision definition there have been several decision instances started
      • when:
        • Optimize imports the engine data
      • then:
        • Elasticsearch contains only a single decision instance
      • expected:
        • Elasticsearch constains all the data from the engine including all started decision instances

        This is the controller panel for Smart Panels app

            [OPT-1675] Decision instance import only imports one instance and overwrites it with new data

            Johannes added a comment -

            For someone that does not know what the code/ticket is about, the description is not very helpful. I adjusted the description so that you get an idea how one might describe the problem. For bug fixes I always like the given, when, then, expected structure, since it makes clear how to reproduce the problem. One thing in general: In my opinion should a ticket description not contain the solution to a problem or feature but help to understand what is expected from the feature/ how to reproduce the problem.

            Other than that the implementation looks great! I will merge it to master. Well done

            Johannes added a comment - For someone that does not know what the code/ticket is about, the description is not very helpful. I adjusted the description so that you get an idea how one might describe the problem. For bug fixes I always like the given, when, then, expected structure, since it makes clear how to reproduce the problem. One thing in general: In my opinion should a ticket description not contain the solution to a problem or feature but help to understand what is expected from the feature/ how to reproduce the problem. Other than that the implementation looks great! I will merge it to master. Well done

              Unassigned Unassigned
              sebastian.bathke Sebastian Bathke
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: