Ticket Field Visibility

To make Frappe Helpdesk more secure and easier to use, ticket fields are now protected by permission levels. This release also gives the HD Ticket Template a bigger role: it now controls which fields appear on the ticket form, who can see them, and whether customers can edit them after the ticket is raised

Ticket fields now use Frappe's permission levels, so each site controls what customers can see and fill in. To hide a field from the ticket form, users can set its row in the ticket template to Visible to: Agents. This hides the field in the helpdesk UI and allows that certain field to be filled by Agents only. For further hardening, you can also raise its permission level in Customize Form, so the API stops returning it too.

There are two layers, and they do different jobs.

• Permission levels decide which roles can read and write a field. A higher level makes sure that the field never reaches a role that must not read it.
• Visible to decides where a field shows on the helpdesk pages. Every helpdesk endpoint also drops the fields that are hidden from you. On the new ticket form, you get only the fields that you can fill.

Set a permission level when a field must never reach a customer. Combine it with Visible to, so that the field never shows in the ticket form.

Permission levels

Every field has a permission level. Helpdesk ships three levels by default and leaves room for your own.

Levels 7 and 8 are deliberately high. Levels 1 to 6 are free for a scheme of your own.

To change the level of a field:

• Go to Customize Form and select HD Ticket.
• Click the field that you want to change.
• Set Permission Level to 8 to make the field agent-only, or to 7 to let customers read it.

Click Update.

A permission level is the only thing that hides a field from the API. If a field must be internal, set its level. Read more about permission levels in the Frappe Framework here.

Visible to

Every row on the Default ticket template has a Visible to setting. Open the template at HD Ticket Template > Default in the desk.

• Everyone shows the field to customers and agents. This is the default.
• Agents shows the field on the agent form and hides it from the portal.

Visible to replaces the old Hide from customer checkbox. The update carries over your existing settings.

What to do when a field is hidden but the API still returns it

If you set a field to Agents while its permission level still lets customers read it, helpdesk shows a message when you save the template:

Ticket Type is hidden from customers here, but the API still returns it. Raise its permission level in Customize Form to hide it everywhere.

The field is now hidden on the portal, which is often all you need. If the field is sensitive, follow the link and raise its permission level to 8. The message stops after you do this.

Editable after creation

Every row on the Default ticket template also has a Editable after creation checkbox. When you tick it, customers can change that field after they raise the ticket.

The change can come from the portal, a form script, or the API. Editable after creation only works on a field that the customer can already see:

• The row must have Visible to set to Everyone. The checkbox does not show on a row set to Agents.
• The field must be at a level that customers can read (0 or 7).
• Fields that the server sets, such as sla or response_by, stay locked.

The checkbox is off by default, so nothing changes until you turn it on.

What a customer can change

A customer fills in the fields that your template shows them when they raise a ticket. After that, the ticket is theirs to read, not to edit.

After a ticket exists, a customer can only:

• reply to it,
• close it,
• leave feedback and a comment,
• change a field whose template row has Editable after creation ticked.

Helpdesk refuses every other change and shows an error. The field keeps its value. The error gives the reason:

A customer cannot set their own priority, move a ticket to Replied, reassign a team, or change who raised the ticket.

This applies to every route into the ticket, not only the portal. Calling the API directly makes no difference.

Form scripts

A form script runs in the browser as the user who has the page open, so it cannot do more than that user can do. Apply to customer portal decides whether the script runs on the portal or on the agent pages. Apply on new page decides whether it runs on the new ticket form or on an existing ticket.

• For an agent, a form script can change every field.
• For a customer on the new ticket form, a form script can fill only the fields that the Default template shows them. Helpdesk drops any other value when it creates the ticket.
• For a customer on an existing ticket, a form script can only close the ticket, leave feedback, or change a field with Editable after creation ticked. Any other change shows one of the errors mentioned above.

Breaking change: customer field permissions

Three things change when you update.

• Customers can no longer edit ticket fields after creation. Before this release, a customer could change fields on their own ticket through the API. They can now only reply, close, and leave feedback. Helpdesk refuses any other change with an error. If customers must update a field after they raise a ticket, you have
  two options:

  • Add the field to the creation form beforehand, so that customers fill it when they raise the ticket.
  • Tick Editable after creation on the field's row in the Default template.

• Hide from customer is replaced by Visible to. The update carries existing values across, so hidden fields stay hidden. Anything that you built to read the old
  hide_from_customer field must now read visible_to.

• Form scripts follow the customer's permissions. A portal form script can no longer change a ticket after creation, unless the field has Editable after creation ticked. On the new ticket form, a portal script can fill only the fields that the Default template shows to customers. The new ticket form also picks scripts by audience.