change status to assigned when requester add a followup

[orthagh]

I open a new discussion because feature was removed in 5d549a060a97#diff-007edb12589cf3c8df3121cd7b19028aL6707 commit.

It's important for some users so i need to re-add it.
But i think the previous implementation was maybe a little hardcoded.

For full explanation.

• technician add a followup and set ticket on waiting (for requester) status to stop the sla time
• When requester add a followup, status is automaticaly set to assigned

I suggest for 0.90.1 (or next) to add an entity option to control this.

Your opinion, @yllen

[yllen]

This change of status is only for a follow-up, so it must be in post_addItem() of TicketFollowup.
If you want this action you must have many controls:

• is the actual status is Waiting?
• is the ticket assigned (technician, group of technicians or supplier)?

With an entity option for that, all sources will have same treatment (email, interface and webservices).

[orthagh]

In complement to this friday discussion, i would like to precise old control (5d549a060a97#diff-007edb12589cf3c8df3121cd7b19028aL6707).
Today, i remember how the feature was implemented and i think it's not as stupid as mentionned.
Since 0.90, we have a splitted button to change ticket status when adding a fup/task.

In self-service, this control is also present (but only with allowed status) and the default choice was predefined by removed part :

if ($actor_type == CommonITILActor::REQUESTER) {
   $ticket->fields['status'] = CommonITILObject::ASSIGNED;
}

I you are a requester, the defaut value was defined to CommonITILObject::ASSIGNED
However we miss a check on previous status (as you mentioned in #247 (comment)), but i'm not sure of adding code in TicketFollowup::post_addItem(). It will add duplicated code (see below).

I prefer a change in displayed html and add an input[type=hidden][name=_reopen] in case of requester actor.
Thus, we can re-use this part who match perfectly for our need : https://github.com/glpi-project/glpi/blob/master/inc/ticketfollowup.class.php#L394-L411

[orthagh]

Maybe, we can add this only in followup's form (instead of both task/followup)

[orthagh]

actually, we already have a part to do this : https://github.com/glpi-project/glpi/blob/master/inc/ticketfollowup.class.php#L601-L607

I'll change this part to take to set $reopen_case = true on case of waiting status

[orthagh]

So, here is the final implementation.
@yllen, waiting for your review to close this issue.

[orthagh]

One more point, in case of double notifications (update_ticket and add_followup) on this action,
Il would prefer to keep add_followup notification instead of update_ticket.

Same for a user change status in same action of adding followup or task.

The important data to notify is, imo, the content added in task or followup , not the change of status in ticket.
we could remove the

$donotif = false; 

and add

$update['_disablenotif'] = true;

before the ticket update

Your opinions ?

[yllen]

Je suis désolée mais je ne comprends pas du tout le code.
Pourquoi un sef-service aurait le droit de réouvrir un ticket clos UNIQUEMENT s'il n'y a pas de technicien assigné ?

[yllen]

I'm not agree with this change.
Now you can't have notification for update ticket when status change.
So, if your technician is notified for update ticket, he can't know if a ticket is reopen.

[remicollet]

@yllen good catch

[orthagh]

Done at purpose, see #247 (comment)