SLA input on the update page should default to the ticket's current SLA

[arr2036]

The SLA dropdown on Ticket/Update.html is pre-selected with the queue's default service level (RT::SLA->GetDefaultServiceLevel( Queue => ... )) rather than the SLA the ticket already has. ProcessTicketBasics includes SLA in the attributes it writes on submit, so replying or commenting without touching the dropdown silently resets the ticket's SLA back to the queue default whenever the two differ.

To reproduce on 6.0-trunk (or 6.0.3):

1. Configure two service levels, and a queue whose default is level A.
2. Create a ticket in the queue and set its SLA to level B.
3. Open Reply on the ticket. The SLA dropdown shows level A.
4. Submit the reply without touching the dropdown: the ticket's SLA is now level A again, with only a hard-to-notice transaction recording the change.

This change prefers the ticket's current SLA when building the dropdown default, keeping the submitted $ARGS{SLA} first so re-rendered forms preserve the operator's choice, and keeping the queue default as the fallback for tickets that have no SLA yet. The ticket Basics editing on the display page already behaves this way, because /Elements/SelectSLA falls back to $TicketObj->SLA when no default is passed; the update page widget was overriding that fallback.

[arr2036]

According to internal testing this has been an issue since 4.x.x, probably earlier. We have a custom scrip, that looks up the email domain of the user, and sets an SLA based on that. Guessing that's not super common, so we're probably getting bitten when others aren't.

[cbrandtbuffalo]

According to internal testing this has been an issue since 4.x.x, probably earlier. We have a custom scrip, that looks up the email domain of the user, and sets an SLA based on that. Guessing that's not super common, so we're probably getting bitten when others aren't.

@arr2036 Do you still see the issue if you run with your custom scrip disabled?

[arr2036]

Correct. If I make a new ticket from the Web UI, with a non-queue-default SLA, and the scrip disabled, and then reply to it, the SLA defaults back to the queue default... So I guess that disproves it's my "just us" theory. So now I'm confused, as to why no one else is complaining.