Release Button

Requirements:

• If the permission is a team leader then a release button shows up beside the Close button shows up to the left of the Junk button
  The permission should not be tied to a role but an actual permission.  Example “Allowed to release tickets” then roles are assigned that permission.
• This calls a function release() on the server and then changes the tab to the 1^st tab so it doesn’t check-out automatically (Wouldn’t this normally be performed in the Search Mailbox?) No, it would be in the checkout mailbox b/c the only reason it needs to be released is if it is checked out.

Questions/Solutions:

1. TicketResponse.mxml
2. TicketResponseMediator.as
   1. Insert Release button beside the close button (which side left or right?)  Since it is a button that only appears sometimes it should be on the left so the position of the other buttons remains static due to the right align of the buttons.  Thus to the left of Junk if the user is a team lead
3. ReleaseButton.mxml
   1. New view component in com.dos.widget.flurry.views.components
4. ReleaseMediator.as
   1. New mediator in com.dos.widget.flurry.views.mediators
   2. Should be disabled by default; only enabled if the ticket being viewed is checked out by another user
   3. On click handler needs to invoke service call to release the checkout on a ticket
5. TicketController.as
   1. Implement the service call for release
   2. Success handler
   3. Error handler
      1. What is the fail scenario? Notification to user?
6. FlurryEvent.as
   1. May require new events

Server Side Changes

1. Already completed.  Call releaseCheckout(email address).  Code is found in DefaultTask::releaseCheckout(email)

Estimate for Release Button: Approx. 6 hours (dev & unit tests) + 1 hour (QA)

Escalate Button

Requirements:

• Add an escalate button for everyone beside the Close button
• Replace with an unEscalate button if user has escalation viewing priveldge and if the item they are viewing is Escalated.
• Clicking on it sends a command to the server.   Server.escalate(Array ticketIds, Boolean TRUE)
• Available to all users

Questions/Solutions:

1. TicketResponseMediator.as
   1. Insert Escalate button beside the close button (which side left or right?)  To the right of Suspend
   2. If ticket being viewed is in Escalated state the Escalate button should become an Unescalate button
2. EscalateButton.mxml
   1. New view component in com.dos.widget.flurry.views.components
3. EscalateButtonMediator.as
   1. Requires logic to hide the button when it is in “Unescalate” mode since unescalate is user permission driven
      Not hide but disable so the buttons don’t move.  The only case where this could happen is when a user searches for a ticket that is in the escalation queue.  An escalated ticket will never be checked out by a user who cannot unescalate it.
   2. Click handler:
      1. Escalate:
         1. service call to escalate the ticket via ticketIds
         2. what happens on the interface after the ticket(s) have been escalated?
            Same as assign
      2. Unescalate:
         1.  service call to unescalate the ticket via ticketIds
         2. what happens on the interface after the ticket(s) have been unescalated?
         3. Same as assign
4. TicketController.as
   1. Implement the service call for escalate / unescalate
   2. Success handler
   3. Error handler
      1. What is the fail scenario? Notification to user?
5. FlurryEvent.as
   1. May require new events

Server Side Changes

1. Add field to support.ticket called escalate.  Request sent as part of http://jira.clubpenguin.net/browse/TECHOPS-500
2. Upgrade FlurryTicketVO add field escalated as integer
3. add new method to TicketClientAPI::setEscalation(Boolean)::
   1. Permissions need to be checked (see updateTicketMessage for an example)
   2. returns SuccessResponseUpdate  (return $this->getResponseManager()->getResponseUpdate(current($updatedTicket),$newNotes);)
4. add new method to FlurryController::setEscalation(Boolean)
   1. could be a similar code to assignToUser
   2. need to set the flag escalated in the db to 0 for false, 1 for true
   3. Return a response "The ticket has been escalated" or "The ticket has been unescalated"
   4. Record action "Escalated" "Unescalated"
5. update FlurryController::send
   1. add field for unEscalate - default false
   2. If true also call setEscalation(False)
6. Add tests to FlurryControllerTest
7. Create tests based off of FlurryIntegrationWorkflowTest

Estimate for Escalate / Unescalate button: Approx. 8 hours (dev & unit tests) + 1 hour (QA)

Escalate Filter

Requirements:

• Escalate is added to the filter as “Only show escalated items” à needs to be implemented in Checkout Mailbox’s Filter and in the Search Mailbox’s Advanced Search
• Only show if has escalation viewing priveldge
• Default to checked
• Pass it into the searchVO
• Same with on the search but not default to checked.
• Only available to team leads

Questions/Solutions:

1. SearchFilterLayoutMediator.as
   1. setupFilter method needs to check user’s permission: if user == team lead then render the escalate filter checkbox on the SearchFilterLayout.mxml view component
      See note above about permissions
   2. if the user == team lead; the setupFilter method needs to retrieve the isEscalateFilter checkbox selected and assign it to the FlurryFilterVO.isEscalateFilter before getting tickets
   3. if the user != team lead; the setupFilter method will set the FlurryFilterVO.isEscalate = false
2. FlurryFilterVO.as needs to have isEscalateFilter:Boolean property
3. SearchForTicketMediator.as
   1. Needs to check if user == team lead then render the escalate filter checkbox on the SearchForTicket.mxml view component

1. 1. If user == team lead; the onSearchClicked method needs to retrieve the isEscalateFilter checkbox selected and assign it to the FlurryAdvancedSearchVO.isEscalateFilter before invoking the search
   2. If user != team lead; the onSearchClicked method will set the FlurryAdvancedSearchVO.isEscalateFilter = false
2. FlurryAdvancedSearchVO.as needs to have isEscalateFilter:Boolean property
3. TicketController.as
   1. Re-use existing search service calls / success handlers / error handlers (probably none to minimal amount of changes)
4. FlurryEvent.as
   1. May require new events

Server Side Changes

1. update FlurryFilterVO and FlurrySearchVO## add property: escalated
   1. add method decorateWithEscalated
      1. perhaps base of FlurrySearchVO::decorateWithTicketId
      2. if value is 0 ignore b/c we are only searching for if escalation is true not if it is false.  0 will search for both true and false.

Estimate for Escalate Filter: Approx. 8 hours (dev & unit tests) + 1 hour (QA)

Icons Required:

Escalate

Unescalate

Release