I would very much like an evaluation of player / record history widget behavior when a trigger is configured to write a value to a table and the identical value is already in the data base field. I am on LTS 10.6.
My example are apps which record the last action performed on an artifact. In below example a clipout of the trigger that is storing the last action. This is purely an example. I see exact same behavior of all data types and contexts.
When the user performs same action twice the record history fails to reflect this. This is in my view a data integrity issue, which should be evaluated by product team. The trigger is not requesting a potential update but to store a value in a table.
First time around the system logs the data change correctly:
But if the same person executes the same activity again the system reflects only the change of time stamp.
This might be viewed as a benign example but if I log pH values, buffer lots or similar the record history widget would only show partial data of app behavior, and we potentially have to scroll backwards in time to figure out what the full data set is. The history should in my view reflect what the app directed to happen of data placed in tables.
I am not blind to the fact that the record history widget say “Updated record” but is this really the intended behavior? Can the Tulip instance be configured to make the record history widget show the stored data as directed by the trigger?
It is hard to use the history widget as a tool to show what happens on shop floor when it chooses to only show a partial truth and we have to contextualize the rest of the data set by scrolling through the log.
If it gets an overhaul please add to Record history widget - additional configuration list of possibilities. The alternative is that we create a separate log table and reconfigure the triggers to store the actions there instead, but we have previously been told that this is not the best practice use of system.
As you are using the same record placeholder (the same database line), it will only display the delta (changes) in the record history widget.
As you know you will be updating the your last action filed + date + user each time, I would suggest to do the following:
-In a first trigger, you will use the Data Manipulation → Clear on Record → Last Action + Date + User
-On a second trigger, you will set your values as expected (with pH)
-On the Record History widget, you can filter out results with Last action has Null value or is blank (same for date and user).
I understand your suggestion as a workaround. If that was the correct use of Tulip then the system knowledge base and training would include that when an app is developed for a GXP environment it should clear data before running triggers to store data.
I agree that this will make the record history not loose data. We would need to remove the data just before placing new data into the table because if I it happens too early and end user changes their mind and navigate back to the overview screen then the data is removed unintentionally.
But following your idea I placed a separate trigger just before data population which clears data:
The applied filtering of history widget appear I assume you would use below filtering option
But it actually doesnt have the desired effect. Maybe we are in the area of blank vs null (blank is not a filtering option). What filtering would you apply?
I did some testing, the only way I found was actually not to use the clear function.
-Set Last action value as to be deleted or any other dummy text.
-In your History widget select does not contain static value to be deleted as filter for the last action.
Sorry, it is a workaround of a workaround.
I believe there is something not working with the “is not null” filter of the History widget.
