Better control for the use of project resources

The release 4.10.0 offers the possibility to get resource allocations on the projects under control. Until now, allocations were stateless. That is, an allocation comes about through direct assignment of a resource to a project task. The allocation simply exists from that point on, can be changed, reallocated to another resource or even deleted. But it has no state.

Now an allocation workflow can be activated in the ADMIN module, as shown in the picture. Thereby allocations get a life cycle and run through different states. This works analogously to the states of a TODO. An allocation created by a project manager is first in the "New" state. This allows the allocations for the tasks to be searched and allocated as before by assigning an effort size to the resources for the task. Once the resources are allocated to the tasks, the allocations can now be requested. For this purpose, a new allocation workflow panel is available, which can be displayed directly below the Gantt plan, as shown in the following figure.

When a task is selected in the Gantt chart, all associated allocations are grouped in this panel according to their state in vertical lanes. The resources are displayed in horizontal lanes according to their affiliation to organizational units. This provides a perfect overview of which allocations are still to be requested, have already been released or rejected. The display can be influenced with options. By drag & drop single allocations but also a whole group of allocations or resources can be changed in their state. For example, all new allocations can be dragged to the "Requested" state at once.

Such an allocation workflow panel can also be found on the resource manager page. Each organizational unit now has the option to see allocations of resources in an overview on the "Disposition" view. This way, a resource manager can easily approve or reject the resources requested from the projects for his unit by drag & drop.

The question of what happens to approved allocations whose effort magnitude or task start or end dates change is easy to answer. As soon as one of these variables changes beyond a given tolerance , the affected allocations automatically fall back to the "Changed" state. So, from the project's point of view, they have to be applied for again. The tolerances can be defined in the ADMIN module.

Token-based authentication

Third-party applications can now log on to the PQFORCE server via a token. The functionality is as follows: The third-party application triggers an API request to the PQFORCE server. It receives a token, which is not yet validated. A URL is also returned with the token. This URL can be used to open a PQFORCE login window, via which a user logs into PQFORCE with his user account, thus binding the token to his user account and validating it. The token is also assigned a validity period. During this time, the third-party application can now log in to PQFORCE with the token on behalf of the user and thus access PQFORCE via the REST API. In the ADMIN module, the user has an overview of the assigned tokens and can also delete them there if necessary.