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)
Release Engineering Graveyard
Applications: Balrog (frontend)
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)
Reporter | ||
Updated•8 years ago
|
Updated•8 years ago
|
Updated•8 years ago
|
Priority: -- → P3
Whiteboard: [lang=js][lang=html][lang=css]
Updated•8 years ago
|
Updated•7 years ago
|
Mentor: bhearsum
Updated•7 years ago
|
Mentor: bhearsum
Comment 1•7 years ago
|
||
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 | ||
Comment 2•7 years ago
|
||
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)
Assignee | ||
Comment 3•7 years ago
|
||
Comment 4•7 years ago
|
||
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)
Assignee | ||
Comment 6•7 years ago
|
||
To be displayed when the rules link is clicked
Assignee | ||
Updated•7 years ago
|
Attachment #8909567 -
Attachment description: Screen Shot 2017-09-19 at 3.03.57 AM.png → New Mockup
Assignee | ||
Comment 7•7 years ago
|
||
Updated•7 years ago
|
Attachment #8907369 -
Attachment is obsolete: true
Flags: needinfo?(bhearsum)
Updated•7 years ago
|
Attachment #8907457 -
Attachment is obsolete: true
Comment 8•7 years ago
|
||
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.
Assignee | ||
Comment 9•7 years ago
|
||
Thanks Ben. I will start implementing it based on your comments.
Comment 10•7 years ago
|
||
This is being worked on in https://github.com/mozilla/balrog/pull/435 and https://github.com/mozilla/balrog/pull/430
Comment 11•7 years ago
|
||
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
Comment 12•7 years ago
|
||
Commit pushed to master at https://github.com/mozilla/balrog
https://github.com/mozilla/balrog/commit/f10a616390deb106c322dc51f6abf6af2606d0aa
bug 1329524: What changed at timestamp UI (#435). r=bhearsum
Comment 13•7 years ago
|
||
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
Updated•5 years ago
|
Product: Release Engineering → Release Engineering Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•