Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend Monitor JSON Data evaluation with additional operators #4614

Open
qu4cks4lb3r opened this issue Mar 24, 2024 · 1 comment
Open

Extend Monitor JSON Data evaluation with additional operators #4614

qu4cks4lb3r opened this issue Mar 24, 2024 · 1 comment
Labels
area:monitor Everything related to monitors feature-request Request for new features to be added type:enhance-existing feature wants to enhance existing monitor

Comments

@qu4cks4lb3r
Copy link

πŸ“‘ I have found these related issues/pull requests

No similar issues / prs found

🏷️ Feature Request Type

Change to existing monitor

πŸ”– Feature description

Current implementation
The monitor type "HTTP(s) - Json Query" allows to add an expression in JSONata format and compare agains an expected value. It is currently only possible to compare the expression via equals.

Requested change
Adding functionality to also allow using other operators such as !=, <, <=, >, >=

Why
It is possible to define a JSONata expression with including the operator into the expression and turn it into a boolean expression that can be compared. However, it would be more clear to add the value to the monitoring configuration itself rather than to the expression. Also that way, the value could be added to the log of the monitor.

βœ”οΈ Solution

For the monitoring type "HTTP(s) - Json Query"

  • Add a new property that holds the compare operator (==, !=, <, <=, >, >=).
  • For not introducing a breaking change, the default operator should be == if not available in an existing configuration.
  • Extend the UI to allow the user to select the operator s/he wants to use for comparison - Default ==

❓ Alternatives

No response

πŸ“ Additional Context

If fine, I'd like to provide a PR for that change. Following the rules for adding PRs, I wanted to clarify if this feature request sounds interesting to the Uptime Kuma team first.

@qu4cks4lb3r qu4cks4lb3r added the feature-request Request for new features to be added label Mar 24, 2024
@CommanderStorm CommanderStorm added area:monitor Everything related to monitors type:enhance-existing feature wants to enhance existing monitor labels Mar 24, 2024
@CommanderStorm
Copy link
Collaborator

Seems like a reasonable change to improve the ergonomics of said feature.
I think squeezing this in before #3919 is possible.

From a UX side: please include this as a drop-down to the value-field.
I think adding a description ( >= value must be greater or equal) in the drop-down is good because otherwise the comparison direction might be beneficial.

qu4cks4lb3r added a commit to qu4cks4lb3r/uptime-kuma that referenced this issue Mar 25, 2024
qu4cks4lb3r added a commit to qu4cks4lb3r/uptime-kuma that referenced this issue Mar 25, 2024
db migration now considers all monitors that have an expected_value and sets the default operator for them
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:monitor Everything related to monitors feature-request Request for new features to be added type:enhance-existing feature wants to enhance existing monitor
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants