added date of disabled pvs to structural element

[milenaschedle]

If all the leafs of a structural element in the alarm tree have the same enable date, it is displayed next to the name of the component

• Testing:

  • The feature has automated tests
  • [x ] Tests were run
  • If not, explain how you tested your changes

• Documentation:

  • The feature is documented
  • The documentation is up to date
  • Release notes:
    • Added an entry if the change is breaking or significant
    • Added an entry when adding a new feature

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[abrahamwolk]

The comment describing DisableAction.checkEnableDates() states:

Returns true when all leaf items of the same structure either have no enable dates or all the same

Therefore, withEnableDate.iterator().next().getEnabledDate() not throwing an exception here (in the case that there are no enable dates) implicitly depends on leavesDisabledStatusBooleanPair.getValue() being true meaning that there is at least one timer in the sub-tree.

In practice, it seems that DisableAction.checkEnableDates() is used to determine whether there exists one shared enable date for a sub-tree: I suggest to consider changing the signature of DisableAction.checkEnableDates() to something like the following to reflect this:

Optional<LocalDateTime> checkEnableDates(AlarmTreeItem<?>) 

Returning:

1. Optional.empty() if there is no shared enabled date.
2. Optional.of(sharedEnabledDate) if there is a shared enabled date.

This would remove the implicit dependency, also.

[georgweiss]

DisableAction.checkEnableDates() is actually used also for another purpose, which has been a bit lost in the refactoring done in this commit.
I will update to split the required business logic a bit to improve readability.

[abrahamwolk]

I suggest to format the enabled date with second-precision only, i.e., to remove the milliseconds, etc.

I don't know whether it would be a good idea to also implement logic to simplify the date depending on the current date: e.g., if the current date is 2026-07-15 and the enable date is 2026-07-15T10:00:00, perhaps it would simplify the display to only display 10:00:00, or similar.

[georgweiss]

Yes, second precision is sufficient. But I prefer to always use the same format for the sake of consistency.