#1 ✓closed
Ben Hood

Heat map should should be organized by detection date

Reported by Ben Hood | September 27th, 2010 @ 10:11 AM | in 0.8

At the moment the events in the heat map are arranged by business date. It is probably a better idea to order these by the date that the conflicts occur. For example, if a single error occurs that causes a bunch of entities to conflict, some of these entities could have business dates that are far apart from each other. It would be more intuitive to have these clustered on the point in time that the error occurred - ordering by business date would stretch the heat map in an unintuitive way.

This means a change in the back end and the front end:

  • The session manager should timestamp events as they go into the pending state
  • This timestamp needs to go into the session event
  • The UI needs to group by this timestamp rather than the business date, which is due to be deprecated as a first class attribute (see ticket #2)

Comments and changes to this ticket

  • Ben Hood

    Ben Hood September 27th, 2010 @ 11:20 AM

    • Milestone set to “0.8”
  • Ben Hood

    Ben Hood September 28th, 2010 @ 07:48 AM

    • State changed from “new” to “open”
  • Ben Hood

    Ben Hood September 28th, 2010 @ 07:49 AM

    • Tag set to “kernel”
  • Ben Hood

    Ben Hood September 28th, 2010 @ 08:20 AM

    • Assigned user changed from “Ben Hood” to “Jonathan Lister”

    I've added the timestamp to the session event, hence I'm re-assigning the issue to complete the UI portion of this story.

  • Ben Hood

    Ben Hood September 29th, 2010 @ 08:47 AM

    • Assigned user changed from “Jonathan Lister” to “Ben Hood”
    • Milestone order changed from “1” to “0”

    So it turns out that there is probably an issue with the last detection date for old conflicts. The first cut of this implementation just adds the timestamp of the event as it goes into the session, but this is not so cool for conflicts that are detected a long time before the session was started. Because they would have been detected a long time ago, we should probably persist the original detection time and pass this through to DifferencingListeners.

    Hence I'm reassigning the ticket back myself, although the UI work can still progress based on the first cut of the detection date in the session event.

  • Ben Hood

    Ben Hood September 29th, 2010 @ 12:00 PM

    • Assigned user changed from “Ben Hood” to “Jonathan Lister”

    OK, so I've made the detection date sticky, hence when you poll and receive SessionEvents that are based on old conflicts, the persisted detection date is taken rather than generating one on the fly when the session cache is populated => over to Jonathan to integrate the detectionDate into the UI.

  • Jonathan Lister

    Jonathan Lister September 29th, 2010 @ 10:52 PM

    • State changed from “open” to “resolved”

    Heatmap is ordered by the events' detectedAt property.

  • Ben Hood

    Ben Hood October 28th, 2010 @ 04:24 PM

    • State changed from “resolved” to “closed”

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

A Real Time Differencing Tool.

Shared Ticket Bins

People watching this ticket

Tags

Referenced by

Pages