-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix update ticket status when ticket task is de-scheduled #16895
base: main
Are you sure you want to change the base?
Fix update ticket status when ticket task is de-scheduled #16895
Conversation
Please add a test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is already a function updateParentStatus
, which you could use
I change the target to main branch. This can be considered as a new feature and may have unexpected side effects. |
a44093c
to
937926a
Compare
@RomainLvr I rebased your branch to fix conflicts. |
if ($iterator->numrows() > 0) { | ||
$input['_status'] = CommonITILObject::PLANNED; | ||
} elseif ( | ||
$parentitem::isAllowedStatus($parentitem->fields["status"], CommonITILObject::ASSIGNED) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure of this, but I think we should not rely on the current profile statuses matrix to filter available status. Indeed, I think that when a task begin date is updated, the ticket status should be changed to PLANNED
, even if the technician is not supposed to be able to do it by itself.
@orthagh What do you think of this?
$parentitem::isAllowedStatus($parentitem->fields["status"], CommonITILObject::ASSIGNED) | |
$parentitem->isStatusExists(CommonITILObject::ASSIGNED) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, previously, we just checked the planned status really exists for the ITILobject (Changes doesn't have this status).
The right of a technician to change the status to planned should not be checked.
This is for the UI and prevents manually changing the status field.
All shortcuts, like "adding a tech actor -> status move to in ASSIGN", "remove all attributed actor -> return to INCOMING" and the new one to move to PLANNED should be done by the framework automatically and do not impact the status field directly.
) { | ||
$input['_status'] = CommonITILObject::ASSIGNED; | ||
} elseif ( | ||
$parentitem::isAllowedStatus($parentitem->fields["status"], CommonITILObject::INCOMING) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same remark here.
$parentitem::isAllowedStatus($parentitem->fields["status"], CommonITILObject::INCOMING) | |
$parentitem->isStatusExists(CommonITILObject::INCOMING) |
When a task is de-scheduled, the ticket status remains In progress (Scheduled) instead of being changed back to In progress (Assigned).