Allow for searching of process with an active step of name "X"

[BartChris]

Is your feature request related to a problem? Please describe.
While testing #6587 i was wondering what the actual semantics of a search for step:xxx in the process list is.
It seems like the query is interpreted in a way that it returns all processes which have any step with the name "xxx" somewehere in their workflow (task list).

This is hardly useful in my opinion. Should the search not give me any process which has an ACTIVE task of that name? I would consider those three steps as ACTIVE: OPEN, INWORK, LOCKED

Sometimes i want to get all processes in that specific step, no matter if somebody is currently working on it (INWORK) or nobody has picked it up yet. (OPEN)

Is there any use case for returning a quiet arbitrary list of processes which have this step somewhere in their associated (not necessary active) tasks? I would consider the current behaviour invalid.

Describe the solution you'd like
A search for step:xxx should give me all processes with an active step with title xxx.

Edit:
Description is related to current Master. 3.8 seems to not work as the search for step:XXX does not return any results at all. I will therefor also add the "bug" label.

[solth]

@BartChris I am not sure if I correctly understood your description, but there already is a filter that allows searching for processes with a specific task in state OPEN or INWORK, by using the filter operators stepopen and stepinwork, instead of just step:

stepopen:bildübernahme:

stepinwork:bildübernahme:

Is this not what you are proposing?

[BartChris]

@solth You are right that the two searches combined give me more or less what i want. (Although i would have to issue them serially) I would consider it at least a quality of life improvement if there was a way to just get in one go all processes which are in a specific step (what i described as Active). If somebody/a script is actively working on the task or if the task is open for processing is not relevant at that point and it can be annoying to always having to query both states.

Edit: Maybe that's debatable. But what happens right now (step:xxx just returning all processes which somehow have this task in their workflow) seems quite confusing.I am not sure, adding another entry like stepactive: maybe leads to more confusion.
Would be great, if somebody has a better idea.

[henning-gerhardt]

Why step:XXX was added - I don't know and I don't know any useablel usage scenario for this. In most cases I use ony stepopen:XXX and stepinwork:XXX to filter tasks and especially automatic task. In rare cases I used steplocked:XXX if something goes really wrong. But in most cases I used this filtered list to extract the internal IDs and any later work is done by this retrieved IDs.

I see - from my point of view and usage - even no usage scenario for stepactive:XXX as I work with open and inwork on most usage scenarios and they then need different usages where an combined step filter did not really help.

If step:XXX get removed - I have no issues with that removing.

Edit:

In my opinion active should only take OPEN and INWORK into account as with this two states the users can interact. With LOCKED (red) and CLOSED (green) normal users can not interact in any way.

[BartChris]

Edit:

In my opinion active should only take OPEN and INWORK into account as with this two states the users can interact. With LOCKED (red) and CLOSED (green) normal users can not interact in any way.

I think you are right. I probably had a wrong understanding of the LOCKED state, for which i still struggle to grasp in what different scenarios (i suppose there are multiple) it gets assigned.

[matthias-ronge]

A task is LOCKED (German: gesperrt) before it can be accepted to work on, because the preconditions have not yet been fulfilled. A task is CLOSED (German: abgeschlossen) after it has been done. So if a task is locked, that means it is "still disallowed to work on", as long as it has not been reached in by the workflow progress. A task that is LOCKED is always not yet available, we will come to it later. So it is a position in the workflow, that it is its turn later. For example, if the workflow has the steps "Transport to scan center" and "Scanning", the scanning task is locked (not yet ready) as long as the object has not been brought to the scan center, because it cannot be scanned if it is not yet there.

The "locked" state is only assigned to tasks in two cases: First, when a process is created (typically, the first task is "open", any subsequent tasks are "locked"). Second, when invoking the Correction Step functionality, then the task to redo is set to "open" and all subsequent tasks are set to "locked".

A workflow without parallel steps always look like this:

[CLOSED] {0 .. n}, [OPEN or INWORK] {1}, [LOCKED] {0 .. n}
^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^
 finished tasks      task in work or     tasks waiting for
                   waiting to be worked  previous task to
                            on            be completed to
                                         become available

I think, "blocked" or "pending" would be a better translation of that German "gesperrt", and "completed", "done" or "finished" would be a better translation of that German "abgeschlossen", but that’s a different story.

[BartChris]

Thanks a lot for the explanation. Since i am currently working on a new wiki article for the "Workflow Editor"?

https://github.com/kitodo/kitodo-production/wiki/Kitodo%E2%80%90Workflow-Neu

What is the meaning of this select menu ("gesperrt" vs "abgeschlossen") in the workflow editor, as those seems to be attributes which are somehow assigned to a (correction(?)) task:

[matthias-ronge]

Normally, all workflow tasks are initially "locked" (= unprocessed). When the workflow for the process is started, as soon as the process has been created, the workflow engine automatically sets the first task to "open." Therefore, unless you know otherwise, this menu entry should always be set to "locked" (= unprocessed).

However, there are also organizations that have already taken steps in Kitodo before starting the workflow (e.g., creating the process in Kitodo, or other preceding steps) and want to reflect this in their workflow. They can then create these "closed" (= processed, completed) steps in the workflow and set them to "closed". After the process is created, the first "locked" task is set to "open". "closed" tasks are ignored. Therefore, tasks should only be set to "closed" at the beginning of the workflow, not at some later point. (And I fundamentally reject this; it just creates unnecessary database objects that serve no purpose. But some experts prefer it that way.)

Workflow editor:

[CLOSED] {0 .. n₁}, [LOCKED] {1 .. n₂}

New process:

[CLOSED] {0 .. n₁}, [OPEN] {1}, [LOCKED] {0 .. (n₂ − 1)}

Example workflow:

• CLOSED: Create process in Kitodo
• LOCKED: Scanning
• LOCKED: Quality control
• LOCKED: Structuring
• LOCKED: Export to presentation

A newly created process will look like this:

• CLOSED: Create process in Kitodo
• OPEN: Scanning
• LOCKED: Quality control
• LOCKED: Structuring
• LOCKED: Export to presentation

[matthias-ronge]

Back to the topic:

The simplest solution would be to search for the task and exclude all locked tasks (and keep completed tasks hidden).
For example: "step:OCR" "-steplocked:OCR"

I haven't tested it yet. Does it do what it's supposed to?

[BartChris]

Back to the topic:

The simplest solution would be to search for the task and exclude all locked tasks (and keep completed tasks hidden). For example: "step:OCR" "-steplocked:OCR"

I haven't tested it yet. Does it do what it's supposed to?

"step:OCR" "-stepdone:OCR" "-steplocked:OCR"

seems to do it. Your suggestion also gives all processes where the ocr is done.

How should i "keep completed tasks hidden"? I am searching the process list.

[matthias-ronge]

Oh, I thought you were searching the tasks. Completed tasks aren't displayed in the task list without setting the switch to "on," that's what I meant.

In the process list, you'll have to manually exclude them, as what you already wrote should do it:

"step:OCR" "-stepdone:OCR" "-steplocked:OCR"

Yes, I see an additional search predicate would not be bad, but in principle that is at least a way. That's why one can save filters, because some are more complicated to enter.