Edit Ticket in Question and Set SLA Plan to "None".

How is the overdue flag cleared Again from a ticket without closing ticket?

(or setting overdue date to a future date)

Olest,

The most reliable way is to "Edit" the ticket in question and select "None" for SLA plan, add some internal notes (required), and then "Save".

From our testing, if you decide at any point during the lifetime of the above ticket to turn the SLA back on, it will immediately, set the "isoverdue" bit back on, turning the "Overdue" status icon back on in the scp gui. This behavior happens without regard for how many times the ticket has been touched, by staff or your customer while you had the SLA set to none. It leaves a confusing "Overdue" icon in SCP until that particular ticket is closed.

How the "Overdue" logic behaves makes absolutely no sense imo.

Expected behavior should be, when you respond to the ticket that's "Overdue" it turns it back off.

Same with SLA behavior logic. SLA times (in my experience) are setup for the first initial contact with the customer. In our business customer can select from several different SLA's. Each with guaranteed response times and price points. The SLA logic in osTicket applies the SLA time to both customer and staff.

EG... Say I have a 1hr SLA set:

1> Customer opens a ticket that has a 1hr SLA set by default.

2> Staff responds to the that ticket within 30mins asking for additional info. (For us, this puts the ticket from "Open" into the "Answered" Que/State.

3> Customer doesn't respond for over an hour.

4> The "isoverdue" trips and puts the ticket into the "Overdue" Que/State because the customer didn't respond. This logic (imo) makes absolutely no sense. A customer not responding burdens us with a False Negative, set's a distracting "Overdue" status icon, and then we can't turn the "Overdue" status off, no matter how many times the customer or staff responds for the the lifetime of the ticket. The "Overdue" status stays on for the lifetime of the ticket until the ticket is "Closed".

Please let me know what your thoughts are from what I've pointed out. I'm curious what other people think of this behavior.

IMO, we think both the SLA logic and Overdue logic need to be rethought, as one directly effects the other.

Right now, we've completely turned SLA's off and renamed our "ticket priority" levels the same as our SLA's and give our support contract customers the choice to choose which priority level they want on the web form. We can get by setting manual due dates and times if need be.

How the "Overdue" logic behaves makes absolutely no sense imo.

Expected behavior should be, when you respond to the ticket that's "Overdue" it turns it back off.

I disagree with you. If a ticket becomes over due, updated, closed, and then later re-opened logically it would now be REALLY over due since obviously if the ticket has been re-opened then the item was never resolved in the first place.

I feel that the ideal way to circumvent this behavior, would be to have some sort of status drop down when re-opening a ticket. Such that the person re-opening the ticket would have to answer a simple status question of:

"Why are you re-opening this ticket?"

1). issue was not resolved

2). closed by mistake

3). issue was resolved but has reoccurred

4). Other

Answers 1-2 would keep over due status, and 3 would not, 4 could optionally tell the user that they need to open a new ticket.

This would of course be a huge change from the current work flow of osTicket.

Another (and probably more in sync with current work flow) solution would be to simply not allow anyone but staff (read: managers or supervisors) to re-open tickets, and always assume that if its being re-opened that the status should stay over due. .

Interest Points Made

I disagree with you. If a ticket becomes over due, updated, closed, and then later re-opened logically it would now be REALLY over due since obviously if the ticket has been re-opened then the item was never resolved in the first place.

I feel that the ideal way to circumvent this behavior, would be to have some sort of status drop down when re-opening a ticket. Such that the person re-opening the ticket would have to answer a simple status question of:

"Why are you re-opening this ticket?"

1). issue was not resolved

2). closed by mistake

3). issue was resolved but has reoccurred

4). Other

Answers 1-2 would keep over due status, and 3 would not, 4 could optionally tell the user that they need to open a new ticket.

This would of course be a huge change from the current work flow of osTicket.

Another (and probably more in sync with current work flow) solution would be to simply not allow anyone but staff (read: managers or supervisors) to re-open tickets, and always assume that if its being re-opened that the status should stay over due. .

Ntozier,

First of all I just wanted to say "Thank You" very much for all the time you've invested in helping others on these forums and the tutorials you've put together at http://www.tmib.net(http://www.tmib.net). I admire your dedication (as I know you put a lot of time and effort into your postings and tutorials). I hope to reciprocate that help for others as I get up to speed with osTicket.

Thanks for your response. You make some interesting points that I would like to follow-up on, but feel (upon further reflection) it would be best suited I devote a fresh topic in the correct place on the forums if you don't mind?

Ntozier, I'm very new to php and mysql and can't seem to find where the function or behavior is defined for the code that dictates how "isoverdue" "Overdue" notice acts/reacts.

If you could kindly point me in the right direction that would be very much appreciated.

Thanks,

lmpc

Seems to me that the logic for overdue shouldn't be too complex:1. Is the last response from the customer? Is so, continue. Else we are waiting on customer - remove overdue.2. Calculate the time elapsed from the last customer response until now.3. If the time is > the SLA then mark as overdue

just modify checkOverdue() in class.ticket.php: https://github.com/osTicket/osTicket-1.8/blob/02a2a13ea25f321e3f294a10e4276c465705677f/include/class.ticket.phpI think I'm about to since like Impc, our SLA would be upon first response.