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

Jump to bottom

[dev.icinga.com #11629] Simplified event-history date and time representation #2397

Closed
icinga-migration opened this issue Apr 20, 2016 · 10 comments
Closed

[dev.icinga.com #11629] Simplified event-history date and time representation #2397

icinga-migration opened this issue Apr 20, 2016 · 10 comments
Labels
area/ui Affects the user interface enhancement New feature or improvement
Milestone
2.3.2

Comments

@icinga-migration
Copy link

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

Created by Tux12Fun on 2016-04-20 11:03:21 +00:00

Assignee: aklimov
Status: Resolved (closed on 2016-04-26 10:25:03 +00:00)
Target Version: 2.3.2
Last Update: 2016-04-26 10:52:43 +00:00 (in Redmine)

Hi,

my colleague asked me to have a look if a Service "xy" had a Problem at 12.04.2016 22:00.

It's very difficult to find such events if you have only have a view like: before 1 day 4 Hours or before 10th of April.

It would be nice if we could see Timestamps like 2016-04-12 22:00:00
and if we would be able to search through the events.

And please display the Filter for 10, 25, 50 ... 500 (all events) at the History page.
Modifying the URL isn't a nice thing for a user of the Gui.

Attachments

Changesets

2016-04-22 15:15:19 +00:00 by aklimov 6df8c37

Event history: display a heading above each group of events (WIP)

refs #11629

2016-04-25 08:34:07 +00:00 by aklimov babaf15

Event history: group events always by day

refs #11629

2016-04-25 08:47:46 +00:00 by aklimov 062cb30

Event history: make ASC sort working

refs #11629

2016-04-25 09:07:17 +00:00 by aklimov a847e10

Event history: improve performance per request

refs #11629

2016-04-25 10:29:07 +00:00 by aklimov c8b8618

Event history: print date headings verbosely

refs #11629

2016-04-25 10:30:50 +00:00 by aklimov b4ffe5a

Event history: preserve translation domain

refs #11629

2016-04-25 11:28:11 +00:00 by aklimov 0ffb58b

Event history: show the absolute time of events

refs #11629

2016-04-25 12:21:37 +00:00 by aklimov 25185b9

Event history: use strftime() instead of DateTime::format() for date headings

refs #11629

2016-04-26 09:34:10 +00:00 by aklimov 098eff9

Event history: preserve translation domain

refs #11629

2016-04-26 09:38:24 +00:00 by aklimov 531d999

Event history: show the absolute time of events

refs #11629

2016-04-26 10:09:40 +00:00 by aklimov 809c2d0

Event history: display a heading above each group of events (by day)

refs #11629

2016-04-26 10:20:01 +00:00 by aklimov 1bef896

Merge branch 'feature/simplified-event-history-date-and-time-representation-11629'

resolves #11629

Relations:
@icinga-migration
Copy link
Author

Updated by jmeyer on 2016-04-21 07:46:59 +00:00

Hi,

Tux12Fun wrote:

my colleague asked me to have a look if a Service "xy" had a Problem at 12.04.2016 22:00.

It's very difficult to find such events if you have only have a view like: before 1 day 4 Hours or before 10th of April.

It would be nice if we could see Timestamps like 2016-04-12 22:00:00
and if we would be able to search through the events.

That's reasonable, but I guess not the common case. I mean, "scanning" the history. If a user needs to got that far back, he'll most likely know exactly how far. And that's even the case for you: 2016-04-12 22:00:00

There's a feature open #10026 which is meant to improve this. For the meantime, convert this manually to a unix timestamp like so: timestamp>=1460496600&timestamp<=1460493000
This will show you only events between 2016-04-12 21:30:00 and 2016-04-12 22:30:00.

Tux12Fun wrote:

And please display the Filter for 10, 25, 50 ... 500 (all events) at the History page.
Modifying the URL isn't a nice thing for a user of the Gui.

Waiting ages for a response isn't a nice thing either. ;) We removed this for a good reason: performance
Counting thousands or even millions of history entries is pretty expensive, just to show the user a nice paginator at the top of the page. And any input causes the same process to start again. A database that is handling such requests is having a really bad time. And, well, "(all events)" will most likely kill your browser.

You don't have to adjust the url manually, just scroll down to the bottom of the page and the next page of results should be shown automatically.

I'll close this as duplicate of #10026. If you have further questions, feel free to further ask them here.

Best regards,
Johannes

@icinga-migration
Copy link
Author

Updated by jmeyer on 2016-04-21 07:47:15 +00:00

  • Duplicates set to 10026

@icinga-migration
Copy link
Author

Updated by jmeyer on 2016-04-21 07:47:33 +00:00

  • Category deleted UI
  • Status changed from New to Closed

@icinga-migration
Copy link
Author

Updated by jmeyer on 2016-04-21 08:47:29 +00:00

  • Subject changed from Make History Time useable to Simplified event-history date and time representation
  • Category set to UI
  • Status changed from Closed to New
  • Target Version set to Backlog

Hi again,

I'll re-open this as I had a discussion with a colleague myself. He has got an idea on how to improve the layout of the event history some time earlier which he will attach later today in this issue.

Best regards,
Johannes

@icinga-migration
Copy link
Author

Updated by tgelf on 2016-04-21 09:06:22 +00:00

  • File added icingaweb2_historylist_proposal.png
  • Category deleted UI
  • Target Version deleted Backlog

Hi Tux12Fun,

please have a look at the attached screen-shot. It shows a prototype created pre 2.1, a version that brought a lot of UI changes. The prototype was forgotten afterwards. With the current version titles would look different and the time would be shown below object state. However, I guess something like this would make "scan history with your eyes" much easier.

@Tux12Fun: could something like this be what you're trying to get? Regardless of visualization, we need of course better controls allowing us to choose specific time ranges in an efficient way.

I'd also opt for re-adding the "limit" control (but not the pagination). These are distinct beasts, limit controls how many rows to fetch at once, even when scrolling down. It doesn't involve evil "count" queries as a pagination showing a total page count does.

Cheers,
Thomas

NB: One last note, as performance was mentioned -> we should get rid of permission-related joins when showing history for single objects. Permission control already took place when you arrive there. So this allows for much, much faster queries.

@icinga-migration
Copy link
Author

Updated by jmeyer on 2016-04-22 09:06:01 +00:00

  • Category set to UI
  • Status changed from New to Assigned
  • Assigned to set to aklimov
  • Target Version set to 2.3.2

@icinga-migration
Copy link
Author

Updated by Tux12Fun on 2016-04-22 10:34:01 +00:00

I got a feedback of my colleague. This kind of view would be very usefull.

@icinga-migration
Copy link
Author

Updated by aklimov on 2016-04-25 12:25:11 +00:00

  • Status changed from Assigned to Feedback
  • Assigned to changed from aklimov to jmeyer

@icinga-migration
Copy link
Author

Updated by aklimov on 2016-04-26 10:25:03 +00:00

  • Status changed from Feedback to Resolved
  • Done % changed from 0 to 100

Applied in changeset 1bef896.

@icinga-migration
Copy link
Author

Updated by jmeyer on 2016-04-26 10:52:43 +00:00

  • Assigned to changed from jmeyer to aklimov

@icinga-migration icinga-migration added enhancement New feature or improvement area/ui Affects the user interface labels Jan 17, 2017
@icinga-migration icinga-migration added this to the 2.3.2 milestone Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/ui Affects the user interface enhancement New feature or improvement
Projects
None yet
Milestone
2.3.2
Development

No branches or pull requests
1 participant
@icinga-migration