Hi Dojo,
Would there be room to consider this feature suggestion for 2024?
https://community.dataminer.services/new-feature-suggestions/mask-alarm-element-until-date-time-calendar-selection/
The main benefit would be to quickly mask elements or alarms without having to calculate how many hours or days need to elapse until monitoring should be restored.
The "mask" wizard gui has just a slider or the text box to specify duration:
It would help to add also an option that allows operators to quickly select a date and a time.
A calendar icon could be just at the side of the slider, without taking much space:
Leaving here for evaluations.
Thanks
Thank you Alberto, I'm aware that the UX of our time range selector is not great. I understand that in the context of masking just selecting a end date is sometimes easier.
There might be something quick we can do in our client applications to let the user enter the end time/date, but towards the server this would still resolve to a time range (starting at the point when it is received). That could result in small offsets towards the entered date/time.
Ex.
You enter 'Tomorrow, 9:00' as planned end date/time. If you enter that today at 8:00, the time range passed to the server is 25 hours. But it is received at the server at 8:01, so actually the masking would be done until tomorrow 9:01.
Would that be acceptable or are you really looking for exact end date/time execution?
Hi Alberto,
Ideally we don’t have to change the server, so that’s was why I was looking what we could do in the client. The API on the server only allows timerange and not end date/time, so that’s why I was looking into something where we can make that transformation in the client. But with that, we can have the offset (depending how long the user needs to enter his stuff and apply his changes)
Regarding your PS, feel free to forward me your top 3 ‘New feature’ requests 😉
Thanks for the prompt feedback, Pieter.
Indeed I was also thinking about something similar, so that users can specify a date & time via their client and the server will calculate the related time range.
Client & servers can have different time settings in some environments (this is handled via CUBE time settings), so letting the server work out the timing, based on cluster time settings, looks the best option.
A small offset of 1 min could be handled – and it if it is always 1 min, we could enter “Tomorrow 8:59” to trigger the “unmasking” at “9:00” sharp – no problem.
Even better if when selecting e.g. “2023, DEC 31st, 23:59:59UTC”(*) this could be handled with the granularity/accuracy of 1 second.
(*)PS: I’m clearly looking forward to all the new features we’ll have in 2024 (;