We’re trying to use RT across the company as our main ticketing system. This requires other departments to raise tickets into our queue.
We have two mandatory ticket custom fields in this queue for us to internally categorise tickets.
Our standard users do not have rights to “View custom field values” or “Modify custom field values” and indeed cannot see or set these fields in the Create Ticket view.
When the user attempts to raise the ticket, RT seems to be checking for the validity of these custom fields, even though the user has no ability to set them.
Raising via email works as expected, but our users are used to the RT interface and prefer to raise this way.
Is this expected behaviour? How might I work around this?
Paul
Paul Stead
Systems Engineer, Zen Internet
T: 01706 902009
Set
Custom Fields to not mandatory on creating new ticket, then set plugin
options to force mandatory CF on any or specific transaction, change of
status (ex, for closed ticket - fields have to be mandatory)
Enjoy!
W dniu 2014-02-04 11:07, Paul Stead napisał(a):
Hello,
Running RT 4.0.17 on Debian.
We’re trying to use RT across the
company as our main ticketing system. This requires other departments to
raise tickets into our queue.
We have two mandatory ticket custom
fields in this queue for us to internally categorise tickets.
Our
standard users do not have rights to “View custom field values” or
“Modify custom field values” and indeed cannot see or set these fields
in the Create Ticket view.
When the user attempts to raise the
ticket, RT seems to be checking for the validity of these custom fields,
even though the user has no ability to set them.
Raising via email
works as expected, but our users are used to the RT interface and prefer
to raise this way.
Is this expected behaviour? How might I work
around this?
Paul
Paul Stead
Systems Engineer, Zen
Internet
T: 01706 902009
Bartosz Maciejewski
IT
Administrator
Agri Plus Sp. z o.o.
ul.Marcelińska 92/94
60-324
Poznań
tel: 061 665 79 77
gsm: 666 866 549
Please consider the
environment before printing this email.
Sorry if I am misinterpreting, but it sounds like you have custom fields the end users don’t have permissions to set.
Yet you need them to be able to set those fields.
If this is true, it’s the same thing we encountered here.
Surely not the most elegant solution, but this worked for us:
End users (e.g. 'everyone') has permissions to enter tickets in the "helpdesk" queue
We needed to have them set a custom field called "application" (and a few others) initially, but didn't want them changing those fields later when the ticket was escalated to other queues.
We created two sets of custom fields, matching in name, except that one set had underscore characters appended (e.g. "application" and "application_")
Both sets of custom fields applied to the helpdesk queue, but only the non-underscore version applied to the escalated queues.
Users had permissions to change the underscore version, but not the other. This way you can tweak not only what they can change, but even what they can see, also allowing them to set them initially, but not change them later. Great for things like when they set a priority and you have to change/hide that later! =)
We set a scrip to loop through all the custom fields on the ticket upon ticket creation, shifting the values from the underscore custom fields to the matching non underscore versions.
We set the built-in mandatory flags on the ones that needed to be set to ensure they were captured at ticket creation.
It does require the scrip to move the custom field values from one set of fields to the other, and I also included an if statement or two to hide the underscore fields from privileged users (otherwise the duplicate fields thing looks messy when they are adding new tickets to helpdesk queue where both sets of fields appear to privileged users).
BrentFrom: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Paul Stead
Sent: Tuesday, February 04, 2014 5:07 AM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Mandatory Custom Fields and Group Rights
Hello,
Running RT 4.0.17 on Debian.
We’re trying to use RT across the company as our main ticketing system. This requires other departments to raise tickets into our queue.
We have two mandatory ticket custom fields in this queue for us to internally categorise tickets.
Our standard users do not have rights to “View custom field values” or “Modify custom field values” and indeed cannot see or set these fields in the Create Ticket view.
When the user attempts to raise the ticket, RT seems to be checking for the validity of these custom fields, even though the user has no ability to set them.
Raising via email works as expected, but our users are used to the RT interface and prefer to raise this way.
Is this expected behaviour? How might I work around this?
Paul
Paul Stead
Systems Engineer, Zen Internet
T: 01706 902009
We’re trying to use RT across the company as our main ticketing system.
This requires other departments to raise tickets into our queue.
We have two mandatory ticket custom fields in this queue for us to
internally categorise tickets.
Our standard users do not have rights to “View custom field values” or
“Modify custom field values” and indeed cannot see or set these fields
in the Create Ticket view.
When the user attempts to raise the ticket, RT seems to be checking for
the validity of these custom fields, even though the user has no ability
to set them.
Raising via email works as expected, but our users are used to the RT
interface and prefer to raise this way.
Is this expected behaviour? How might I work around this?
It is not expected behavior. I reported this a few months ago. Thomas
said that it’s already fixed in the 4.2 branch & there’s a ticket to
have it fixed in the 4.0 branch. Hit the login as guest button on the
URL below.
Is this expected behaviour? How might I work around this?
It is not expected behavior. I reported this a few months ago.
Thomas said that it’s already fixed in the 4.2 branch & there’s a
ticket to have it fixed in the 4.0 branch. Hit the login as guest
button on the URL below.
Your best bet may be to upgrade to the 4.2 branch.
To clarify, it’s not a branch of 4.2, the current releases of 4.2.2
contain these fixes. Unfortunately, backporting them is non-trivial
so I’m not sure if that will happen for 4.0.
Is this expected behaviour? How might I work around this?
It is not expected behavior. I reported this a few months ago.
Thomas said that it’s already fixed in the 4.2 branch & there’s a
ticket to have it fixed in the 4.0 branch. Hit the login as guest
button on the URL below.
Your best bet may be to upgrade to the 4.2 branch.
To clarify, it’s not a branch of 4.2, the current releases of 4.2.2
contain these fixes. Unfortunately, backporting them is non-trivial
so I’m not sure if that will happen for 4.0.
-kevin
Ah yes, I meant s/branch/release/g. Thanks for the clarification, Kevin.