Refactor status classification

[JavierGOrdonnez]

• centralizes all frontend status handling into a single place (easier to maintain)

• Fixes error in the backend when the jobs have the new status type (a dict instead of a string) - this was generating the sporadic error in SuMo validation

[Copilot]

Pull Request Overview

This PR centralizes frontend status handling into a single place by creating a unified status classification system, and fixes a backend error where jobs with the new status type (dict instead of string) were causing sporadic validation errors.

• Introduces extractJobStatus function to handle both string and object status formats
• Refactors all status classification logic to use the new centralized approach
• Adds backend status extraction function to handle dict-formatted job statuses

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
node/src/utils/function_utils.ts	Adds centralized status extraction and classification functions
node/src/components/data/JobSelector.tsx	Updates all status checks to use new extraction function
node/src/components/data/JobRow.tsx	Simplifies status handling using centralized approach
flaskapi/flask_workflows.py	Adds backend status extraction to handle dict-formatted statuses

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[alexpargon]

this was done with more changes on the #419 PR, avoid merging it

[JavierGOrdonnez]

@alexpargon merged your changes and added those that were relevant. I think it is still useful to clearly separate the logic from the component / context that is using it - specially as status is currently checked in two places and potentially could be checked in more.

[Copilot]

Pull Request Overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 8 comments.

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[JavierGOrdonnez]

reviewed all changes, it seems coherent to me. Feel free to comment / ask for changes, and test yourself on (local) osparc deployment (run a few more samples) before merging.

[alexpargon]

this filter does not take into account other failed states, like:

else if (["FAILED", "ABORTED"].includes(jobStatus) || (jobStatus.startsWith("JOB_") && jobStatus.endsWith("_FAILURE")))

and endsWith should not be used unless everytime you use that element in the same position

[alexpargon]

The autoSelectJobs functions should not be removed but implemented, it was disabled as the feature which should automatically select the in-range jobs is not present, but due the fact that after every selection / deselection of a job, we refresh the moga, we should re-activate this and do it properly to save time for the user

[alexpargon]

This line catches everything that starts with JOB_ as PENDING, but JOB_ can have FAILED / FAILURE at the end or other states, so it should not only filter for the starting section with an OR (even tho the FAILURE / FAILED state is removed before in another IF statement, in the future we may add more states and they will be catched here without intention)