Administrative action: set task status to In process

[solth]

Currently, users with appropriate rights can change the status of a process' task to Completed, Open, In process and Locked. In contrast to the other three states, setting the status of a task to In process without actually assigning the task to a user does not make sense, IMHO.

Who is supposed to be working on the task to make it In process?

Therefor my question to @subhhwendt and @andre-hohmann: which behavior is expected here?
I see two possible solutions:
A user with administrative rights can either

1. set the status of a task to Completed, Open and Locked, but not to In process or
2. set the status to In process as well, but is then required/prompted to assign the task to a user with the corresponding role, project and client.

[andre-hohmann]

At the first glance, you are right and i assume it is possible, because that kind of implementation was the easiest: It is always the same sequence of the tasks. Ignoring the task In process has two advantages:

• the change of the status is quicker
• the risk of misinterpretation of the colors is reduced

Is it still possible to set the task from In process to another one? That is sometimes useful, if a user does not release the task and someone else needs to work on the process quickly.

Option 2 - to assign a task to a specific user - takes time and i definitely do not recommend its implementation.

On the fly, i cannot imagine a scenario in which it is necessary to set the status to 'In process' - from the users point of view. Maybe @henning-gerhardt knows, if it has technical effects, which i cannot see.

It must be regarded that although it does not make sense, it does not hurt. Thus, if uncertainty persists, it could be still applied in the previous way.

[henning-gerhardt]

From an administrative technical point of view setting one or many tasks to "in progress" is used if you need to repair / to do something in the background and you don't want that a regular user or an other administrator is taking over this task. In 2.x the user is assigned to the task who is setting the task to "in progress" but as this is done by an administrator the change type of the task is "administrative" instead of "manual" if a regular user is taking this task.

[andre-hohmann]

That sounds reasonable and i suggest to keep the current state.
I am afraid of complications, if we try to change the concept/function.

Is that OK for all?

[solth]

The reason I brought this up is because the current implementation in 3.x makes a lot of trouble, because the system - rightfully in my opinion - assumes a task can only be in work/in process (for some reason it's not in progress, but rather in process at the moment) if someone is actually working on it. For the special case that a task is in process but no user is assigned all kinds of special edge cases need to be considered which makes working with these tasks much more complicated than necessary (see #3679 for example).

Assigning the task to the user who performed the administrative action is normally not possible, because the user probably does not have the role, project and client required to accept that specific task.

If it's that important to sometimes set a task to in process via an administrative action to repair something I would suggest to eventually implement option 2: prompt the admin to assign appropriate users to tasks whose status he manually changed to in process when saving a process.

This does not need to be implemented right away but I think it would be good to have a sound concept.

[henning-gerhardt]

Why is it not possible to assign an user to a task independent if he has the correct right / permission? I'm talking about administrative users who are doing this and not about regular users. Regular users should only do things with the right rights and or permissions.

If I must set thousands of tasks / processes to "in progress" to repair them, then I don't want enter thousand times my user name.

[solth]

@henning-gerhardt ok, I see your point. I guess we will not change it than. But one thing I do not understand is: how should a task, that is in process, but not assigned to anyone, be displayed in the task list? The same way as an open task so that users can self-assign them? What is the benefit of setting them to in process instead of open than? Or are they marked in a different way?

[henning-gerhardt]

@solth I never said that this "in progress" task is not assigned to any user. Like in 2.x it should assigned to the user who set this task to "in progress"! But instead doing this in the regular way the administrative user who is doing this (setting task to "in progress") is set as assigned user for this task - independent if this administrative user could do this in regular way. After the administrative user is done with his work he normally set the task to "open" or "done" and regular workflow can go on.

[andre-hohmann]

I am sorry, but i have to ask about the result of the question. Is my assumption correct:

1. The task In process is still available in the task list of processes
2. If it is set administratively to In process, the current user is assigned to the task

We should find a solution to the problem that the combination "In process - no user" causes trouble. That is more important than the fact, that the current state does not make sense in all regards.

[solth]

@andre-hohmann I think Henning clearly answered the question:

Like in 2.x it should assigned to the user who set this task to "in progress"!

The way I see it the decision is to keep the functionality of 2.x. I just didn't realize administrators had the rights to self-assign tasks even if they didn't belong to the appropriate groups in 2.x

Since in process tasks should therefore always be assigned to someone, the current situation where tasks set to in process via a process' task list (e.g. an administrative action) are not assigned to anyone - which requires all the workarounds I mentioned - clearly indicates a bug.
I opened a bug ticket (#3692) and would suggest to close this issue.

[henning-gerhardt]

Last notice for this issue: At our house our administrative users has most of all possibles roles / groups and 80% to 100% of all projects assigned. So they can act as regular users in case of errors or to reproduce user errors but even work and interact as administrative users.