BUGFIX: Use correct color for timed visibility icon#4003
Conversation
| const hasTimeableNodeVisibility = node?.properties?._hasTimeableNodeVisibility; | ||
|
|
||
| if (hasTimeableNodeVisibility) { | ||
| const circleColor = isDisabled ? 'error' : 'primaryBlue'; |
There was a problem hiding this comment.
The internal logic of timable node visibility has changed. That's why this also has changed. The state is rather depending on the actual visibility state (disabled/enabled) than the "calculated" state based on the datetime.
There was a problem hiding this comment.
But that also means, the editor has to wait for the job to run so they can see the real state.
What happens if they set hidden manually, the job would then change the value, correct?
There was a problem hiding this comment.
Yes, correct. As I wrote in the issue:
IIRC we discussed a feature for the UI to show a warning if the current state is not correct (e.g node is visible, but the enableAfter is in future etc). But I couldn't find any issue for this.
There was a problem hiding this comment.
We could use this change for that, as it would be more or less the same code ?
There was a problem hiding this comment.
I guess so. Would be a feature and we would need some idea how we want to display that.
There was a problem hiding this comment.
But I think your solution does not cover all scenatios atm. Please check the tests in the neos/timeable-node-visibility package: https://github.com/neos/timeable-node-visibility/blob/9.0/Tests/Behavior/Features/HandleExceeded.feature
There was a problem hiding this comment.
And the backend implementation to determine the state: https://github.com/neos/timeable-node-visibility/blob/9.0/Classes/Service/TimeableNodeVisibilityService.php#L129-L154
2 participants
What I did
This fixes a regression introduced with 43efd9c
Resolves: #3997
How I did it
Readded some of the necessary code from 8.3 and adjusted it to the new visibility property names.
How to verify it