On saving changes to a ticket edit page displayed

I know this has been mentioned before but I haven’t been able to find in
the lists the reason for this small, possible inconsistency.

When you “Update” a ticket after adding a comment the modified ticket is
displayed.

When you “Save Changes” to a ticket, after modifying fields in the edit
Basics page (for instance) the edit window remains displayed, rather
than returning to the ticket display page.

I am sure there is a logical reason for this, and am just trying to find
out what it is to provide our users with an explanation.

thanks
Gordon

I know this has been mentioned before but I haven’t been able to find in
the lists the reason for this small, possible inconsistency.

When you “Update” a ticket after adding a comment the modified ticket is
displayed.

When you “Save Changes” to a ticket, after modifying fields in the edit
Basics page (for instance) the edit window remains displayed, rather
than returning to the ticket display page.

I am sure there is a logical reason for this, and am just trying to find
out what it is to provide our users with an explanation.

thanks
Gordon

Hi Gordon,

One reason is that certain scip actions can be based on the settings
of particular fields. So you need to first set one field and then
another to produce the correct action. One field we have is whether
or not to send E-mail when a ticket is resolved. To have this work
you first need to set that field and then resolve the ticket.
Otherwise the mail is sent. That is one example but having to re-enter
the basics screen over and over would be clumsy at best.

Regards,
Ken

One reason is that certain scip actions can be based on the settings
of particular fields. So you need to first set one field and then
another to produce the correct action. One field we have is whether
or not to send E-mail when a ticket is resolved. To have this work
you first need to set that field and then resolve the ticket.
Otherwise the mail is sent. That is one example but having to re-enter
the basics screen over and over would be clumsy at best.

It’s not clear why this is a two step process, you can set
custom fields when replying to the ticket. If you do not
wish to reply or comment, you could still do this with Jumbo.
Cambridge Energy Alliance: Save money. Save the planet.

One reason is that certain scip actions can be based on the settings
of particular fields. So you need to first set one field and then
another to produce the correct action. One field we have is whether
or not to send E-mail when a ticket is resolved. To have this work
you first need to set that field and then resolve the ticket.
Otherwise the mail is sent. That is one example but having to re-enter
the basics screen over and over would be clumsy at best.

It’s not clear why this is a two step process, you can set
custom fields when replying to the ticket. If you do not
wish to reply or comment, you could still do this with Jumbo.

If the custom field is not set before the reply/resolve scrip
is executed, the notice still goes out. Then the CF value is
changed.

Ken

Shouldn’t you be able to check the transaction to see if the CF is being sent?
$Transaction->CustomFieldValues perhaps. It’s not as simple as simply
checking the CF, but makes it a one-step process for the user.

Cambridge Energy Alliance: Save money. Save the planet.

Hi Gordon,

One reason is that certain scip actions can be based on the settings
of particular fields. So you need to first set one field and then
another to produce the correct action. One field we have is whether
or not to send E-mail when a ticket is resolved. To have this work
you first need to set that field and then resolve the ticket.
Otherwise the mail is sent. That is one example but having to re-enter
the basics screen over and over would be clumsy at best.

Yes: basically, it saves you a click.

A real-world example:
If you are in the comment screen on a ticket, say that the comment you
want to leave on that ticket normally gets bcc’ed via email to the 4
admin ccs’s for that queue, whose emails are listed under scrips &
recipients–but in this instance for some reason you want to notify
only 1 admin cc with an email, so you click the checkboxes next to the
other 3 people so they won’t receive an email.

Clicking those boxes only marks their names, though; it does not save
the fact that you marked their names. The “Save changes” button saves
what you did–the other 3 admin cc’s names would be listed as people
who would not receive messages–and now you just scroll back up to the
textbox and write in your comment (instead of having to reload the
comment screen again from the main ticket page).

When you press “update” that comment will be sent and bcc’ed to that 1
admin cc only, since that’s what you’d saved in the previous step.

Please note that the next time you tried to comment on that ticket,
your changes would still be in effect since they were saved, so you
would have to check the boxes next to the other admin cc’s names and
press “save changes” again if you wanted to bcc to all 4 of them again.

Cassandra Phillips-Sears
Office Manager
Best Practical Solutions, LLC