[SOLVED] How to have no default priority

[HervE]

Hello forum,

I'd like to improve my configuration so that there is no default priority, so that the agent that deals with the ticket first, has to set the chosen priority for the ticket.

I tried a first idea: leave blank the default priority in SysConfig Ticket::Postmaster. But creating a new ticket with no priority failed.

So the second idea is: create a priority named "undefined" (and invalid, so that the ticket can't keep this value when you change the priority).
Now the question is: how to force the agent to modify the priority?

I thought the most convenient place would be on ticket reply, so I started to modify AgentTicketViewCompose.dtl and AgentTicketViewCompose.pm.
I was self-confident, because I already did it to add article type (email-internal/email-external) to it. But this time I didn't succeed.

But maybe there is another more convenient place? Or, at least, easier to program.

Any idea is welcome.

Regards,
HervE

[micshi]

For creating new ticket, the front module will eventually call TicketCreate() interface which defined in the OTRS core module $Home/Kernel/System/Ticket.pm

Without Priority parameter, TicketCreate() will be failed to create ticket.

Please refer to Kernel::System:Ticket from Developer API Documentation.

[HervE]

Thank you micshi for your answer.

That's for my first idea.
But I think it is wiser to let it down.

Now I focus on my second idea.

I almost managed to add Priority selection to Ticket reply page.
But still need to adapt the following things:
1. make it mandatory
2. make the previous value the selected item
3. commit the selected item as the new value

Regards,
HervE

[micshi]

Hi HervE,

Your second idea, maybe not realized.

Priority is one of ticket attribute, while reply is an action on article.

Article action (reply) can not manipulate ticket attribute.

thanks,

micshi

[HervE]

Hi micshi,

Article action (reply) can not manipulate ticket attribute.

Why not? Article points to the ticket it belongs to. Anyway, the Reply action allows to set the next state of the ticket. So I think it could possible to make it set the next priority as well.

Regards,
HervE

[micshi]

Hi micshi,

Article action (reply) can not manipulate ticket attribute.

Why not? Article points to the ticket it belongs to. Anyway, the Reply action allows to set the next state of the ticket. So I think it could possible to make it set the next priority as well.

Regards,
HervE

Hi HervE,

You are right. My idea has logical mistake.

Have you tried on module of ITSMIncidentProblemManagement?

It can calculate the priority based on criticality (which defined in Service) and impact. It more in line with the ITIL best practice

Thanks,

micshi

[HervE]

Have you tried on module of ITSMIncidentProblemManagement?
It can calculate the priority based on criticality (which defined in Service) and impact.

Hello,

Thanks for your answer.
I haven't tried this module, and I don't think our team needs such a (complicated) thing, but rather to set the priority by ourselves when replying to a ticket.

I have progressed on the way to achieve that!

I managed to have the priority in the Reply window and handle it (AgentTicketCompose.dtl + AgentTicketCompose.pm)

The only remaining thing I have to do is make the priority field as mandatory. For the moment, my related code in AgentTicketCompose.dtl is:

Code: Select all

                <label class="Mandatory" for="NewPriorityID"><span class="Marker">*</span>$Text{"Priority"}:</label>
                <div class="Field">
                    $Data{"PriorityStrg"}
					<div id="PriorityError" class="TooltipErrorMessage"><p>$Text{"This field is required."}</p></div>
                </div>
                <div class="Clear"></div>

Which doesn't make it mandatory indeed. Why? Because value "-" is an option, for it is considered as different from nothing.
Do you think of an idea to refuse this value, although it does have to be in the list-box?

Regards,
HervE

[HervE]

I somehow succeeded, as I explained here.

HervE