Config Server: Tasks

[iaktern]

• MQTT:
  • Button in the middle to send the dataset to a configured mqtt broker
  • add in setting MQTT settings: Server, Topic, User, Pass
• Status of Datapicker and Middleware: add new nav elements on left side for status (functionality should be in PROCEED main repo)
• UI: put Name and ID into Header and add an Edit button
  
• add Reference Data Sets between Target and Machine Sets
• Settings: Name of "Tech Data Set" should be configurable, Default not Tech Data Set but: "Config Data Set"
• Space-Logo should be configurable (functionality should be in PROCEED main repo)
  • Replace logo in login screen
• UI: Show "Services and Status" under the separator line (in PROCEED main repo)

Implement New TDS Structure (see Miro):

• implement structure in backend and database
• adapt the UI elements to write into the new structure
• add to the three editing icons (in edit mode) two more icons for moving the parameter up and down. find a beautiful position for all five icons
• UI: change the table columns for the parameters to (in this sequence): Name, Value, Unit, Parameter-Description, Transformation
  • implement the following functionality and show a small question mark icon behind "Name" with the following explanation (tooltip): "This column shows the "Display Name" of a parameter. If it is not filled it shows the "Name" field of a parameter in italic."
• connect meta-data (shortName, name, description, categories) with "Create New" modal
• for creating a new config set with "New TDS" based on the Template, generate the uuids for all parameters in the template
• UI Edit modal: check that the "Name" input field only has lower-case letters, upper-case letters, numbers or -_+. Autogenerate a (changeable) suggestion for the "Name" input field every time a new character is inserted in the "Display Name" field (replace space with -, remove all other special characters
• UI Tree-View: show displayName text in the TreeView for each element. Default: Deutsch (as long as we have no language selection built into the UI)
• UI Tree-View: show hierarchical structure of parameters if structureVisible != false (if ==false then all child elements should get one level up)
• UI Editor: show multiple, expandable sections of all Parameters of the highest/root level of the TreeView of the View mode (hint: if structureVisible is false, parameters "jump" one level up in view mode). Each section has a table with all its including parameters. In Edit mode, still show exactly the same sections of view mode, even if a parameter is not on the root level anymore because of structureVisible = false. For all additional Parameters on the root level, which are not shown in the View mode, show an extra section
  • UI: Default if opening a new Config Set: TreeView = show all root elements but closed, Right Content View: all sections closed
• UI TreeView:
  • remove "m" and "c" from the boxes
  • create a hard-coded color for "parameterType": "meta" and its childs: #F0FFFF
  • create a hard-coded color for "parameterType": "content" and its childs: #F6FFED
  • for all parameters with a transformation (not "none"), the square should have on one half another color:
    • "manual": #FFF8E7
    • "linked": #FFFFE0
    • "algorithm": #F1E9D2
    • "external": #E5E4E2
  • same functionality for TreeView and Tables (right side): "Move up", "Move down", "Edit", "Add Parameter", "Add Nested Parameter", "Delete"
• parse/store Categories as a semicolon separated list in meta
  • UI: there is a Parameter "Categories" in the TDS header, which is linked to our meta field. If you open the Edit modal, it should not show the semicolon separated list but our Categories input field
• realize copyValueToParameterAtCreationFromTemplate functionality of the meta fields (shortName, name, description, categories).
  • UI: show a drop down where the user can select None or one of the four meta fields. If the user selects one, store the path into the array. if the user deselects one to "None" again, create a normal parameter inside the structure.
• UI Edit Modal: activate language input fields, to insert and see the different text for Display Name and Description. (even though, we not yet use it somewhere in the UI)
  • UI: Default in TreeView and Table View: Deutsch
  • UI Bug: after creating a new Parameter, in TreeView the parameter name (not displayname) is shown (probably reason: in the Edit modal you add everything in English?)
• UI: Show an "Add Parameter" under every nested parameter table, if it is opened
• UI: a row in the table on the right side, should not have any plus icon if it has no nested parameters (like the TreeView)
• UI (low prio): implement "Move up" and "Move down"
• UI (low prio): in the Parameter Edit modal, for linking parameters for a transformation, a drop-down opens. ESC key stroke should close the drop-down instead of closing the Edit modal.
• UI: in the TreeView, every content parameter (parameterType == content, if none look at the parent) without a value should be italic and dark-red
• UI: After saving a new value for a parameter in the Edit modal, show a pop-up if transformations were executed. In the popup, show all changed parameters.
• UI: Advanced section in the parameter Edit modal that is by default collapsed/closed. if someone opens this Advanced section, there he can set the Parameter Type, Structure Visible, and Template Source for Value (valueTemplateSource).
• (low prio) Config Editor -> Edit modal: reduce all language selection lists, e.g. not 4 differen dialect for german, just "de"
• UI: in the Editor in the right content area: the border of the blocks should have the same color as the parameter type (content -> light green)
• UI (low prio): in the Editor in the right content area - in Edit mode: indent the separate blocks a little to the right if they are a child element of the previous block. Example: the "Vorgabe-Datensatz" block should be a little indented to the right because it is under the "TDS Body" block
• UI (low prio): drop-down language selection in UI (only for the values of the config set, not for the whole MS)
• UI Edit Modal (low prio, later): on top of the "Value" input field, have a small tab-environment where the user can select either "Value" (+Question Mark Icon: "Value is directly stored inside this Parameter"), "Target Value" (+Question Mark Icon: "Value is stored inside a Nested Parameter called Target Value") or "Min-Target-Max" (+Question Mark Icon: "Three Values that are stored inside Nested Parameters for describing a range"). Add the functionalities like described in the question mark texts (see AAS example, "TargetValue" = german displayName "Sollwert"). This sub-parameters must have structureVisible set to false so that it is not displayed in the View mode. If "Min-Target-Max" is selected, display two further input fields for entering addtionally a Min and Max value. "Min", and "Max" which contain the inserted values in its "value" properties.
• Bug: it seems that usedAsInputParameterIn -> path is not filled anymore
• if the main Header is removed and someone tries to create a new version, add the main Header again
• AAS Import/Export: should be the same functionality as the REST API
  • AAS: Serialization of Categories
  • AAS: Serialization of Transformations
• Add Option to send AAS format over MQTT
• Drop-Down button in Editor and right click to create dataset:
  • 1. "Create a Target Dataset": creates default structure (deactivate button if already one target dataset exists);
  • 2. "Create a Reference Dataset": creates default structure and copies all Body Parameter from Target Dataset with a transformation set to linked, the correct input parameter set and usedAsInputParameterIn updated. (deactivate button if already one reference dataset exists);
  • 3. "Update Reference Dataset": copies all Body Parameter from Target Dataset (if the same name is not yet existing) with a transformation set to linked, the correct input parameter set and usedAsInputParameterIn updated.
  • 4. "Create a Machine Dataset": creates default structure and copies all Body Parameter from Reference Dataset with a transformation set to linked, the correct input parameter set and usedAsInputParameterIn updated.
  • 5. "Update Machine Dataset": update default structure and copies all new Body Parameter from Reference Dataset with a transformation set to linked, the correct input parameter set and usedAsInputParameterIn updated.
• UI: The collapse/extend icon in the TreeView should only open and close the Content/Body parameters (not the Header fields)
• Units
• Show usedAsInputParameterIn and transformation -> linkedParameters in UI + clickable

TDS Template:

• TDS Template: "TDS Header" and all its subparameter should be invisible in the View mode => structureVisible: false
  • Bug: Header stays hidden in edit mode
• TDS Template: the parameter TDSIdentifier in the Machine Datasets should have a transformation by default: linked to TDSIdentifier in the Config Header
  • Transformation currently not working for virtual Parameters
• TDS Template: the parameter AcknowledgeMode in the Machine Datasets should have a transformation by default: linked to AcknowledgeModeDefault in the Config Header
• (low prio) Generic Structure: in our TDS Template, some parameters contains references to other parameters in linkValueToParameterValue, usedAsInputParameterIn, linkedInputParameters. They all have the same structure: [{ "id": "<uuid>", "path": ["Header", "VersionNumber"] }, ...]. In out internal TDS template, the UUID must be empty and only the path exists because before creating, we can not know what will be the uuid of the referenced parameter. For now, the few transformations of the TDS template are more or less hard coded in the backend => make it more generic: if no uuid exists, then use the path to create a transformation
  • data structure adapted

TDS/Config List table:

• show all meta data of the TDS in the main table: Id, Name, Categories, Description, Version
• make it sortable (not the version number column)
• make it searchable/filterable (ID, Name, Desc, Category)
• removing the three dots on the right side (all columns are already shown)
• make the icons of the rows work again (Copy can be done later)
• Add functionality to copy a config
• "New Empty Config": create an empty editor
• UI: After Creating a new Config Set, automatically open the Editor
• (low prio) in the Config Set list: only one "Import" button -> that automatically detects, if it is the internal or the AAS format
• Export: like in the Editor -> be able to export as internal or AAS format
• (low prio) in the Config Set list: only one "New" button (no drop-down anymore). that opens our meta modal which should have an extra "Template" selection area, where "Empty Set" or "Techdata-Set" can be selected

REST API:

../configurations:

• GET: return a list of all Configurations with their Metadata (no content/parameters, because the content has multiple versions later on)
• POST: Create New Empty Configuration Container, id generated at server, shortName required
• POST: with query parameter ?template=TDS, create a new TDS configuration

../configurations/{config-container-id-or-shortName}:

• (low Prio): in the path not only the id of the config-container can be used, but also the unique shortName (update this behaviour for every paths)
• GET: return a list of versions
  • (for now, only "latest")
• PUT: like "Import" in the UI.
  • If Container id exists (path and body), show error (return "please first delete the existing Configuration Set")
• in the UI: ask for confirmation to override the Set and all its versions (i.e. delete and import)
• DELETE: delete latest and all versions

../configurations/{config-container-id-or-shortName}/latest-parameter:

• POST: create a new Parameter directly under content (root parameter) with the following logic
• POST: if query parameter ?asSubParameterOf=<uuid> is given, create a new Parameter directly as a Subparameter of the given Parameter with the following logic
• (low Prio): implement the query parameter ?aas-format=true for setting the AAS serialization
• Parameter Logic:
  • we should be a little bit more open, so that the complete parameter structure must not always be given. it is okay, if some properties are missing.
  • Only name is required.
  • the following part of the generic parameter should be set/changeable via REST: name*, parameterType, structureVisible, displayName*, description*, value*, valueTemplateSource*, transformation*
    • name: it must be unique in the whole Configuration
    • displayName and description: this does not add an entry, but it overrides the complete array
    • value: can only be set if transformation is not existing or transformationType is none or manual
    • valueTemplateSource: 1. check is given reference is correct ("shortName", "name", "description", "categories"), 2. update value and correctly link with the meta parameter
    • transformation: can be given if the following conditions are satisfied:
      • type none: linkedInputParameters and action must be empty (else: return 400 and error with description in body, hint: this is independent of value - it can have a value set or not)
      • type manual: linkedInputParameters must have exactly one entry which exists as parameter in the same TDS set, and action must be empty (else: return 400 and error with description in body, hint: this is independent of value - it can have a value set or not) => update usedAsInputParameterIn of the referenced parameter
      • type linked: linkedInputParameters must have exactly one entry which exists as parameter in the same TDS set, value must be empty, and action must be empty (else: return 400 and error with description in body) => 1. update value entry of own parameter and 2. update usedAsInputParameterIn of the linked parameter
      • type algorithm: linkedInputParameters could have entries or none, value must be empty, and action must be set (else: return 400 and error with description in body) => 1. calculate value entry of own parameter and 2. update usedAsInputParameterIn of the linked parameters
      • type external: linkedInputParameters must be empty, value must be empty, and action must be set (else: return 400 and error with description in body) => do nothing for now
  • changeableByUser, usedAsInputParameterIn, valueType, subParameters must not be set
    • usedAsInputParameterIn should be automatically updated if a transformation is added inside another parameter
    • valueType should be automatically calculated on our server based on the input of value. it should be automatically recalculated if value is updated.

../configurations/{config-container-id-or-shortName}/latest-parameter/{parameter-id}:

• PUT: create the update of a Parameter like the creation of a new Parameter (see POST) but with the following additions:
  • It is okay, if some properties of the Parameter structure are missing. The given properties update the existing ones and do not delete the others (exception: displayName and description: this does not add an entry, but it overrides the complete array)
  • id inside body can be missing. if id is included in body, it must be the same as in the REST path and already existing in the TDS set as a parameter
  • if (path-)parameter-id does not exist in the given set-id (in path): return 400 and error with description in body
    • i.e. even if the parameter exists in another configuration container set, throw an error
  • parameter can only be changed with PUT, if changeableByUser attribute is true or non-existent (default=true). if false, return 400 with explanation
  • change of name: change all references of this parameter (in usedAsInputParameterIn, linkedInputParameters, and maybe in the meta data fields copyValueToParameterAtCreationFromTemplate)
  • change of transformation: if the linkedInputParameters change compared to the previous linkedInputParameters, e.g. one referenced parameter was deleted, also remove the old, deleted input parameters from the referenced parameters usedAsInputParameterIn attribute
  • look into the existing usedAsInputParameterIn and update the values of the linked parameters accordingly to the change (i.e. run the transformation)
• (low Prio) DELETE: remove the parameter only on the latest version of the Configuration (later, if we have versioning)
• DELETE: also remove all references of this parameter (in usedAsInputParameterIn, and maybe in the meta data fields copyValueToParameterAtCreationFromTemplate)
• (low Prio): implement the query parameter ?aas-format=true for retrieving/setting the AAS serialization

/spaces/{space-id}/configurations/{config-container-id-or-shortName}/{version-id}

• remove PUT operation
• GET: implement the query parameter ?parameter-id-or-name for retrieving only one part of the configuration with all its subparameters
  • COMMENT: Done but as part of the method GET /spaces/{space-id}/configurations/{config-container-id-or-shortName}/latest-parameter/{parameter-id} and we cannot select Parameters by name since their names are not unique for a whole config
• (low Prio): implement the query parameter ?aas-format=true for retrieving the AAS serialization

/spaces/{space-id}/configurations/{config-container-id-or-shortName}/{version-id}/target|reference|machine

• remove all this paths and operations for "target", "reference" and "machine" (expect for the "feedback" parts, if they have been already implemented)

Transformations:

• Change Name of "Automatic" Transformation to "Linked" (also in template)
• Add a possibility to add a transformation for every parameter:
  • drop-down field for "Transformation-Type:" with values "None", "Manual", "Linked", "Formula" (hint: stored as "algorithm")
  • if "Transformation-Type:" is not "None" (any other selection), 1. disable "Value" input field, 2. show the other transformation input fields (if it is "None", the other transformation input fields should not be shown)
  • "Select Input Parameter" field: 1. move the "Linked Parameters" selection field (currently outside of the Edit modal - see picture) into the Edit modal and rename it to "Select Input Parameter". 2. if "Manual" and "Automatic" type is selected, only one input parameter is allowed, for "Formula" multiple input parameters should be selectable
  • for "Formula" type: each input parameter needs to automatically get a short variable name, e.g. IN1, and the user should see it (maybe under the selection dialog)
  • for "Formula" type: an input field "Formula" should be shown
• UI: Put an explaining question mark behind "Transformations" with the following text: "None: Value can be set directly. It is not linked to any other input parameter and is never changed automatically. \n Manual: Value can be set directly, but is linked to an input parameter. If this changes, Value is cleared and must be reset manually. \n Linked: Value is linked to an input parameter, from which Value is automatically copied 1-to-1. \n Formula: Value is linked to several input parameters, which are used to calculate a value using a formula."
  • UI: Remove "External" option from drop-down
• for every parameter that creates a new transformation (only if "OK" is clicked, not if "Cancel" is clicked), store this parameter also into the linked input parameters in the field usedAsInputParameterIn: []
  • when a TDS is initially loaded in the UI, go through all parameters: Recreate the usedAsInputParameterIn field for the whole TDS based on all existing transformations.
• do transformations at the backend when the "value" of an input parameter changes: 1. "Automatic" just copies values, 2. "Formula" executes with JSONata, 3. "Manual" empties/deletes the "value" input field
  • when the request to change the value of a parameter arrives at the backend, run the JSONata transformations on all parameters referenced in the usedAsInputParameterIn field. Send the response with every changed parameter back to the frontend.
  • UI - highlight (in the content tables and in the navigational TreeView) parameters that are empty or have transformations attached, so that someone is aware of a transformation and can check it. The following ideas apply in general, not just for parameters with transformations: for a parameter, 1. change the text color in the TreeView (not black) and 2. somehow change the table row (ideas: change font color or just make a border around the "value" column). Parameters with no/empty value should have an orange highlighting, Parameters with automatic, algorithm and external should have a blue highlighting
• UI: for each parameter in the table show (with the multi-selection drop down already used in the UI): 1. all parameters where it is used as input parameter, 2. all input parameters for its own transformation. (it should not be changeable inside the table directly (deactivated), only within the edit modal)
• optional/low priority UI: both should be linked in the UI for the View and Edit mode. if someone clicks on the UI box with the linked parameters, then the UI scrolls to the referenced parameter
• UI: show hint in TDS editor (as some kind of removeable banner), if "Not every Parameter inside the Target Dataset is linked in the Reference Dataset". Simply check the usedAsInputParameterIn attribute of every target parameter (not for the Header fields)
• (low prio): before "Save" inside the Edit modal, test if the Syntax of the formula is correct and show an error if not

Versioning

• Versioning: Versioning == Release: Each time the entire TDS is released by an authorized employee, it is “versioned.” Work is always done on “latest,” which represents the changes since the last version. Old versions should be viewable and recoverable.
  • The version parameters should be shown in the tables but should not be changeable by the User in the UI. Implement the attribute changeableByUser: true|false in our parameter structure
    • UI: deactivate the Edit, Add Nested Parameter, Delete buttons/icons if changeableByUser == false for a parameter
    • REST (low prio): deactivate the changing of parameters via REST that contain changeableByUser == false
  • UI: Implement a button "Release" in the top row which opens a modal: Title = "Release Config Set: Create new Version", Text = "Do you want to release the latest changes in this Configuration Set as a new version? <newline> There have been structural or content changes in Header, Target Dataset, or Reference Dataset compared to the previous version. The new version number for config set will be: <show last versioned Header -> VersionNumber> arrow: -> <show new Header -> VersionNumber> <newline> (for every changed Machine Dataset:) Machine Dataset <name>: There have been structural or content changes compared to the previous version. The new machine dataset version will be: <show last versioned Machine Dataset -> Header -> FullVersionNumber> arrow: -> <show pre-calculated Machine Dataset -> Header -> FullVersionNumber> <newline> (repeat for every changed Machine Dataset) <newline> "Cancel" and "Release" button on the right side
    • UI: only show the "Release" button in Config Set based on our TDS template (not in Empty Config Sets)
    • UI: when the Release modal exists and the versioning is working, remove the "Send to MQTT" button and add the functionality (sending to MQTT) to the button if a new version is created
    • UI: deactivate the Release button for someone who has not the release permission
    • UI: if there are no changes compared to the latest versioned dataset, show the following text: 1. for Config Set "There have been no structural or content changes in Header, Target Dataset, or Reference Dataset compared to the previous version.", 2. for each Machine Dataset "There have been no structural or content changes compared to the previous version."
  • versioning functionality Config Set Target and Reference: there is one VersionNumber in Header for changes (structural and content) in the Header, Target and Reference Dataset. This is an integer that should be incremented (+1) if there has been a change in the corresponding dataset compared to the previous version.
    • create backend function: versioningCheckIfTargetOrReferenceSetChanged(): true or false. if true, then also return the calculation of the next version number
    • create backend function: versioningCreateNewVersionForTargetOrReferenceSet(): new version number. 1. check if there were changes, 2. change Header -> VersionNumber +1 and write "latest" into the current VersionNumber (if no version parameter exist, create them) , 3. Copy the Config Set as JSON into a versioning table
  • versioning functionality Machine Datasets: 1. each Machine Datasets Header contains a StructureVersionNumber. This is an integer that should be incremented (+1) when structural changes occur in the specific machine dataset (parameter is renamed, deleted, or added). 2. each Machine Datasets Header contains a VersionNumber displaying the individual optimizations done to a specific machine dataset. This is an integer that should be incremented (+1) when content changes occured in the specific machine dataset compared to the previous version. But, it should just increment if only the Machine Dataset was changed and not the Structure of the Machine Dataset OR the Target OR the Reference Dataset. If the Structure of the Machine Dataset OR the Target OR the Reference Dataset was changed (see other version numbers), then reset this version to 0.
    • create backend function: versioningCheckEachMachineSetChangedStructure(): true or false for each machine set. if true, then also return the calculation of the next structure version number
    • create backend function: versioningCheckEachMachineSetChangedContent(): true or false for each machine set. if true, then also return the calculation of the next version number
    • create backend function: versioningCreateNewVersionsForMachineSet(): new structure and version number. 1. check if there were changes in Header -> VersionNumber, structural and content changes in each Machine Set, 2. change Machine's StructureVersion and VersionNumer according to the logic (if no version parameter exist, create them), 3. Copy the Machine Set as JSON into a separate Machine versioning table which is connected to the main Config Set version
      • creating a new version must mean that the whole TDS is saved as a separate copy and the parameters can no longer be changed. There is one exception: the free-run status on the machine (AcknowledgeMode) in all machine data sets must remain changeable so that it is possible to store which data set has been approved for use in production.
    • for the frontend and REST, we also need functions to easily retrieve 1. all versions of the main config set (1, 2, 3, latest -> versioningGetAllConfigSetVersions()), 2. for one config set to get all included machine datasets plus all of its full version numbers (versioningGetAllMachineDatasetsAndVersions(<config-set-id>), remember that new machine datasets can be added over time to a config set and must not exist already in the very first config version), 3. get a specific version of a config set (versioningGetConfigSet(<version>)), 4. get a specific version of a machine dataset (versioningGetMachineDataSet(<config-set-id>, <machine-dataset-id>, <full-version-number>))
  • in the “MachineDataset” - “Header” there is a “FullVersionNumber”: this should be be default a composition (via a transformation) of ‘StructureVersionNumber’ (first digit), “VersionNumber” from TDS Header (second digit), and “VersionNumber” from Machine Dataset Header (third digit), e.g., “2.1.4.”
  • Kai G.: change REST API so that (the newest) versions can be retrieved. Add a possibility to change the AcknowledgeMode of each MachineDataSet of an already versioned TDS set
    • Implement the REST API for machine datasets: /spaces/{space-id}/configurations/{config-container-id-or-shortName}/machines, /spaces/{space-id}/configurations/{config-container-id-or-shortName}/machines/{machine-dataset-id-or-name}/{full-version-number}, /spaces/{space-id}/configurations/{config-container-id-or-shortName}/machines/{machine-dataset-id-or-name}/{full-version-number}/acknowledged. Pay attention that full-version_number can be 2.3.5 or latest or latest-versioned or latest-acknowledged-versioned
  • UI: in the Version drop-down field in the top row, show all VersionNumber (e.g. 1, 2, 3, 4, latest). This drop-down should only be visible in "View" mode. If clicked, open the selected version in the view editor (read-only).
    • (low prio) Now, if an version is selected+shown, show a button next to the drop-down to "Set this version to Latest" (attention: before recovering this version, automatically create a new version of the current "Latest" if there are changes)
  • UI: in every Machine Dataset, show its own Version drop-down field which shows its FullVersionNumber (e.g. 1.4.2). This drop-down should only be visible in "View" mode. If clicked, open the selected version in the view editor (read-only) (hint: the full TDS will be reloaded, because old Machine versions depend on old Target and Reference).
• UI: after versioning is implemented, highlight the parameters which have changed since the last version, e.g. because an automatic transformation was applied
• implement "Set as Latest" functionality
• implement correct version comparison of current version with the previous one (currently, we just use a boolean to mark, if a parameter was changed. Problem: if a parameter is changed and then reverted back again, the system still shows that something changed.)
• Import Bug: changeableByUser attribute must be set for versionings even after Import (hard coded). else, someone could easily import a file which has changeableByUser set to true
• BUG blue parameter text to show unversioned changes: if two parameters have the same name/id (but within different parent elements), then the blue text is not consistent and only one of the two are shown in blue
• BUG blue parameter text to show unversioned changes: not well implemented because it is only stored if something has changed. Problem: if the change is reverted, it still show blue although there is no change compared to the previous version

Feedback

• Feedback functionality from Machine: Machine should be able to send feedback via REST which will be displayed in the UI
  • Kai: create REST API endpoints for Machine Feedback
  • implement Feedback REST API to store every change to an existing machine dataset: 1. The full version number must be specified for unique identification. 2. Meta data information must be in the "FeedbackHeader": “AuthenticationData” (person/worker, machine/cell), ‘FeedbackID’ (timestamp from the machine), “Comment” (change comment), 3. Complete machine dataset with changed values -> Return error if it does not contain the same parameters name as the original M-dataset or any data is missing in the FeedbackHeader
  • Persistently save all incoming M-TDSs by timestamp conneted to an existing M-TDS in the DB. Set “ReviewState” in the ‘Header’ to 0. (Note: incoming feedback from an M-TDS is not automatically a new version, but rather a kind of new “commit” to a version. In other words, an intermediate version.)
  • UI: When a TDS is opened, the system must check whether new machine feedback is available, i.e., “ReviewState” == 0 but only from the newest feedback. If so, a pop-up modal is displayed. The user/reviewer can decide whether they want to view the feedback. If so, the time (FeedbackID), comment, and authentication are displayed, along with a summary of the changes to all affected parameters. The user/reviewer can decide 1. whether they want to accept the feedback in Latest (sets “ReviewState” to 1), OR 2. reject it (sets “ReviewState” to 2), OR 3. send it to the reference dataset (sets ‘ReviewState’ to 3), OR 4. send it to the target dataset (sets “ReviewState” to 4).
    • If option 3 or 4 is selected, the comment field will change from read-only to writable so that further comments can be added, and all other buttons will disappear except for the selected button. When clicked, feedback will then be written to the respective “FeedbackHeader” of the reference or target data set: “AuthenticationData” (person is renewed), “FeedbackID” (timestamp is reset), comment from the comment field is used
  • UI: When a TDS is opened, it must check whether there is new feedback in the reference dataset, i.e., “ReviewState” == 0 but only from the newest feedback. If so, a pop-up modal is displayed. The user/reviewer can decide whether they want to view the feedback. If so, the time, comment, and authentication are displayed. The user/reviewer can decide 1. whether they want to “incorporate” the feedback (sets “ReviewState” to 1), OR 2. reject it (sets “ReviewState” to 2), OR 3. send it to the target dataset (sets “ReviewState” to 4).
    • If option 3 is selected, the comment field will change from read-only to writable so that further comments can be added, and all other buttons will disappear except for the selected button. When clicked, feedback is then written to the respective “FeedbackHeader” of the target dataset: ‘AuthenticationData’ (person is renewed), “FeedbackID” (timestamp is reset), comment from the comment field is used
  • UI: When a TDS is opened, it must check whether there is new target feedback, i.e., “ReviewState” == 0. If so, a pop-up modal is displayed. The user/reviewer can decide whether they want to view the feedback. If so, the time, comment, and authentication are displayed. The user/reviewer can decide 1. whether they want to “Incorporate” the feedback (sets “ReviewState” to 1), OR 2. reject it (sets ‘ReviewState’ to 2), OR 3. prepare it for development (sets “ReviewState” to 5).

---

Implement Hints and Restrictions that this software is just a prototype:

• reusable pop-up modal: "This software was developed as a prototype for demonstration purposes within a research project. For stable execution, it was only tested with . If you want further development into stable, production-ready software, please contact us: ...contact data."
• Spaces View: 1 space
• User View: 5 additional Users
• Parameter: 1000 parameters over all configs

---

TODOs for further Dev:

• Test and restrict JSONata functionality -> no bad things should happen
• more stable: transactions, separation and no corruption of data if something goes wrong
• AAS completely: transformations, units, etc.
• [ ]