Update task
rillsoft_task_updateChange a task's planning data such as name, dates, duration, notes, task type, and personnel effort redistribution; one undo step, conflicts rolled back.
Instructions
Changes the planning data of a task: name, dates, duration, notes, fixing, display row, task kind and the dynamic redistribution of the personnel effort. It changes the task itself - moving it in the structure goes through rillsoft_element_move, its progress through rillsoft_task_progress_set, its assignments through the rillsoft_task_*_assignment_set family, and a subproject through rillsoft_subproject_update. One undo step; conflicts are rolled back for you.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | code of the task, the free text field of the task dialog; an empty string clears it. RP does not check it for uniqueness | |
| name | No | new name | |
| uuid | Yes | UUID of the task | |
| fixed | No | fix the start date | |
| notes | No | new notes | |
| start | No | new start, DD.MM.YYYY hh:mm | |
| finish | No | new finish, DD.MM.YYYY hh:mm | |
| number | No | narrows an ambiguous UUID down to one part. After a rillsoft_task_split all parts carry the same UUID (they keep the baseline reference); the number from rillsoft_project_tree_get is unique per part | |
| sameRow | No | true = draw on one display row together with the WBS predecessor, false = a row of its own (the 'Show on one row' switch of the task dialog) | |
| fixedType | No | task type: duration, effort, duration_effort (defaults to the application default from the settings). It says which quantity RP holds fixed while computing: duration keeps the duration, effort keeps the effort, duration_effort keeps both. This matches the choice in the task dialog | |
| calendarId | No | calendar of this task, an id from rillsoft_calendar_list; 0 = none of its own, the calendar of the enclosing subproject or project applies. An id that does not exist is refused with unknown_id | |
| durationHours | No | new duration in hours (0 = milestone) | |
| dynamicRedistribution | No | spread the personnel effort of this task dynamically over the people of one qualification - the switch on the 'Personnel' tab of the task dialog. Three conditions decide whether it takes effect, and two of them make the call fail rather than promise something that never happens: scheduling has to be capacity_driven (with deadline_driven nothing redistributes at all, the same refusal as at the project), and the project must not carry the switch itself (while it does, it wins, and the task dialog locks its box the same way - switch it off through rillsoft_project_update first). The third one is not an error: without named people on the task - a role alone is not enough - the switch stays without effect. Read both sides back through rillsoft_project_tree_get: dynamicRedistribution is this switch, dynamicRedistributionEffective is what the scheduling really applies. Switching it off puts the distribution back to static |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| wbs | Yes | WBS code | |
| name | Yes | name | |
| uuid | Yes | UUID of the element | |
| start | Yes | start, DD.MM.YYYY hh:mm | |
| finish | Yes | finish, DD.MM.YYYY hh:mm | |
| number | Yes | number of the element; unique even for split tasks |