(SOLVED) Dynamic field is not setting on new tickets

[bayerex]

Hi,

I've created a dynamic field dropdown with a default value set. This works ok for agents but not for customers. After a customer creates a ticket the value is blank, presumably because the field is only displayed on the agent new ticket form and has not been added to the customer form.

I assumed that because the field has a default value that it does not need to be displayed on the form. So my question is how can I ensure that this default value is input into the ticket without the customer seeing the field?

Would the solution be to add this field to the customer form but make it hidden?

Thanks for your help.

[bayerex]

I've solved this with a bit of Javasript at the end of CustomerTicket

Code: Select all

document.getElementById("LabelDynamicField_WorkflowProcess").style.display = 'none';
document.getElementById("DynamicField_WorkflowProcess").style.display = 'none';

The problem remains of a blank value when customers emails a ticket but to save confusion I'll write ask about this on a different post

[crythias]

If the same value is assigned to all new tickets ... what's the point of assigning this value?

More to the point why isn't ticket state "new" relevant to your workflow process?

Or even, why isn't the ticket state indicative of your workflow process?

[bayerex]

If the same value is assigned to all new tickets ... what's the point of assigning this value?

More to the point why isn't ticket state "new" relevant to your workflow process?

Or even, why isn't the ticket state indicative of your workflow process?

Because in our workflow, when an owner wishes to involve a developer they assign them as responsible and change the workflowprocess field to 'developerment'. When the developer has finished their work they change the workflowprocess to 'support' but remins responsible on the ticket. The support person answers the customer and later closes the ticket. This allows us to share the same queues and create seperation in our searches.

[bayerex]

The decision was taken to design it this way because the developers can have potentially hundreds of tickets in their queues and once they have written a solution they do not want the ticket visible in their queue anymore.

At the same time the company won't allow developers to remove themselves from being responsible to the ticket as they want this to be searchable.

Using a dynamic field was in the end a happy compromise.

[crythias]

Another option:
Queues for workflow.

once they have written a solution they do not want the ticket visible in their queue anymore.

Which means they can send it back to the Support queue when they've written the solution. And support can send it to developer queue when they need dev to update it.

[bayerex]

Another option:
Queues for workflow.

once they have written a solution they do not want the ticket visible in their queue anymore.

Which means they can send it back to the Support queue when they've written the solution. And support can send it to developer queue when they need dev to update it.

That would mean doubling all our queues. There are already about 7 different queues depending on the product group. At the moment that wouldn't simplify things any further