New per-user and per-workflow job pages

[tcompa]

Let's move to two different "jobs" pages: one at the workflow level, and one with all jobs of a user

Per-workflow jobs

1. This fetches all jobs related to a workflow, by fetching all jobs related to the corresponding project and then filtering on fractal-web side. Maybe we can improve this based on Expose per-user and per-workflow GET-job endpoints? fractal-server#920
2. Data are filtered before filling the table, so that the table at first appears as clean (with all filters unset) and the URL does not include any query parameter
3. The header of the page correctly says something like Jobs of workflow "My Workflow Name"
4. The url&breadcrumbs of the page are appropriate (something like project/1/workflow/2/jobs in the URL, and the same structure in the breadcrumbs)
5. A (top-right?) button brings you back to the workflow page
6. The table does not include project and workflow columns

Per-user jobs

1. It is always visible in the top menu, under the "Jobs" name
2. It fetches all user's jobs, by first fetching all user's projects and then fetching all jobs of each project. Maybe we can have a single endpoint for this? (Expose per-user and per-workflow GET-job endpoints? fractal-server#920)
3. It does not apply any filter on the job list
4. It does show project.name and workflow.name columns
5. The header of the page correctly says something like Jobs of user "admin@something.xxx"

Side effects

Other simplifications that are now possible

1. The workflow-apply modal, upon success, redirects to the workflow page (without adding the job-id query parameter to the URL)
2. We can probably fully disable the feature of URL query parameters being turned into table filters
3. We automatically get rid of the "Job ID filters don’t show up in the interface" issue
4. We most likely get rid of the "Transient display of other jobs during refresh: " issue

Related

• Automatic updating of the job page to fetch new status #119
• Always sort by jobs starting from latest start-time #294

[tcompa]

Note: it would make sense to wait for the merge&release of fractal-analytics-platform/fractal-server#923 first, since it may introduce some (minor) breaking changes to the jobs attributes.

[zonia3000]

5. A (top-right?) button brings you back to the workflow page

Is this needed? There is already the breadcrumb that goes back to the workflow page.

[tcompa]

It fetches all user's jobs, by first fetching all user's projects and then fetching all jobs of each project. Maybe we can have a single endpoint for this? (fractal-analytics-platform/fractal-server#920)

This is now available, as of fractal-server 1.4.0a1.
The relevant endpoints (see also https://fractal-analytics-platform.github.io/fractal-server/openapi/) are:

• /api/v1/project/job/
• /api/v1/project/{project_id}/workflow/{workflow_id}/job/

[zonia3000]

I see that using the new version the job status is now stored as an uppercase string. This has an impact on the visualization that I can quickly fix:

However I was wondering if this has been considered as a breaking change and if the statuses of the old jobs should be updated by the database migration procedure. One could be in a mixed situation after upgrading the server.

[zonia3000]

This is now available, as of fractal-server 1.4.0a1. The relevant endpoints (see also https://fractal-analytics-platform.github.io/fractal-server/openapi/) are:

• /api/v1/project/job/
• /api/v1/project/{project_id}/workflow/{workflow_id}/job/

I see that the project type also has the fields workflow_list and job_list on it, so it seems that retrieving the list of projects should be enough to obtain all the information I need. Do you agree?

[tcompa]

However I was wondering if this has been considered as a breaking change and if the statuses of the old jobs should be updated by the database migration procedure. One could be in a mixed situation after upgrading the server.

This is something I also noticed, and I don't think it should be like this. We are looking into it.

[tcompa]

To clarify: let's fully remove the per-project jobs page.

[jluethi]

+1 on we don't need per-project job pages anymore if we have workflow job pages and all jobs (of a user) :)

[tcompa]

I see that using the new version the job status is now stored as an uppercase string. This has an impact on the visualization that I can quickly fix:

However I was wondering if this has been considered as a breaking change and if the statuses of the old jobs should be updated by the database migration procedure. One could be in a mixed situation after upgrading the server.

Could you provide some more details?
I think I saw something similar in the past, but I'm now failing to reproduce it.