fixes #36, #997 respect workflow displayOrder, add filter workflows

[JamesUoM]

Respect workflow displayOrder
Add filter workflows by displayOrder (min/max config settings)

UoM: MAT-477, MAT-478

[JamesUoM]

deploy.opencast.org only has one workflow. To help with testing you can inject a dummy workflow by editing
src/main/WorkflowSelection.tsx

    const filterWorkflows = (workflowFilter: IWorkflowConfiguration | undefined, workflows: Workflow[]) => {
    // DEBUG
    let w : Workflow = {
      id: "1235",
      name: "test workflow",
      description: "bobbins",
      displayOrder: 600
    }

    workflows = [workflows[0], w]
    ...

[github-actions]

This pull request is deployed at test.editor.opencast.org/1101/2023-07-06_11-20-09/ .
It might take a few minutes for it to become available.

[Arnei]

Could you add the new settings to the public/editor-settings.toml as well?

I can crash the editor with the following setting

min = 1001
max = 1000

Results in this error:

Uncaught TypeError: Cannot assign to read only property '0' of object '[object Array]'
    at Array.sort (<anonymous>)
    at WorkflowSelection (WorkflowSelection.tsx:58)

I have four workflow configured, with displayOrder values 1010, 1000, 100 and no value.

[Arnei]

Small remark: The editor has been respecting displayOrder, but apparently been sorting the wrong way around:

opencast-editor/src/redux/videoSlice.ts

Line 215 in 897d4f5

state.workflows = action.payload.workflows.sort((n1: { displayOrder: number; }, n2: { displayOrder: number; }) => {

. I suppose that code can go then.

[JamesUoM]

I have four workflow configured, with displayOrder values 1010, 1000, 100 and no value.

It's not the min>max but something weird triggered by the sort() when a displayOrder is undefined. You can't sort "in place" and need to create a copy.

min>max results in zero workflows selected and so the warning is issued and all workflows are returned.

[github-actions]

This pull request is deployed at test.editor.opencast.org/1101/2023-07-10_14-53-55/ .
It might take a few minutes for it to become available.

[lkiesow]

No complaints about respecting display order, but I'm really not sure about the filtering.

[lkiesow]

I'm not sure if this really makes sense and would like to hear your reasoning behind this. I find this extremely unintuitive. Why should the order determine if a workflow is being shown or not? As an admin, I could see it easily happen that I want to change the order and this causes the workflow to accidentally disappear.

More than that, with the old editor being sunsetted and about to be removen, the new editor is the only place in Opencast where the tag editor is being used. This means that you can just tag the workflows and only the workflows you want to be shown as editor.

This is much more straightforward ans also means that the same functionality is not being duplicated (you are essentially trying to add a second configuration option which does the same thing as an existing one).

That means, unless you have a good argument for adding this, I really think we shouldn't add this.

[JamesUoM]

Fair point, this may not be for everyone. We would have to address the issue of unwanted editor workflows (ie the default ones) in the end-user editor by other means.

-- ------------------------------------------------------------------------ James S. Perrin Media Technologies Team Office One, Kilburn Building, The University of Manchester Oxford Road, Manchester, M13 9PL e: ***@***.***

________________________________ From: Lars Kiesow ***@***.***> Sent: 14 August 2023 10:55 To: opencast/opencast-editor ***@***.***> Cc: James Perrin ***@***.***>; Author ***@***.***> Subject: Re: [opencast/opencast-editor] fixes #36, #997 respect workflow displayOrder, add filter workflows (PR #1101) @lkiesow requested changes on this pull request. No complaints about respecting display order, but I'm really not sure about the filtering.

________________________________ In editor-settings.toml [github.com]<https://urldefense.com/v3/__https://github.com/opencast/opencast-editor/pull/1101*discussion_r1293252615__;Iw!!PDiH4ENfjr2_Jw!AGBAdOfa7MX0Zkdu9X0jQIz6wmGeSgwtZZ7CnMpER0_FO3YrCgriCeCwPVigCRZ2fyydkBCh29n7OxcQS1dEWmm6EjMVjQANLw$>:

+# Filter the publishing workflows by their displayOrder value

+# min <= displayOrder <= max +# Type: number +# Default: undefined (unbound) +#min = +#max = I'm not sure if this really makes sense and would like to hear your reasoning behind this. I find this extremely unintuitive. Why should the order determine if a workflow is being shown or not? As an admin, I could see it easily happen that I want to change the order and this causes the workflow to accidentally disappear. More than that, with the old editor being sunsetted and about to be removen, the new editor is the only place in Opencast where the tag editor is being used. This means that you can just tag the workflows and only the workflows you want to be shown as editor. This is much more straightforward ans also means that the same functionality is not being duplicated (you are essentially trying to add a second configuration option which does the same thing as an existing one). That means, unless you have a good argument for adding this, I really think we shouldn't add this. — Reply to this email directly, view it on GitHub [github.com]<https://urldefense.com/v3/__https://github.com/opencast/opencast-editor/pull/1101*pullrequestreview-1576513211__;Iw!!PDiH4ENfjr2_Jw!AGBAdOfa7MX0Zkdu9X0jQIz6wmGeSgwtZZ7CnMpER0_FO3YrCgriCeCwPVigCRZ2fyydkBCh29n7OxcQS1dEWmm6EjN6Yos1NA$>, or unsubscribe [github.com]<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AAWQ6E7NNJA5LWPYRBSDOE3XVHY2NANCNFSM6AAAAAA2AIPYPM__;!!PDiH4ENfjr2_Jw!AGBAdOfa7MX0Zkdu9X0jQIz6wmGeSgwtZZ7CnMpER0_FO3YrCgriCeCwPVigCRZ2fyydkBCh29n7OxcQS1dEWmm6EjMOi9SLVQ$>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[github-actions]

This pull request has conflicts ☹
Please resolve those so we can review the pull request.
Thanks.

[KatrinIhler]

@JamesUoM I agree with Lars here, I don't think the filtering is something we want in the upstream. But the rest of the changes seem useful, could you maybe update this PR or file those separately?

[JamesUoM]

To keep it clean and tidy I've created a replacement PR #1179