-
Notifications
You must be signed in to change notification settings - Fork 240
feat(api): add eventlog listing #8381
feat(api): add eventlog listing #8381
Conversation
Resolves: MON-4866, MON-4867
Resolves: MON-4866, MON-4867
…ntreon/centreon into MON-4866-add-eventlog-listing
…TranslateSortParameterToSql
* fix(ldap): use define user member_attribute var * fix(code): use PSR2
* fix(code): dedicated meta event console does not exist anymore * fix(code): scheduling queue console does not exist anymore * fix(code): merge some cases Co-authored-by: Colin Gagnaire <cgagnaire@centreon.com>
Refs: MON-7944
* feat(doc): update the API documentation Resolve MON-4887 * fix(doc): apply feedback from PR Resolve MON-4887
src/Centreon/Domain/Monitoring/Interfaces/TimelineRepositoryInterface.php
Show resolved
Hide resolved
protected function generateCommentsQuery(StatementCollector $collector, int $hostId, int $serviceId = null): string | ||
{ | ||
$sql = "SELECT | ||
CONCAT('C', c.comment_id) AS `eventId`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO, eventId should be an integer from only eventId
The unique id will be the association between eventType and eventId
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this way it wouldn't be unique :) we just needed 1 field that is unique for every timeline set of data
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can do a unique identifier based on two fields
For instance, if we want to get information of a specific event, the controller will look like:
monitoring/events/{type}/{id}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you, but this 'eventId' property does not need to be used if FE don't need it, and can be removed later if we decide it is useless. For now it does not hurt to have it, because I believe every listing endpoint had to have unique identifier for each row of returned info (due to FE requirements). If that is not the case I can always just omit it from the return of the endpoint. It does not create extra load, it does not mess with any business logic, so in a future refactor we can just remove it easily.
Co-Authored-By: Kevin Duret <kduret@centreon.com>
…terface.php Co-Authored-By: Kevin Duret <kduret@centreon.com>
….php Co-Authored-By: Kevin Duret <kduret@centreon.com>
Resolves: MON-4866, MON-4867
Co-Authored-By: Kevin Duret <kduret@centreon.com>
…terface.php Co-Authored-By: Kevin Duret <kduret@centreon.com>
….php Co-Authored-By: Kevin Duret <kduret@centreon.com>
…ntreon/centreon into MON-4866-add-eventlog-listing
Description
Add endpoint to allow retrieving event timeline for hosts and services
Fixes # MON-4866,MON-4867
Type of change
Target serie
How this pull request can be tested ?
Visit the endpoint using GET:
http://host/centreon/api/beta/monitoring/hosts/14/services/19/timeline
http://host/centreon/api/beta/monitoring/hosts/14/timeline
Checklist
Community contributors & Centreon team
Centreon team only