Last modified: 2014-02-07 23:11:31 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T55372, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 53372 - Require confirmation after making dropdown selection when moving a ticket to a new queue
Require confirmation after making dropdown selection when moving a ticket to ...
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
OTRS (Other open bugs)
wmf-deployment
All All
: Low minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-26 21:09 UTC by Ryan (Rjd0060)
Modified: 2014-02-07 23:11 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Ryan (Rjd0060) 2013-08-26 21:09:50 UTC
OTRS v3.0 and up have a new way to "move" a ticket to a new queue.  You simply select the queue from a dropdown menu and click it - and bang, the ticket is moved, typically then inaccessible by the agent who moved it, because they likely moved it to a queue that they do not have access to.

This is normally ok, however, it is a frequent issue where tickets are moved to the incorrect queue, as a result of clicking the wrong name from the dropdown, and not being able to confirm the selection.  It would be helpful if a confirmation was required to ensure that tickets are moved to the correct queue.

This will probably need to be filed upstream, unless somebody on our end can create a patch.
Comment 1 MZMcBride 2013-08-26 21:13:19 UTC
(In reply to comment #0)
> This will probably need to be filed upstream, unless somebody on our end can
> create a patch.

Indeed.

Is OTRS in Puppet? I think there are differences between how much we can customize software that is or isn't deployed via Puppet. Jeff G. would know for sure. Depending on how annoying this is, we can probably find a workaround for now and work on a ticket upstream simultaneously.

For tickets upstream, just go ahead and file the bug there (in OTRS' issue tracker). Be sure to search their tracker first because the issue may already be filed/reported. Then mark this bug with the "upstream" keyword and cross-reference the upstream bug report link.
Comment 2 Patrik (pajz) 2013-10-01 15:13:53 UTC
If you really think this is a problem, a workaround would probably be to toggle Ticket::Frontend::MoveType from Dropdown to New Window via the SysConfig, see also http://doc.otrs.org/3.2/en/html/Ticket.html#Ticket:Frontend::Agent::Ticket::ViewMove (attention, large page). (I'm a bit worried about Ticket::DefaultNextMoveStateType -- the state should ideally not be changed when moving a ticket. Could this be achieved by setting Ticket::Frontend::AgentTicketMove###State to No? It's currently Yes.) As far as I see, this would basically get us back to how it was handled in 2.4.

That said, I do like the simplicity of the dropdown and can't remember to have made a mistake here, So I'm just not sure if this is actually a "bug." Perhaps we can collect some more opinions on OTRS Wiki?
Comment 3 Ryan (Rjd0060) 2013-10-01 23:52:01 UTC
It is a minor issue/enhancement - all such requests go to bugzilla.  I posted this after report/request of a number of users.  If you'd like more discussion, feel free to start one.

People frequently make mistakes.  Many times they ask for the ticket to be moved back.  Other times they just leave it.  This would eliminate any potential for issue with very minimal action required from the agent (one extra click or pressing of 'enter').
Comment 4 Ryan (Rjd0060) 2014-02-07 23:11:31 UTC
Closing.  An alternative is built in to the software but the agents aren't interested in changing the option at this time.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links