Skip to content

Add filters to the Jobs page by profile, repository and status. - #2565

Open
ebuzerdrmz44 wants to merge 1 commit into
borgbase:masterfrom
ebuzerdrmz44:refactor/scheduler-jobs-filter
Open

ebuzerdrmz44 wants to merge 1 commit into
borgbase:masterfrom
ebuzerdrmz44:refactor/scheduler-jobs-filter

Conversation

@ebuzerdrmz44

Copy link
Copy Markdown
Contributor

Description

Adds filtering to the Jobs page, the third bullet of goal 3 in #2360.

ezgif-7650c02577ff5bb1

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 JobsFilterProxyModel in views/partials/jobs_filter_proxy.py. It subclasses the existing SortProxyModel to keep the UserRole sorting, and adds filterAcceptsRow. 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:

  • Status is filled once from JobModel.Status. This way every status can be picked even when no row has it right now (running and completed only appear while a backup is in flight).
  • Profile and repository are rebuilt from the values in the current rows, because those can be anything. On rebuild the current selection is kept, even if no row has that value anymore. One case where this happens: arm_profile emits schedule_changed and 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 raw JobRow value the model already exposes for sorting) instead of the DisplayRole text. 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.Type has 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

  • The profile filter uses profile_name. If a profile is renamed, its history shows up as two entries. Both sides have the stable id, but JobRow doesn't carry it, and changing JobRow felt like too much for a filter PR. I can do it here if you prefer.
  • running, completed and interrupted have 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.
  • Rows without a profile or repository only show under "All". There is no "(none)" entry.

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:

  • Backup is the only job type right now, and re-queueing a failed backup would do the same thing as pressing "Start Backup" on that profile.
  • I'm not sure what cancelling a pending run should mean. It could skip only that run, pause the profile, or turn off the schedule. Turning the schedule off is already on the Schedule tab, and the scheduler already has its own pause logic. The only new behavior would then be skipping a single run, but still I am not sure about that.

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 how SortProxyModel is tested with its own models.

tests/unit/test_schedule.py covers the page side: a reload keeps the selection, and a value that leaves the rows doesn't get dropped.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant