Select Requester When Creating a Ticket

[dschipfel]

Hello FreeITSM Team,

I would like to suggest a feature that could significantly improve the ticket creation process, especially for service desk agents and administrators.

Current Situation

When creating a ticket on behalf of another user, all requester information must be entered manually each time. This can be time-consuming and increases the risk of typing errors or inconsistent user data.

Proposed Enhancement

Add the ability to select an existing requester (user/contact/customer) directly from a searchable list or lookup field during ticket creation.

Benefits

• Faster ticket creation
• Reduced manual data entry
• Fewer data inconsistencies and mistakes
• Improved user experience for support staff
• Better integration with existing user/contact management

Example

When creating a new ticket, the agent could simply start typing the user's name or email address and select the requester from a dropdown list. The relevant contact information would then be filled in automatically.

I believe this would be a valuable enhancement for organizations that frequently create tickets on behalf of employees, customers, or external contacts.

Thank you for considering this feature request. I would be interested to hear whether this functionality is already planned or if there are existing workarounds available.

Best regards, Daniel

[edmozley]

Thanks Daniel @dschipfel, this is in main now.

The requester is a single field rather than separate name and email boxes. Start typing a name or an email address and pick the person from the list. Each match shows their name, their email underneath, and their company on the right, which matters more than it sounds: service desks accumulate people with similar names, and the company is how you tell at a glance that you have the right one.

It works from the keyboard: up and down to move through matches, Enter to choose, Escape to close. Once you pick someone the box is replaced by a summary of who you chose, with an "x" if you got it wrong.

For people who genuinely are not on the system yet, Add someone new is always the last option in the list, not just when there are no matches. That is deliberate. If you are adding a new Daniel and the system already has another Daniel, a "no matches found" option would never appear, and that is exactly the moment you need it. Choosing it opens name and email boxes and keeps whatever you had already typed, putting it in the right one depending on whether it contains an "@", so you never retype anything.

There is also a magnifier beside the box that opens the full list as a scrollable table, for when you would rather browse than search.

Two things about the old form turned out to be quietly wrong, and both are fixed by this:

• The name box did nothing whenever the person already existed. FreeITSM has always identified a requester by their email address, so typing a name that differed from the stored one simply discarded what you typed.
• A typo in the email address silently created a second person. There was no way for it to know you had slipped, so it created a new requester and filed the ticket against them. You would find out when the real person said they never got the update.

Documentation:

• Raising a ticket for someone else
• Raising tickets for others: Developer Guide

One related fix worth mentioning if you run more than one customer company: the requester list was returning everybody on the installation rather than just the companies you work with. That is now scoped the same way tickets and assets already were. Details are in section 4 of the developer guide.

Would be glad to hear how it works in practice.

[dschipfel]

We've reviewed and tested this feature, and it works very well.

The ability to select the requester when creating a ticket is a valuable improvement and helps us handle tickets more efficiently, especially when creating tickets on behalf of other users.

The implementation is intuitive and fits naturally into the existing workflow, making ticket creation much more convenient.

Thank you for implementing this feature. It's a great addition and works exactly as we expected.