Closed Bug 1329524 Opened 8 years ago Closed 7 years ago

Create UI to answer questions 'what changed at <timestamp>'

Categories

(Release Engineering Graveyard :: Applications: Balrog (frontend), defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nthomas, Assigned: hope.ngerebara)

References

Details

(Whiteboard: [lang=js][lang=html][lang=css])

Attachments

(3 files, 2 obsolete files)

The history for individual rules and releases are available available in the Balrog Admin UI, but there's no way I can think of to see a global changelog/audit trail (other than accessing the DB directly). For debugging of issues, or 'ZOMG we are so broken right now' panics it would be helpful to be able to see what changes were made to the DB. For example, we're offering <something> to <someone> that we shouldn't, and it started <some time> ago --> go look at the changelog to see what was modified then. There are many ways we could filter, which we'll need because there are some very noisy times/users (ie localized nightly & releases submission). Eg: * time window: both start/stop * change type: release/rule/permission/scheduled change/... (checkbox) * product/channel/... (like rules filtering) * user who made change (eg exclude automated accounts)
Priority: -- → P3
Whiteboard: [lang=js][lang=html][lang=css]
Mentor: bhearsum
Mentor: bhearsum
I think this is implied in comment #0, but just to state it outright: I think this is best implemented as a new page in the UI that pulls from all of the History tables, and applies whatever filters are given. It would probably be best to allow the User to filter prior to making any network requests, because we could probably reduce the number of requests made by letting filtering happen first.
Priority: P3 → P1
Assignee: nobody → hope.ngerebara
Attached image UI mockup (obsolete) (deleted) —
This is the mockup I came up with for the UI. Please let me know what to discard or improve on. Thanks
Flags: needinfo?(bhearsum)
Attached image mockup 2 (obsolete) (deleted) —
These looks like a decent start. Some questions/comments: - I'm only seeing examples of Rules being shown in the list of changes. Can you add some examples of other objects, too, so we can see how that may look? The crucial part of this UI is that it is a unified view of changes to any table, not just one. - Is there a reason to limit a user to just one of the filters? Given Nick's example from comment #0, I think we have use cases that would require the use of multiple filters. - The date filter needs to support a time range. Ideally, we'd support both including changes from a time range, and excluding them. - The user filter needs a way to specific multiple users, and do excluding. - Will the product/channel filter work like the one on the Rules page, and also include entries for entire products?
Flags: needinfo?(bhearsum)
Attached image New Mockup (deleted) —
New mockup
Flags: needinfo?(bhearsum)
Attached image Rules modal (deleted) —
To be displayed when the rules link is clicked
Attachment #8909567 - Attachment description: Screen Shot 2017-09-19 at 3.03.57 AM.png → New Mockup
Attachment #8907369 - Attachment is obsolete: true
Flags: needinfo?(bhearsum)
Attachment #8907457 - Attachment is obsolete: true
These new mockups look much improved. A few more comments: * I think it would be better to replace the "History Type" with "Object". The data in the rows should have a bit of identifying information, too. For example, for Rules I think this would be product+channel+alias if present, or rule_id if not. For releases, the name would suffice. * I don't think the "Status" column will make sense here -- only the Scheduled Changes tables have them. * We need to allow users to filter by timestamps all the way down to the second. * Please ensure that filtering by object type is supported. If you'd like to do another mock up with these in mind feel free, but as far as I'm concerned you're welcome to skip that and start implementing this as long you keep these comments in mind.
Thanks Ben. I will start implementing it based on your comments.
Commit pushed to master at https://github.com/mozilla/balrog https://github.com/mozilla/balrog/commit/b97d1c70ba4489976333ab9b96bcaacbfc41c944 bug 1329524: Add central history endpoint to support new history UI (#430). r=bhearsum
This is in production now. I expect follow up work to come up (eg: https://bugzilla.mozilla.org/show_bug.cgi?id=1447764), but it's probably best to track it in individual bugs. Thank you for all of your hard work here Hope!
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Product: Release Engineering → Release Engineering Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: