Hello,
for some Queues we have a couple of Custom fields to be attached to Tickets
in this Queue.
These Custom Fields are of different kind with respect to when they are
expected to get a value and whether this value is expected to change.
Let me give an example:
-
some keywords have to be added by helpdesk personal when they first
create or take the ticket (if it is created by customer).
-
severity and level of concern have to be entered in an early stage but
may change during lifetime of the ticket.
-
some other field, for example if this ticket contains useful information
to be postprocessed by some person responsible for the knowledge base is
expected to be entered, when the ticket becomes resolved. For us it would
be indeed useful to make entering a value mandatory when reolving a ticket.
We would like to control where the entry fields for the custom fields are
shown, for example cf of kind 1 should be visible/editable on the "create"
and the “dispatch” screen (latter is a custom screen here), kind 2 should
be editable on each correspondance or comment screen, kind 3 should only
be visible on resolve screen and mandatory there.
For “pragmatic kind” of cf cannot be stored anywhere an “mandatory” status
does not depend on the “pragmatic kind”.
How would you implement this fetaure in RT without coding somthing like “if
name of custom field is xyz then … else …” in all of these mason pages?
Regards,
Dirk.
Hallo,
–Am 18. Januar 2008 11:22:19 +0100 schrieb Dirk Pape
pape-rt@inf.fu-berlin.de:
For “pragmatic kind” of cf cannot be stored anywhere an “mandatory”
status does not depend on the “pragmatic kind”.
this sentence is t a sentence I think, so next try.
cfs for now have only a category (type) but there is no attribute to give
them the desired “pragmatics”, that is on which pages they will be shown or
can be entered and in which stage of the ticket they become mandatory.
I look for a way to express this in the database and use this information
in the mason code systematically.
Regards, Dirk.
Dirk,
What you want to do is going to be very difficult. If custom field
permissions checking had some context of the current ticket having it’s CF
permissions checked then you could do something clean, but unfortunately no
context is provided.
There are callbacks that allow you to override what mason components are
used to display each CF and they do have ticket/page context, so you could
use them to display edit/display read-only/not display based on the ticket
and what context the CF is being viewed in.
-ToddOn 1/18/08, Dirk Pape pape-rt@inf.fu-berlin.de wrote:
Hallo,
–Am 18. Januar 2008 11:22:19 +0100 schrieb Dirk Pape
pape-rt@inf.fu-berlin.de:
For “pragmatic kind” of cf cannot be stored anywhere an “mandatory”
status does not depend on the “pragmatic kind”.
this sentence is t a sentence I think, so next try.
cfs for now have only a category (type) but there is no attribute to give
them the desired “pragmatics”, that is on which pages they will be shown
or
can be entered and in which stage of the ticket they become mandatory.
I look for a way to express this in the database and use this information
in the mason code systematically.
Regards, Dirk.
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Hello Todd,–Am 18. Januar 2008 07:52:31 -0500 schrieb Todd Chapman todd@chaka.net:
What you want to do is going to be very difficult. If custom field
permissions checking had some context of the current ticket having it’s CF
permissions checked then you could do something clean, but unfortunately
no context is provided.
There are callbacks that allow you to override what mason components are
used to display each CF and they do have ticket/page context, so you could
use them to display edit/display read-only/not display based on the ticket
and what context the CF is being viewed in.
Thanks for your advice. I will look through the callbacks you mention.
Dirk.