Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #3175] Add command "Acknowledge problem for this host and its services" #1121

Closed
icinga-migration opened this issue Sep 25, 2012 · 27 comments
Closed

[dev.icinga.com #3175] Add command "Acknowledge problem for this host and its services" #1121

icinga-migration opened this issue Sep 25, 2012 · 27 comments
Labels
Commands enhancement Low
Milestone
1.14

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/3175

Created by ossmon on 2012-09-25 13:38:24 +00:00

Assignee: ricardo
Status: Closed (closed on 2016-09-22 18:41:23 +00:00)
Target Version: 1.14
Last Update: 2016-09-22 18:41:23 +00:00 (in Redmine)

Add host command "Acknowledge problem for this host and its services" as the already existing command "Schedule a downtime for this host and its services" in order to acknowledge with one command a host and all his services.

Changesets

2015-05-07 22:12:02 +00:00 by ricardo 484c54a

Classic UI: add possibility to acknowledge host and all its services with one command #3175

It is now possible to acknowledge a problem host and all its services
with one action. Available in extinfo.cgi and status.cgi with
multi select.

Refs: #3175

2015-11-19 21:36:58 +00:00 by ricardo 4adcf06

Classic UI: add possibility to acknowledge host and all its services with one command #3175

It is now possible to acknowledge a problem host and all its services
with one action. Available in extinfo.cgi and status.cgi with
multi select.

The command handling has been in the core for a while now. Only the GUI part was missing.
This command is disable if backend is not Icinga 1.
Refs: #3175

2015-11-19 23:41:47 +00:00 by ricardo 4975667

and here are the additinal changes for last commit

Refs: #3175
@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-10-11 22:01:35 +00:00

there is currently no core command support that behaviour like SCHEDULE_HOST_SVC_DOWNTIME - better having the core handle that one imho.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-04-08 21:18:06 +00:00

  • Project changed from Web to Core, Classic UI, IDOUtils

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-06-29 15:15:14 +00:00

  • Category set to Commands
  • Status changed from New to Assigned
  • Assigned to set to h4ck3rm1k3

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-06-29 15:15:25 +00:00

please evaluate.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-09-21 17:15:57 +00:00

  • Assigned to changed from h4ck3rm1k3 to elagon

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-09-27 21:11:39 +00:00

  • Target Version set to 1.11

@icinga-migration
Copy link
Author

Updated by elagon on 2013-10-03 10:27:49 +00:00

  • Done % changed from 0 to 10

Working on it

@icinga-migration
Copy link
Author

Updated by elagon on 2013-10-03 13:11:52 +00:00

  • Done % changed from 10 to 50

Implementation in feature/acknowledge-problem-for-hosts-and-its-services-3175
Should work, testing now

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-10-22 12:28:28 +00:00

  • Assigned to changed from elagon to ricardo

@ricardo

please proceed with testing and evaluate if that one makes sense as gui command.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2014-01-03 20:18:40 +00:00

  • Priority changed from Normal to Low

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2014-03-03 18:54:02 +00:00

  • Target Version changed from 1.11 to 1.12

feature freeze 1.11

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2014-12-08 08:54:24 +00:00

  • Target Version changed from 1.12 to 1.12.1

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2014-12-08 09:06:49 +00:00

  • Target Version changed from 1.12.1 to 1.13

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-02-14 23:06:25 +00:00

  • Target Version changed from 1.13 to Backlog

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-05-01 10:59:41 +00:00

  • Target Version deleted Backlog

@icinga-migration
Copy link
Author

Updated by ricardo on 2015-05-07 22:24:49 +00:00

  • Status changed from Assigned to Feedback
  • Done % changed from 50 to 90

Added to "feature/add-CMD_ACKNOWLEDGE_HOST_SVC_PROBLEM-to-cgi-3175"

Needs to be added to docs if not already done.

It is now possible to acknowledge a problem host and all its services
with one action. Available in extinfo.cgi and status.cgi with multi select.

Please test.

Cheers
Ricardo

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-05-08 12:17:25 +00:00

Your change in base/commands.c is wrong - the host is already acknowledged after the services loop.

@icinga-migration
Copy link
Author

Updated by ricardo on 2015-05-08 20:47:48 +00:00

dnsmichi wrote:

Your change in base/commands.c is wrong - the host is already acknowledged after the services loop.

??? I don't understand. Check the change again!

CMD_ACKNOWLEDGE_HOST_SVC_PROBLEM always includes a expire TS. The change honors this behavior.

Cheers
Ricardo

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-05-08 21:14:24 +00:00

Sorry, looked at the wrong if condition.

Though I don't think it's correct to always pass an expire time to this command w/o _EXPIRE suffix similar to the existing commands already existing.

@icinga-migration
Copy link
Author

Updated by ricardo on 2015-05-08 21:43:51 +00:00

Well, I introduced the *_EXPIRE commands only to keep backwards compatibility. So you have the regular one and the one with aded expire TS. In this case it's not needed as it's a complete new command.

if TS = 0 then no expire time otherwise see if TS is in future and set expire.

Cheers
Ricardo

@icinga-migration
Copy link
Author

Updated by berk on 2015-05-18 12:17:36 +00:00

  • Target Version set to Backlog

@icinga-migration
Copy link
Author

Updated by ricardo on 2015-11-14 21:04:03 +00:00

why did this feature never made it into master?

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-11-14 23:18:44 +00:00

Mainly for the reason that I do not want to extend the external command api anymore which would certainly open demands for adding those to Icinga 2. Given what's possible with the Icinga 2 API and filtered actions I don't think it is worth the effort changing and maintaining commands in core 1.x and the command pipe.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-11-14 23:19:31 +00:00

  • Status changed from Feedback to Closed
  • Assigned to deleted ricardo
  • Target Version deleted Backlog

@icinga-migration
Copy link
Author

Updated by ricardo on 2015-11-16 23:26:15 +00:00

  • Status changed from Closed to Feedback

Can I add it to Icinga 1 and hide the controls if backend is Icinga 2.

would be quite useful in Icinga 1

@icinga-migration
Copy link
Author

Updated by ricardo on 2015-11-19 21:41:03 +00:00

  • Assigned to set to ricardo
  • Target Version set to 1.14
  • Done % changed from 90 to 100

Now in icinga-core/master.

This command is not visible if the backend is not Icinga 1.

Cheers
Ricardo

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-09-22 18:41:23 +00:00

  • Status changed from Feedback to Closed

@icinga-migration icinga-migration added this to the 1.14 milestone Jan 17, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
Commands enhancement Low
Projects
None yet
Milestone
1.14
Development

No branches or pull requests
1 participant
@icinga-migration