Add filters to the Jobs page by profile, repository and status. - #2565
Open
ebuzerdrmz44 wants to merge 1 commit into
Open
ebuzerdrmz44 wants to merge 1 commit into
ebuzerdrmz44 wants to merge 1 commit into
Conversation
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds filtering to the Jobs page, the third bullet of goal 3 in #2360.
The issue lists four filters, not three. Job type is the one I left out, and the reasoning is in "On the choice of filters" below.
How it works
I added
JobsFilterProxyModelinviews/partials/jobs_filter_proxy.py. It subclasses the existingSortProxyModelto keep theUserRolesorting, and addsfilterAcceptsRow. The proxy stores one selected value per column and only accepts a row when all of them match, which means the filters combine as AND. I used one proxy for both sorting and filtering instead of chaining two, and the view still has a single model in between.The combos are filled in two different ways:
JobModel.Status. This way every status can be picked even when no row has it right now (runningandcompletedonly appear while a backup is in flight).arm_profileemitsschedule_changedand returns early when a profile has no repo or scheduling is off. A profile's only row can leave the table because of that event, and without this the filter would jump back to "All" on its own.Rows are matched on
Qt.UserRole(the rawJobRowvalue the model already exposes for sorting) instead of theDisplayRoletext. If a cell gets translated or formatted differently later, the filters should still work.Which filters
Open question 2 in #2360 asks which filters matter most. I picked profile, repository and status because the table already has those columns. I don't really have evidence they are the best ones. I can drop any of them, or add a time range if you think that would be more useful.
I left out the job type filter, even though the issue mentions it.
JobModel.Typehas only one member right now and every writer hardcodes it (and #2560 doesn't add a new type either). The combo would only offer "All" and "backup", both showing the same rows, and it would take up a quarter of the filter row. The Type column is still in the table and the proxy works with any column. Adding the combo later is a few lines once a second type exists. If you'd prefer to have it now as a placeholder, I can add it.Known limitations
profile_name. If a profile is renamed, its history shows up as two entries. Both sides have the stable id, butJobRowdoesn't carry it, and changingJobRowfelt like too much for a filter PR. I can do it here if you prefer.running,completedandinterruptedhave no writer on master yet, and selecting them shows an empty table for now. extract Execution and close the job lifecycle (#2360, goal 2) #2560 adds the writers. I listed them already to keep the combo from changing when that lands.What's left of #2360:
I didn't do cancelling a pending run or re-queueing a failed one (the fourth bullet of goal 3). Would it be okay to skip this item? My reasons:
If it turns out to be needed later, it could go in its own issue if you want.
After that is skipped or builded , #2360 can be closed .
Tests
The proxy tests are in
tests/unit/test_jobs_table_model.py, next to the model it wraps. That matches howSortProxyModelis tested with its own models.tests/unit/test_schedule.pycovers the page side: a reload keeps the selection, and a value that leaves the rows doesn't get dropped.